[OSM-talk] Missing structure

[Karl Newman]

On Jan 17, 2008 11:00 PM, Lester Caine <lester at lsces.co.uk> wrote:

> Karl Newman wrote:
> > On Jan 17, 2008 12:52 PM, Lukasz Stelmach <stlman at poczta.fm
> > <mailto:stlman at poczta.fm>> wrote:
> >
> >     Lester Caine wrote:
> >      > After my missive in the postal addresses thread I had yet another
> >     scout around
> >      >   on what is already available and how it is not being managed
> well.
> >      >
> >      > All mapping is currently based on physical nodes, but I think
> >     that perhaps we
> >      > need an abstract element that we can hang things on.
> >     [...]
> >
> >
> >     Day by day it becomes more obvious to me that sooner or later
> >     segments/ways distinction will be back with us. Look at this.
> >     A way (street) may belong  to many relations, right? Each relation
> >     may contain different part of the street, right? Especially in big
> >     cities where bus routes can be relations and each bus may take
> >     different turns, there will bo no single way/highway comprising more
> >     than one segment (to be precise I think about lines between
> >     crossings which in case of curved street may comprise more
> >     segments). There will obviously MUST be invented 'street' replation
> >     which takes a few segmetns and gives them common name. The other
> >     relation (perish?) could contain all the objects that belong to a
> >     certain place including half of the segments of the streets that
> >     connects two adjacent places.
> >
> >     This shows a little problem which, however, should be automatable, a
> >     new object (node/way|segment) has to be assigned to a different
> >     object (relation) rather then assigning the  place relation to the
> >     new object.
> >
> >     I am just shatring my thoughts, maybe someone can come up with some
> >     thing wiser ;-)
> >
> > It seems to me we're going about this all wrong. Instead of splitting up
> > ways just because any of its attributes change (or to break it up for a
> > route), it seems like a way which denotes the same street (or other
> > linear feature) should be as long as possible. Then we could hang
> > attributes on subsections of it: i.e., for way 1234, the speed limit
> > from node 5522 to node 5595 is 100 km/h. Or, way 1234 is a part of route
> > "blue bus" from node 9553 to node 2558. Relations could accomplish this,
> > but they don't have a rigorous structure to enforce all the parts/data
> > integrity.
>
> This is missing the point *I* was trying to make and while managing the
> detail
> at this lower level IS important, it's the integrity of links to the upper
> levels that need fixing first.
>
> A lot of the higher level relationships could be 'calculated' if we had
> well
> established areas and fast searching on geographic position, but in the
> absence of that, a street, or village 'is_in' a ward, parish, county or
> other
> area designation, and these areas are then 'is_in' states or countries.
>
> So a simple following of the 'is_in' links provides the hierarchy and the
> integrity of objects used 'is_in' should be enforced to ensure that there
> is
> only one occurrence of the target object ! Just allowing any free format
> matching does not work!
>
> OTHER hierarchy is also appropriate such as 'M1' or 'Ermine Street' but
> proposing to merge all of the ways associated with them would not work. We
> do
> need rules as to how the tagging could be used to identify these sorts of
> divers structures, and a 'place' called Ermine Street which can then be
> used
> in an is_in tag on elements of that road, makes sense, but would distract
> from
>  identifying the appropriate 'address' for properties on it. Another
> example
> is postcode, and a long street that has 4 postcodes SHOULD be four ways (
> although there may be several branching ways on some housing estates )
> each
> tagged 'postcode' and is_in 'This street' - it's where the object 'This
> street' exists that is the problem :(
>
> --
> Lester Caine - G8HFL
>

Lester,

Sorry, I was making more of a general comment about how ways are degrading
into segments because of the frequent need to split them. I wasn't really
commenting on your proposal. However, I will now. :-)

I don't have any particular objections against your proposal (although it is
somewhat complex), but I still think geographic boundaries are the way to
go. Which do you think will happen first: Creation of boundaries and a way
to quickly query a point against them (or rather the reverse: given a point,
return the boundaries), or tagging of nearly every object in the database
with an is_in tag?

Since it is going to be renderers, routers and other data consumers that
need that data, there's no need to impose a burden on OSM itself. It could
be done as a parallel activity, derived from information in the database,
somewhat like the Name Finder. If the boundaries are in the database and
appropriately tagged, they could be used for this purpose.

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20080118/10e5478a/attachment.html>