Skip to content
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

For some cities only a square is displayed #339

Open
sebkur opened this issue Feb 22, 2022 · 7 comments
Open

For some cities only a square is displayed #339

sebkur opened this issue Feb 22, 2022 · 7 comments
Labels
bug content A point concerning the integrated neighborhoods

Comments

@sebkur
Copy link
Contributor

sebkur commented Feb 22, 2022

For some cities, the expected suburb boundaries do not appear, instead there only a giant square on the map.

These are cities for which it doesn't work here:

  • Augsburg
  • Braunschweig
  • Bad Belzig
  • Wiesenburg
  • Chemnitz
  • Potsdam

for most other cities everything works fine.

I have the impression it might have something to do with the extend of the city, the ones above are all rather small ones, so that the zoom level is rather high (i.e. zoomed in).

@sebkur
Copy link
Contributor Author

sebkur commented Feb 22, 2022

I have looked into the Chrome Developer Tools and looked for something suspicious happening but didn't stumble upon anything that looks like it could be the cause for this. I don't think it is a problem with the data as others who also experience the problem told me they used to work before.

@fnogatz fnogatz added bug content A point concerning the integrated neighborhoods labels Feb 22, 2022
@epaulson
Copy link
Collaborator

@sebkur can you check out the geojson winding order of those - see what we did in #332

@sebkur
Copy link
Contributor Author

sebkur commented Feb 23, 2022

Thanks, indeed, that seems to do the trick. See #342 for Bad Belzig. When this passes review I can also fix the others.

@sebkur
Copy link
Contributor Author

sebkur commented Feb 24, 2022

I also detected a few more broken ones:

  • albuquerque.geojson
  • arlingtonva.geojson
  • copenhagen.geojson
  • durham.geojson
  • melbourne.geojson
  • taiwan.geojson

Those also have some polygons that are not in clockwise order, however I wasn't able to see that anything is broken in the web app:

  • chapel-hill.geojson
  • korea.geojson
  • london.geojson
  • olympia.geojson
  • poland-parks.geojson
  • san-diego.geojson

@epaulson
Copy link
Collaborator

re: the cities that aren't ordered right but display correct - I'm unfortunately not enough of a GIS/D3 expert to know exactly why the old version of d3 (v3) had no problem with these files and why the modern version of d3 (v7) does - I've not been able to find a documented change in d3 that says it's more strictly enforcing the order or some other change that would help us understand what exactly to look for.

@sebkur
Copy link
Contributor Author

sebkur commented Feb 24, 2022

I guess it might have to do with @mbostock's reply further down on the thread you you linked to d3/d3-geo#79 (comment):

Related, it’s not sufficient to say that the exterior ring should be clockwise (or anticlockwise) because D3 uses spherical rather than planar equirectangular coordinates. Better to clarify that exterior ring for polygons smaller than a hemisphere should be clockwise; polygons larger than a hemisphere will use the opposite winding order. In other words both winding orders are valid but have opposite meaning.

I'm also still not quite getting this yet. Spherical polygons, planar polygons, hmm, which one's do we have at hand?

@epaulson
Copy link
Collaborator

Right - but what I didn't understand was what changed in D3 between v3 and v7 - wasn't it always using spherical coordinates?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug content A point concerning the integrated neighborhoods
Projects
None yet
Development

No branches or pull requests

3 participants