On 12/13/2016 4:33 AM, Christoph Hormann wrote:
On Tuesday 13 December 2016, Paul Norman wrote:
Feedback from anyone interested in using this output is welcome, as
well as any additional information that should be added to the
linestrings.
You have some conflicting goals here - you want to maintain the OSM
tagging information on the way level so you need to maintain the
individual ways - which however limits what you can do in terms of
rendering - dashing is not consistent for example where a boundary is
split and you have problems doing geometry processing (like the all
popular ST_Simplify()).
Maintaining the individual ways is not a goal. The primary goal is being
able to render disputed boundaries, which this achieves, although not
perfectly. The dashing problems are most visible comparing dashed
borders on straight line borders in remote Canada vs several US states.
In the former, the border tends to be one long linestring because it's
unsplit and doesn't have many junction points, while in US states
junction points are more common.
IMO a process that merges the ways where it is non-ambiguous would be
more useful. And most cases where tagging varies in an admin boundary
without there being a junction that is a tagging error.
Most places where two admin boundary ways join are either part of a very
long stretch (e.g. BC-AB border) where merging isn't a huge issue, or
junction points of some kind where >2 admin boundary ways join. The
second poses a problem for merging and simplification, which can be
solved in a three ways
1. Merging on linestring admin_level and simplification by amounts that
don't visibly break topology, even if examining the data on a sub-pixel
accuracy shows breaks. More than this is a problem, not because of
opening up small gaps, but having ways appear to extend to far. The
former will end up interpreted as part of the dashes most of the time,
but the latter can look odd.
2. Doing merging that varies based on rendered admin_levels. This would
need to do a topology-aware simplification based on the admin_levels
that are being rendered. If done in preprocessing by osmborder, this
would probably need to result in 4-6 files being generated, each going
from admin_level 2 to a different maximum.
3. Simplification without merging. This can cause topology problems, but
not at junction points. Unfortunately, this won't help much with data
volume or dashes
Given current priorities, I can't see putting topology awareness into
osmborder or doing it at query time. If that happens, it will probably
be when working on generated vector tile size for low-bandwidth devices.
It's probably going to be simplification without merging at query time
initially, and at some point I'll look at linestring merging for roads,
and boundaries will be easy to do after that.
The maritime attribute based on tagging is currently of very limited use
since it is not consistently applied. On admin_level 2 a better way
would be to classify this based on topology - i.e. all boundaries that
are only part of one admin_level 2 relation are maritime boundaries.
On the higher admin levels this is more complicated of course and not
easy to solve.
Yes, I've been considering if I should do something like that by
counting number of parent relations, but not because of incomplete data.
The data is pretty good for admin_level=2, and less consistent for 4.
The question I was considering is how I want to render boundaries in
places like the Georgia Straight or Great Lakes, e.g.
https://cloud.githubusercontent.com/assets/1190866/21168186/faeecaae-c166-11e6-8cd1-7488fffddca4.png.
If I want those to be rendered, I have to count number of parent
relations and style based on that.
_______________________________________________
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
