[OSM-dev] [Fwd: Re: Chopped of ways. New flag for OSM XML?]
brett at bretth.com
Sat Aug 16 02:10:54 BST 2008
Rogier Wolff wrote:
> On Fri, Aug 15, 2008 at 07:59:07AM -0700, Karl Newman wrote:
>>> Making some parameter negative to mean "this object is incomplete"
>>> sounds like a hack to me. It's something that you might do in an
>>> internal database, or in an in-memory datastructure, but it should not
>>> be in an API. Not ever. It's a cludge.
>> I was thinking more of the general case--"this object should not be
>> uploaded because it's been manipulated in some way that invalidates
>> the data". Setting the version of an entity as negative would
>> easily prevent that, using the (proposed) server api. This "hack" is
>> intended for offline files, not the main API.
> Of course it's not the "main API", but if you use this method in one
> instance, it will be seen as an example. People will copy it. And
> before you know it, data will be passed along from app to app with this
> advice taken to heart. And then you have it in an API.
> You're saying the main API will ignore such uploads. Great. Now the
> fact that these are ignored has become part of the API!
Apologies for returning email to the list if that wasn't the intent of
your email. I just assumed it was accidental, it happens a lot around
here :-) Feel free to voice opinions, I'll always listen, and will
often disagree :-)
To be honest, I don't know what the best solution is here. I tend to
agree that using features for something they were never intended is a
bad idea and often has unintended consequences down the track. In this
case it may be the lesser of several evils though.
We have these options:
1. Do nothing - This is always my default position, and the best unless
you're absolutely sure you have a better answer.
2. Change to negative identifier - Doesn't solve the problem of
preventing uploads, and is somewhat painful to implement, especially if
you take relations into account.
3. Change version identifier - Prevents uploads which was the original
problem. Not the original intent of this attribute. Consumers need to
know that version became negative due to mangling of the entity.
4. Add a tag - Only works if all consumers of the data explicitly look
for the tag.
5. Invent a new entity attribute indicating mangling - Perhaps the
"cleanest" approach. But more complicated than all others and requires
an API change. Would have to be well thought out, perhaps could even be
an "origin" tag making it more generic. Just throwing the idea out
there, haven't thought it through.
Of the above I tend to lean towards updating the version.
More information about the dev