Re: [OSM-dev] Turning boundaries to linestrings

[Paul Norman]

On 12/13/2016 9:04 AM, Martin Koppenhoefer wrote:
that's a nice hack which will generally work, but having overlapping 
boundaries (different ways on the same position) is not a clear 
"error" in OSM, so it is not 100% reliable.


No. I looked at the data visually with transparency to find overlaps, 
and they are exceedingly rare. As a data consumer, I have no hesitation 
in calling what you have described an error.


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Turning boundaries to linestrings

[Paul Norman]

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

Re: [OSM-dev] Turning boundaries to linestrings

[Martin Koppenhoefer]

2016-12-13 13:33 GMT+01:00 Christoph Hormann :

> 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.
>


that's a nice hack which will generally work, but having overlapping
boundaries (different ways on the same position) is not a clear "error" in
OSM, so it is not 100% reliable.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Turning boundaries to linestrings

[Christoph Hormann]

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()).

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.

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.

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev