[OSM-talk] Islands

[80n]

On 4/16/07, Artem Pavlenko <artem at mapnik.org> wrote:
>
>
> 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.
>

So is your problem that you can't devise an algorithm to translate from the
OSM model to the Simple Features model?  Is that because  there is
information missing from the OSM?


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

Well its easy enough to extrapolate a straight line between two nodes when
there is a gap.  Osmarender has to do it all the time because the API
provides incomplete ways (at the bbox boundary), so we just extrapolate a
straight line at the edge of the bbox.

But Islands are not disjoint polylines with gaps anyway, they are closed
polygons.  The inadequacy of the OSM model means that you either have to
create them as two separate ways and have a method of saying that the two
ways are related (which can't be done), or you can make them a single way
that has a gap.  The gap is the *information* that is used to indicate that
the way contains two separate polygons.

Using ways and superways would be a much cleaner method, but until we get
them or something equivalent, we have to make do with the information we
have.


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

The problem with the geometry model being more explicit is that you have to
be sure it doesn't tread on the free-format tagging philosopy.  A simple tag
like place=city carries a lot of semantics that have to be interpreted
implicitly by renderers.  We make assumptions that a city is something that
has a certain approximate size and is relatively larger than a town.

I agree though that some things could be more explicit in the OSM model.
Particularly grouping of ways into super-ways or some method of establishing
relationships between objects.  Either would make it easier and more
explicit to be able to say that this path here (an island) is connected to
this path (a river).  Until such time as something better is implemented we
have to use what we have.


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

Can you explain why gaps are such a problem for you.  Can't you extrapolate
a straight line from the end of one segment to the start of the next
segment?


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/f68995c7/attachment.html>