[Imports] Bulk Import of Hotels

[Greg Troxel]

Pieren <pieren3 at gmail.com> writes:

> On Thu, Jan 28, 2010 at 1:37 PM, Greg Troxel <gdt at ir.bbn.com> wrote:
>
>> I've been thinking about how to handle maintenance of imports; so far
>> osm has tended to import once and then just edit.  My suggestion is to
>> put whatever database primary key you use on the node, and to be able to
>> look at the node and tell which import was done, which really means the
>> internal date or whatever identifier of your database extract.
>
> But what happens if someone replaces your imported node with a new one or
> the node is deleted or someone just changes your primary key for fun ?
> I think it would be better to keep the node_id or way_id (building) in your
> own database and check regularly if your element is still at the right
> location (with some tolerance) with the right tags (with some tolerance) .
> Then if the POI has been removed, check if the same one has not been
> recreated around. If yes, just refresh the node_id in your db. If not,
> recreate the POI or revert the deletion. The link between your db and OSM is
> the lat/lon, not an id which is not guaranteed in time.

The basic principle that I think should be followed is that if imported
data is changed by a user, then that change should not be blindly
overwritten by an import process.  That doesn't mean "node not updated"
- if a user moves a hotel point and the hotel company has a new phone
number and verifies (perhaps programmatically) that the old phone number
is still there, then it's fine to automatically edit it.  But it would
be broken to overwrite the location.

If a user deletes a node and replaces it, then the next import should
flag that as needing manual intervention.  And users shouldn't do that -
they should edit the node.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20100128/974492cf/attachment.pgp>