[OSM-dev] [Fwd: Re: Chopped of ways. New flag for OSM XML?]

[Brett Henderson]

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.

Cheers,
Brett