On Thu, Jun 26, 2008 at 2:35 AM, Lauri Hahne <[EMAIL PROTECTED]> wrote:
> First, I must admit that the subject of this message is a little bit
> outre but don't let that bother. *
>
> I'm trying to summarise a few things I've been thinking lately. I
> think none of these issues is major or something that should actually
> be worked on. I have no suggestions what-so-ever what could fix the
> issues but don't let that bother. I just want some feedback and to
> know whether anybody agrees with me.
>
> 1. Ways
>
> - There are one kind of ways in the database. Ways can have attributes
> (tags) but aren't required.
> - The tagging scheme suggest there are many kinds of ways (highway,
> cycleway, aeroway...)
> - Potlatch and JOSM's preset (and mappaint?) system allow you to pick
> a type for way.
> - We have questions such as "how can I turn this way into a bridge" or
> "how can I create a "bridge-way" at #osm once in a while.
>
> This leads me to think that do Tagging Scheme, Wiki, Potlatch, and
> JOSM (in that order - ordered by "severity") give wring kind of hints
> what's actually in the database. This is because it has become pretty
> obvious to me that there are people (likely not much?) who think the
> that we have different kind of ways. These people need to be told that
> we don't have different kind of ways but way which have attributes. I
> can see why these people think like this because especially wiki does
> list different kind of ways in the Map Features page.
But we do have different kinds of ways.
If users are asking how you change the type of the way, then that
suggests to me a fairly useful abstraction from the data model that we
should be taking advantage of.
Roughly speaking our extended data model, the bit that actually starts
to define what all the ways and nodes actually mean (ie: map
features), does to a large extent imply that each way has a type.
Our data model is much more than just the raw stuff we put in the db.
>
> 2. Nodes
>
> Apparently Potlatch tris to keep nodes and POIs separate even though
> these are the same thing again. This works really well in Potlatch but
> yet again it's against our data model and might lead to some
> confusion. I haven't seen any examples of this so this is very
> theoretical for now.
>
I don't think this is against the data model at all.
Obviously we both know that there's no difference in representation in
the OSM database, except that one is a member of at least one way, and
the other isn't, and we also know that large numbers of tools will
ignore that one difference when processing them. But logically it
makes perfect sense, and again our extended map features data model
kind of largely implies that this is true.
ie: this is another useful abstraction that will help out users if put
to proper use (like in Potlatch).
>
>
> As I wrote earlier, I have no suggestions about "fixing" these issues.
> IMHO the current data model is great but I think it should be made
> obvious to newbies. One way to do this would be to introduce OSM as
> trace-nodes-way-tags instead of the traditional trace-nodes-way which
> is quite prevalent in slides etc. It would also be a nice idea to
> write an introduction to our data model and put it in the beginning of
> the Beginner's Guide in Wiki. I'm volunteering to write this if
> somebody promises to proof-read it.
So I think the "fix" for this is to have the editors better represent
what's actually going on, rather than to have the users trained in the
nitty gritty underlying data model. Abstractions are good, and for the
vast majority of our 40,000+ users more than enough. I'm guessing just
about everybody subscribed to this mailing list wants more though (me
included). I want to be able to play around with the raw
tags/nodes/ways/relations etc to come up with new things, new ways of
doing things. I'm guessing most people just want to make a map though.
Ideally the editors will cater for both.
One of these days I might actually get round to doing something about it.
Dave
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
