search

Open-Historical-Map-Labs / openhistoricaltiles

First iteration of vector tiles from OHM Planet data
BSD 2-Clause "Simplified" License
3 stars 0 forks source link

Borders overlapping #52

Open daelba opened 5 years ago

daelba commented 5 years ago

When rendering border relations, borders are badly overlapping. It seems, that borders are simplified, when converted to vectors, but the simplyfying is done in other way in each relation. This causes:

  1. bordes are not overlapping perfectly (red circles)
  2. dot-and-dash lines are changed to dash-and-dash or simple line (blue circles)

https://openhistoricalmap.github.io/openhistoricaltiles/mbgl-control-timeslider/demo/#10.599/49.57266/15.73962/1905,1850-1945

borders overlapping

┆Created By: Dan Rademacher

jeffreyameyer commented 5 years ago

@mojodna - any thoughts?

danrademacher commented 5 years ago

Thanks for this feedback. Hmm, I think both of these issues are the result of a compromise we're making for real-time first-class OHM-ness of borders, as opposed to OSM's native borders processing that doesn't update automatically or incrementally.

The downside is that adjacent borders overlap instead of getting combined into a smarter topology. I think we might need to take a carto design approach to solving this to get the benefit of realtime border updates without the downside of unaligned dashes colliding.

jeffreyameyer commented 5 years ago

I've added this to the improved stylesheets for the "Launch+1" milestone (also shown here: https://github.com/orgs/OpenHistoricalMap/projects/1)

On Wed, Jun 12, 2019 at 9:14 AM Dan Rademacher notifications@github.com wrote:

Thanks for this feedback. Hmm, I think both of these issues are the result of a compromise we're making for real-time first-class OHM-ness of borders, as opposed to OSM's native borders processing that doesn't update automatically or incrementally.

The downside is that adjacent borders overlap instead of getting combined into a smarter topology. I think we might need to take a carto design approach to solving this to get the benefit of realtime border updates without the downside of unaligned dashes colliding.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/OpenHistoricalMap/openhistoricaltiles/issues/52?email_source=notifications&email_token=AALM4ET3YLVLJUD6GF2JFZTP2EOGPA5CNFSM4HXG4LGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXQ66PI#issuecomment-501346109, or mute the thread https://github.com/notifications/unsubscribe-auth/AALM4EQDY3PPNCSFTZZWV6DP2EOGPANCNFSM4HXG4LGA .

-- Jeff Meyer 206-676-2347 osm: Open Historical Map (OHM) http://wiki.openstreetmap.org/wiki/Open_Historical_Map / my OSM user page http://www.openstreetmap.org/user/jeffmeyer t: @OpenHistMap

mojodna commented 5 years ago

What @danrademacher said about trade-offs. There's no straightforward way to simplify common borders so that they produce identical output (this is what osm-borders was doing, but it didn't include a path to incremental updates).

+1 on a carto approach to dealing with border conflicts; OSM did this for a long time (with less simplification, as it was using Natural Earth at lower zooms) before osm-borders was created.