Re: [Imports-us] Seattle Import
On 12/14/2013 1:50 AM, Clifford Snow wrote: Eric Fischer got me thinking when he was working on a tiger fix that we need to retain this data for future updates, even if we don't know how to do updates today. Rather than use kingcounty:id, shouldn't we have a consistent method of identifying tags that may be needed in the future? It's possible just using :id is sufficient. However, maybe something like update:id, although that has problems as well. Future updates must handle OSM mapper's edits: - A mapper adds a new building address to OSM before the next county update. This must be detected and handled by the import re-sync conflation process without an ID. - A mapper removes a building address from OSM. Re-import must answer the question of whether the building was torn down, or vandalism where the mapper wanted to decrease the visibility of a competing business. I don't see the need for any database ID to link the data for future updates since it won't simplify that process. ___ Imports-us mailing list Imports-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports-us
Re: [Imports-us] Seattle Import
On 12/14/13 1:50 AM, Clifford Snow wrote: Eric Fischer got me thinking when he was working on a tiger fix that we need to retain this data for future updates, even if we don't know how to do updates today. Rather than use kingcounty:id, shouldn't we have a consistent method of identifying tags that may be needed in the future? It's possible just using :id is sufficient. However, maybe something like update:id, although that has problems as well. Thoughts? maybe source:id richard signature.asc Description: OpenPGP digital signature ___ Imports-us mailing list Imports-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports-us
Re: [Imports-us] Seattle Import
On Sat, Dec 14, 2013 at 9:29 AM, Jason Remillard remillard.ja...@gmail.comwrote: I don't support importing these id tags. For updates, the optimal identity of an OSM object is a combination of its location, size, and name/address.You don't have to believe me, Paul has perfectly working code that does updates to OSM addresses without a primary db key. Jason, Keeping an id tag does give the advantage that the issuing agency can see if we made changes to it. I really think that OSM can work side by side with government agencies to improve both of our databases. Right now we are mostly just a user of the data. But as we improve and refine the data, ours becomes better. For example, this gives fire departments better house locations so they can improve their data. Collaborating with governmental groups (just as long as they have more than 3 letters that start with N) can give us positive press. That positive press will bring new users to OSM. I do agree that we can easily get by without the source id tag. But my feeling is that for a minimal investment, we can gain some positive benefits. BTW - I need to clear up some confusion. This is only an address import. No buildings. We do have some building outlines, but feel that addresses have a higher priority. We are using NYC suggestion of splitting up the data by voting district. A typical district has 200 to 300 addresses. The biggest has just under 700. -- Clifford OpenStreetMap: Maps with a human touch ___ Imports-us mailing list Imports-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports-us
Re: [Imports-us] Seattle Import
Hi Clifford, Collaborating with governmental groups (just as long as they have more than 3 letters that start with N) can give us positive press. That positive press will bring new users to OSM. I am all for working with the upstream data sources. The technical argument goes both ways, they have to track OSM without their ids if they want to pick up organic changes to OSM after the import. For addresses, everybody should be using the augmented path matching algorithm when trying to compare between OSM and external data sets - http://en.wikipedia.org/wiki/Hopcroft%E2%80%93Karp_algorithm. Thanks Jason ___ Imports-us mailing list Imports-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports-us
Re: [Imports-us] Seattle Import
Indeed, they absolutely lead to problems.
In NYC we've found several problems with IDs already:
1. The IDs that we thought were unqiue are not- some have special magic
values. It turns out two agencies have different IDs for the same
building, and we may have wanted to be using the other one the one we chose.
2. When we conflate a building, it's often the case that the mapper will
have identified different features than the city did. For example, a
building with a garage, the mapper may have identified the garage as a
separate building, but not the city. Now we have to decide which building
gets the ID.
It's a mess. I was against building IDs but other wanted them- I'd have
fought against them harder if it happened again today.
- Serge
On Sat, Dec 14, 2013 at 4:04 PM, Mike N nice...@att.net wrote:
On 12/14/2013 1:31 PM, Clifford Snow wrote:
Keeping an id tag does give the advantage that the issuing agency can
see if we made changes to it. I really think that OSM can work side by
side with government agencies to improve both of our databases. Right
now we are mostly just a user of the data. But as we improve and refine
the data, ours becomes better. For example, this gives fire departments
better house locations so they can improve their data.
What is their test to see if we (OSM?) have made changes? What if an
OSM user corrects the location, or moves it near a better access entrance,
but doesn't touch the ID? In any case, I would think the government
agency's best query would be Give me any address object modified since
{last synchronization date}.
I'll agree with Jason's observation that external IDs in OSM data tend
to discourage corrections and additional contribution by new mappers.
___
Imports-us mailing list
Imports-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports-us
___
Imports-us mailing list
Imports-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/imports-us
