-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should geom::Polygon.points be closed or not? #2
Comments
The intention is for them to be. But a flat list of points for a polygon with holes is meaningless -- to be more clear, But all of the guarantees depend on how the
Awesome! That's what I'd love to see too. A next (big) step would be to try to make In an ideal world, we can make sure every single construction of a polygon happens from closed rings. But in case all we can get out of lyon is a triangulated mesh, I wonder what we should do otherwise. Also related: the other big |
To test the theory that the problem is usvg + lyon feeding into |
Ah! So the points returned from lyon are likely not even in any particular ordering WRT the winding of the polygon - it's basically just a bag of It seems pretty unlikely that we'd be able to safely roundtrip that representation with geo. |
Maybe |
That sounds plausible! I may (may!) have a go at this tomorrow. |
I think I'm having a go at something along these lines. My basic idea was to have two types:
It's going OK, but I think seeing it through could be a very large change. Here's my hack-and-slash WIP if you're curious: I think at the end of it, Polygon wouldn't have an GeomBatch then, is a collection of Tessellations, not Polygons. I haven't gotten far enough to know if there will be any show stoppers with this approach, but it does seem like it's going to have far reaching implications that I might not have time to see through. Does this approach seem reasonable? |
Approach sounds perfectly reasonable to me! The difficulties I would anticipate...
So actually this hopefully shouldn't be too bad... |
If it's OK, I'm going to pick up your branch and try to push through. I think the migration steps could be:
In your branch you were very carefully changing the API for places that directly construct a tessellation, but I won't attempt that until maybe a step 4. It's a huge refactor. |
I got too ambitious as usual! https://github.com/a-b-street/abstreet/tree/geo_polygon_too_quickly is a start, but I realized some more complications:
I do see a few smaller steps to peel off first, to make the migration easier. I'll see if I can get rid of a few places that construct |
SVG icons that're circles, so just make a way to turn Bounds into a Circle. #951
….com/a-b-street/abstreet/issues/951. This method isn't used in osm2streets itself.
a-b-street/osm2streets#47. No behavioral effect from this. For the moment, I'm pretending uncontrolled junctions are the same as stop signs. Also whittle down creators of strange polygons for #951. Some buildings or areas may be affected, but no major problems seen yet. Regenerating everything...
Can you expound on this? I'm not sure what you mean. |
I've got a few steps to remove callers that construct "bad" polygons. Then we can switch to tessellations for rendering, and consider step 3.
I'm mistaken. We always transform a |
a-b-street/osm2streets#47. No behavioral effect from this. For the moment, I'm pretending uncontrolled junctions are the same as stop signs. Also whittle down creators of strange polygons for #951. Some buildings or areas may be affected, but no major problems seen yet. Regenerating everything...
a-b-street/osm2streets#47. No behavioral effect from this. For the moment, I'm pretending uncontrolled junctions are the same as stop signs. Also whittle down creators of strange polygons for #951. Some buildings may be skipped on import now, but no major changes observed. Regenerating everything...
…any sidewalk corners that stop being rendered, so this is fine.
…ering. #951 The goal is for every Polygon to consist of valid Rings, for a simpler API and better georust integration. Thanks to @michaelkirk for starting this!
…invalid Polygon only to render it. #951
…invalid Polygon only to render it. #951
…ering. #951 The goal is for every Polygon to consist of valid Rings, for a simpler API and better georust integration. Thanks to @michaelkirk for starting this!
…invalid Polygon only to render it. #951
has stricter rules for Rings. Finally remove Polygon::buggy_new, and instead make many Polygon methods return a Result. #951 Just internal geom changes here, no changes downstream yet.
has stricter rules for Rings. Finally remove Polygon::buggy_new, and instead make many Polygon methods return a Result. #951 Just internal geom changes here, no changes downstream yet.
Temporarily breaks the build...
And fix a bad Polygon::rectangle caller from widgetry.
Things like driveway trimming and snapping may slightly change near buildings with holes. Not yet regenerating everything.
Tessellation when thickening Rings for outlines, since the result isn't a valid Ring. #951
This was added to show people how direct the non-car trip is, but the UI is overwhelming right now with 4 routes. Still let people see more info, but don't overload them to start.
This was added to show people how direct the non-car trip is, but the UI is overwhelming right now with 4 routes. Still let people see more info, but don't overload them to start.
Tessellation when thickening Rings for outlines, since the result isn't a valid Ring. #951
Tessellation when thickening Rings for outlines, since the result isn't a valid Ring. #951
concept of the "currently edited area". #951
… add-on to the top-bar. #951 Sliiightly untested.
concept of the "currently edited area". #951
… add-on to the top-bar. #951 Sliiightly untested.
Remaining work before the polygon cleanup can be considered done:
|
…it slower, and most callers of center() just need something 'vaguely' in the middle of the polygon. #951 I didn't regenerate anything based on this change; not sure anything would be affected anyway.
I wanted to test out some new georust/geo features in the context of abstreet, and consequently I've been spelunking in abstreet::geom.
I ran into some inconsistencies while trying to roundtrip some abstreet::geom::Polygyon to/from geo::Polygon - it resulted in some corrupt rendering like this:
My unverified hunch is that this some problem with one or more of:
points
array and the precomputed triangulationindices
While digging into that, I noticed that some (but not all) of the abstreet:geom::Polygon.points are closed. Do you have any strong feelings on whether abstreet::geom::Polygon.points should be closed?
Full disclosure is that more broadly I'm interested in making abstreet/geom more semantically consistent with georust/geo, in hopes of make future inter-op easier, but I'm also aware that these are the kinds of changes with no immediate benefit that could have a long tail of bugs in a system which is more or less currently working.
The text was updated successfully, but these errors were encountered: