[OSM-talk] Making iD the default editor on osm.org

[Peter Wendorff]

Hi Lester,
Thanks - my fault.
misread the section about 412, which refers to MEMBERS of the updated
object, not to the object itself.

Sorry for the confusion!

regards
Peter

Am 25.08.2013 12:37, schrieb Lester Caine:
> (remember to check address!)
> Peter Wendorff wrote:
>>>> If so, then sorry for that - but is there any documentation about it?
>>>> >>The API description in the wiki does not mention anything like
>>>> that, so
>>>> >>IMHO it's missing there, isn't it?
>>> >
>>> >They upload a new version of the object with the appropriate
>>> properties.
>>> >The more relevant call for uploading data is
>>> >http://wiki.osm.org/wiki/API_v0.6#Diff_upload:_POST_.2Fapi.2F0.6.2Fchangeset
>>>
>>> >.2F.23id.2Fupload.
>>> >I don't see anything that needs adding to the documentation.
>>> >
>>> >
>> Sounds inconsistent nevertheless: updating a single object using PUT
>> /api/0.6/[node|way|relation]/#id is not possible when referring to a
>> deleted object, but updating the same object using diff is.
>>
>> If nobody complains, I'll add a hint to the section referring to the
>> diff upload section, and a hint that diff uploads may be used for real
>> reverts, too.
> 
> At the end of the day, nothing is ACTUALLY deleted. Currently a copy is
> retained in the changelog and that is simply used to 're-edit' changes
> so that as has been said a new version is created matching the last but
> one version. The API does not prevent using a 'deleted' node or way
> number so all of the change log history can be retained. But this is
> where maintaining historic records creates a problem. Only one copy of
> an object is maintained in the main live data, so accessing a previous
> 'view' say prior to a realignment of a road fails because it has the
> same way number. Using start and end dates to select a particular view
> is not supported ...
> 
> This is where 'delete' is the wrong concept. Currently it just means
> it's made invisible and there is no reason it can't simply be restored.
> What should be happening is that there should be a mechanism to tag the
> reason for the 'change of state' and changes that are due to historic
> development need to be made available via a different route. Since the
> start and end date tags already exist, managing these properly is long
> overdue, but it's moving records that now have an end date to a view of
> the database where that information can be used that is currently missing?
>