[Openstreetmap-dev] OSM - Schema - Phase 1 - Request for Comment
Tom Carden
tom at tom-carden.co.uk
Tue Nov 29 13:42:18 GMT 2005
Andy Robinson
> Tom Carden wrote:
>
>>Is the task at hand here to expand the current format to hold polygons
>> and
>>points of interest? Why not start there instead of backtracking over yet
>>another way to represent things we already have?
>
> I consider that the task is not to expand the format but to help clarify
> what might constitute the content.
>
Great. That's not a discussion about XML, that's a discussion about
stuff. Let's have that discussion (much as Nick did for telling us about
the kind of paths/roads etc he wanted to represent) and not worry about
how it gets passed around from server to client and back again (not like
Nick when he started talking about adding extra specific attributes to
elements).
>>Is there such a thing as a "way" currently used in OSM? Sounds like new
>>terminology for "segment" or "street" to me, and totally redundant.
>
> Yes, the <way> is my suggested replacement for <street>. It simply means
> we
> might use the same linear designator whether it's, for example, a street
> or
> a railway or an overhead power line. The term "way" just happens to fit
> more
> of the liner types than any other word... but its only semantics anyway.
>
Now we're getting down to it. You want a way to add linear things other
than streets, and you want there to be a generic element to represent
them? That's a one-line request, not a bullet-pointed schema discussion.
Add a ticket to Trac?
>>Unless you're going to write the code that produces it or consumes it,
>> why
>>should you care?
>
> I care very much because right now, as a user, I have no way of adding any
> real map features other than nodes, line segments and a generic "name". If
> I
> keep naming segments "path" so that I can remember its not a road I'm soon
> going to have a hell of a task reediting all those line segments which are
> currently all the same.
>
And here we get to the crux of the argument. The problems you outline
there aren't anything to do with the XML schema. They're to do with how a
client deals with the data it receives, and how it expresses things in
terms of the tags method currently available.
Trac tickets requesting that the applet be modified this way or that way
would be more likely to result in changes to how OpenStreetMap looks and
behaves than an unwieldy schema discussion and resulting spec.
>>And if you are going to write that code, I can't state
>>emphatically enough that those who can code should be concentrating on
>>other issues.
>
> I don't doubt that but that's not what the purpose of the original post
> was.
It's really simple: XML is not the solution or the problem. It's the
glue. You have some stuff you want to get done, and that will involve
code someone else is going to write. Why obfuscate your feature requests
by phrasing them as a spec for the next API format, when you could far
more easily request specific additions to what the database can represent,
and request updates to your client of choice to read/write that data?
I really don't think that the mailing list is the right forum for
discussing XML schema specifications. Further, I don't think that XML
schema specifications actually solve the problems you really have. XML is
just the problem you think you have.
Tom.
More information about the dev
mailing list