[OSM-dev] A consistent format for the multipolygon relation
Andreas Kalsch
andreaskalsch at gmx.de
Tue Jun 16 09:45:16 BST 2009
I don't like this way of discussion. It leads to nowhere ...
The point I wanted to demonstrate was to start an initiative to get
multipolygons into the right format because the quality of OSM data is
crucial for all projects which use it. To get a more consistent
definition of multipolygons is an important step to make it easier for
everyone (including the map renderers) to build on top of the data. I
don't want any silver plates, too, but bite-sized data.
Pretty easy, huh?
Best,
Andi
Wolfgang Schreiter schrieb:
>> "Frederik Ramm" <frederik at remote.org> schrieb im Newsbeitrag
>> news:4A35459C.7070706 at remote.org...
>> Hi,
>>
>> Wolfgang Schreiter wrote:
>>
>>> the style of your response suggests to me that for some reason you take
>>> this
>>> personally.
>>>
>> Not the case; I only found it somewhat condescending of someone who has
>> not made much of an appearance in OSM at all to say that something
>> (whatever it might be) would be required for OSM "if it takes itself
>> seriously", implying that we're just a bunch of clowns at the moment.
>>
>
> All right, so I haven't written a book, just put in a couple of hundred
> hours
> on top of a full-time job.
> And I cannot remember having mentioned clowns at all.
>
>
>> We have had our share of professionals offering their advice, but it was
>> hardly ever advice that came from knowing OSM well - only advice
>> transferred from other, usually non-crowdsourced, non-open,
>> non-spare-time, and non-hobbyist projects based on the totally
>> unreflected assumption that as OSM "grew up" it would certainly have to
>> do as the "professionals" do.
>>
>
> I've seen a lot of good projects go down because people were too sure of
> themselves
> and felt they had no need to listen to advice.
>
>
>>> The success of osm depends on the ability of software to make use of the
>>> data, on the relative simplicity to produce such software, and on the
>>> possibility for end-users to understand the provided data and form a
>>> mental
>>> model about it.
>>>
>> No.
>>
>> OSM's success on the user side is absolutely non-critical.
>>
>
> Pray nobody reads that. For someone who owns a business, this
> is a desastrous statement, even if it were true.
>
>
>> Interest for
>> what we do is so big that everyone is eager to incorporate our data as
>> soon as practically possible. OSM data is being converted in all kinds
>> of formats and data models without us having to move at all. Our part in
>> this is to make sure that the community remains intact, that mappers
>> join the project and keep with it, that our body of data grows and is
>> kept in order. That is the crucial bit - not how easy it is to use our
>> data in a run-off-the-mill GIS system. That bit is being accounted for
>> by anyone with an old-style GIS background and some programming skills.
>>
>
> I'm afraid I haven't made myself clear. Extracting the data may be
> run-of-the-mill,
> but interpreting it isn't. The more tags we have, the more of an
> expert system it will take to figure out what they mean. The same holds for
> those who
> join and/or try to keep the data in order.
>
>
>>> If you've read the spec I mentioned, you will
>>> know that its geometry model goes way beyond what can be usefully tagged
>>> at
>>> the moment, including a clear polygon definition and collections of
>>> linestrings and polygons, just to name the most important.
>>>
>> As I have pointed out, those linestrings do not have topology and thus
>> are rather useless for what we want to do. The spec you quoted is a
>> geometry spec, not a topology spec. You will be able to draw maps wirh
>> that, but you won't be able to do routing if you are too fixated on
>> geometry alone. Look to GDF if you're desperate for an ISO standard that
>> is nearer to what OSM tries to do.
>>
>
> OSM currently isn't able to clearly define an area. Whatever highflying
> ideas
> those in the inner circle may have, they'd better face the realities first.
>
>
>>> and it would indeed be
>>> wise to support what the industry out there is already doing.
>>>
>> I reject the idea that anything "the industry" is doing is worth
>> following. Worth looking at, perhaps.
>>
>
> These are not idiots, they're doing this for a reason, and it's called
> demand.
>
>
>>> Or, in case that was still not concrete enough: in Austria alone, there
>>> are
>>> currently on the order of 750 geometries that are perfectly valid in osm
>>> but
>>> not digestible by quite a few GIS-enabled databases
>>>
>> How sad. Luckily our own software nevertheless works with them. Maybe
>> those GIS-enabled databases should be improved ;-)
>>
>
> Our own software gets patched up on a daily basis for everything it can't
> do. That's
> a poor excuse for a lack of design, and a rather expensive method of
> operation
> where programming power costs money.
>
>
>>> *including our own*.
>>>
>> As I have already pointed out to you, OSM does not use a GIS-enabled
>> database.
>>
>
> No, osm doesn't, it's just a pile of data. Users of that data, including and
> foremost
> people writing tools for osm, do.
>
>
>>> Doesn't that strike you as odd? Care to explain that fact before a
>>> professional audience ("you know, we abhor any sort of standard, and who
>>> is
>>> Mr. Oracle anyway")?
>>>
>> OSM is not involved in a sales pitch to a professional audience.
>>
>
> I'll tell that to our speaker at AGIT. He'll be relieved. Same goes for
> our media relations.
>
>
>> Professionals are paid for their job, so they might just as well invest
>> a few hours to get OSM data into the shape they require (or, if that's
>> too much of a bother, buy "clean" data from someone else). Anything that
>> shifts work away from the "professional audience" you are speaking of
>> and onto the shoulders of mappers is a move in the wrong direction.
>> Mappers don't get paid. They should have it easy.
>>
>
> The point is, a better structure removes work from both the users, making it
> more likely
> that they use osm data, and the mappers as well. Currently everyone suffers.
>
>
>>> I can live with osm confining itself to be an experimental drawing tool
>>> database
>>>
>> See, that's what I do not like about your tone. Experimental? Drawing
>> tool? Right.
>>
>
> Glad you mention tone. I find the sort of arrogance you're displaying
> unbearable, and a shame for the spirit of such a project.
>
>
>>> and will then certainly find matters more worthy of my time.
>>>
>> Lucky you!
>>
>
>
>> You are one of those guys who wants OSM to do everything differently so
>> that users get their stuff on a silver plate. I don't see any merit in
>> this. Let people do this as add-on services. There are already WMS and
>> WFS services publishing OSM data, and we're only seeing the beginning of
>> that.
>>
>
> I'm one of those guys who gets paid to contribute advice so that people
> think about their approach while there is time. And I'm a contributor to
> this project,
> not a user, and my primary interest is to deliver high quality data.
> Though, given our little exchange, that remains to be seen.
>
>
>> GIS professionals haven't managed to produce anything remotely like OSM,
>> ever. Why should we suddenly look to them for guidance?
>>
>
> Because they've run into the same problems osm is facing, and found ways to
> deal with them.
>
>
>> Bye
>> Frederik
>>
>> --
>>
> Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
>
> Let me suggest to end this discussion at this point. I understand that
> you're looking for
> worker bees, not people with any sort of relevant experience or ideas.
>
> Good luck
> Wolfgang
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
>
More information about the dev
mailing list