[OSM-talk] Islands

Artem Pavlenko artem at mapnik.org
Mon Apr 16 14:04:43 BST 2007


On 16 Apr 2007, at 12:58, 80n wrote:

> On 4/16/07, Artem Pavlenko <artem at mapnik.org> wrote:
>
> On 16 Apr 2007, at 12:00, 80n wrote:
>
>> On 4/16/07, Robert (Jamie) Munro < rjmunro at arjam.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Artem Pavlenko wrote:
>> >
>> > 80n,
>> > We don't really need all this crossing segments.
>> > Please, could you explain to me what's wrong with representing  
>> features
>> > like 'river with islands' as proper polygons (one exterior and
>> > n-interior rings) ? If you want just a small part of a bigger  
>> polygon
>> > for rendering use _clipping_.
>>
>> The problem is that none of our existing editors can cope well with
>> editing a way that is big and complicated e.g. the whole river  
>> Thames as
>> a single polygon. If it's multiple polygons, we need a way to join  
>> them,
>> which is the crossing segments. It's a similar problem to coastlines.
>>
>>
>> No you don't need to join them.  You can use the feature/bug that  
>> ways do not require segments to be contiguous.  You can hop from  
>> one side of the river to the other and you can hop from the  
>> riverbank to an island without needing segments to connect them  
>> together.
>>
>> Logically a way is made up of one or more sub-paths.  Each non- 
>> contiguous segment implicitly defines the start of a new sub-path.
>>
>> If we ever get rid of segments then, in this scenario, the way  
>> would become a super-way and each sub-path would become a way.
>>
>> The concept of a path comprising of sub-paths is well defined in  
>> the W3C specifications and the rendering behaviour of such a path  
>> is also well defined.  It seems like a good model to use and is  
>> better than re-inventing the wheel (unless someone invents a  
>> better wheel).
>>
>> 80n
>>
>
> Well, I'm not with you on this one!  Rendering is only one aspect  
> of using OSM data. What about spatial analysis? Do you really  
> suggesting to re-invent in that area?
>
> Artem
> Rendering is only one aspect of using OSM data.  What are the  
> requirements for spatial anaysis?

Here is list of some things that fall into spatial analysis:
Buffer, Spatial predicates (Intersects, Within, Touches etc usually  
defined by DE-9IM matrix), overlay , union etc.
Currently implementations of these operations (to my best knowledge)  
are based on geometry model as defined in Simple Features. The same  
geometry model provides basis for topological model(s). It is  
industry standard and it's widely used.

I don't think 'Simple Features for SQL' is appropriate model for  
collecting data but If OSM data to be used for real, it will have to  
be converted to something that is complaint with the standards.

osm2pgsql goes some way to deal with all this (self- 
intersections.self-tangency) , but there is no way to create polygons  
from disjoint polylines with *gaps*. I think OSM geometry model  
should be more explicit about this. Yes, there are some features/bugs  
and lots can be fixed at  post-processing step, but why don't we  
apply constrains at the data entry and collect better data?  There  
are FOSS libraries (Java/C/C++/Python ) we can use.

> What needs to be represented in the OSM schema and what is  
> currently lacking?

Path-like geometries work well for rendering and I'm using them in  
Mapnik. Unfortunately, they don't play well with spatial predicates.   
So here are some steps :

1. Apply constrains such as no self-intersections/tangency is allowed
2. Polygons(Areas) are closed with no gaps!

I'm hoping some of this has been dealt with at Essen meet-up.

> What are you trying to achieve?
>

I want to use OSM data :)

> 80n
>
>
Cheers,

Artem


>
>
> Cheers,
> Artem
>
>>
>>
>>
>>
>>
>> Robert (Jamie) Munro
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFGI1USz+aYVHdncI0RAlVMAJ9+gFeB0q23jLQFlyBHhXfZVod5ygCdGj9F
>> r9qMkGs42vUjaOTn7zJsS6k=
>> =fMVf
>> -----END PGP SIGNATURE-----
>>
>
> Artem Pavlenko
> http://mapnik.org
>
>
>
>

Artem Pavlenko
http://mapnik.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20070416/356bcb2e/attachment.html>


More information about the talk mailing list