[OSM-dev] Turning boundaries to linestrings

Paul Norman penorman at mac.com
Wed Dec 14 03:47:43 UTC 2016

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. 
If I want those to be rendered, I have to count number of parent 
relations and style based on that.

More information about the dev mailing list