[OSM-talk] Converting buildings from nodes to ways

andrzej zaborowski balrogg at gmail.com
Wed Dec 29 21:44:09 GMT 2010


On 29 December 2010 22:13, Dave F. <davefox en madasafish.com> wrote:
> On 29/12/2010 20:17, andrzej zaborowski wrote:
>>
>> Hi Dave,
>>
>> On 29 December 2010 21:04, Dave F.<davefox en madasafish.com>  wrote:
>>>
>>> On 29/12/2010 17:30, andrzej zaborowski wrote:
>>>>
>>>> On 29 December 2010 13:47, Dave F.<davefox en madasafish.com>    wrote:
>>>>>
>>>>> On 23/12/2010 12:10, Laurence Penney wrote:
>>>>>>
>>>>>> I've been 'exploding' several building nodes into ways,
>>>>>
>>>>> City centres maps look so much better with polygon ways, don't they?
>>>>>
>>>>> To encourage this practice it would be useful if the R (replicate) key
>>>>> in
>>>>> Potlatch worked from nodes to ways. It could also copy the history.
>>>>
>>>> There's no way in the current database schema to copy history from
>>>> nodes to ways.
>>>
>>> Hi andrzej
>>>
>>> Could you elaborate on this please?
>>>
>>> If you mean it can't currently be done, then yes, I know, that why I was
>>> posting the email.
>>>
>>> If you mean it can't be implemented in the future, then that's a bit
>>> disappointing. As OSM increases it mapping detail it would be a very
>>> useful
>>> addition.
>>
>> It could be implemented in the future but the request should not go to
>> Potlatch authors because the issue deeper.  So as far as I know the
>> workings of OSM, it'd have to wait to at least API 0.7.
>>
>> Object history is attached to an object.  Currently objects are
>> referenced by id + object type and IDs are not unique accross types
>> (node, way, relation).  So the type is a property of an object, not a
>> property of a revision of an object.  Thus no object can go from one
>> type to another without losing the history.
>
> I'm not sure if non unique ID's would be a problem as the user is selecting
> specific entities to copy from & to .
>
> Lets take a node element of a hotel that's been edited 4 times.
>
> Someones remaps it as a polygon way & copies the tags & history with the R
> key.
>
> The new way entity would only have to store the id tags of the node as
> historic ie "this used to be a node entity with the the id of XYZ123" whilst
> keeping the id it was given when created.

I assumed by copying history you meant keeping the Id of the entity,
but you suggest adding a new entity attribute to store the link to
"what this used to be".  Which is what I suggested too, earlier in the
thread.

Well, this still needs a change in the database schema and the API
because currently there's no such attribute that the editors could
use.  My second comment is that the history of XYZ123 is never
"closed", people can still edit XYZ123, so you'd have to store the id,
the type and the version number from which this new way entity was
"forked".

Cheers,
Andrew



More information about the talk mailing list