Consolidation seems fine, if there is a better tagging scheme that arise
meanwhile, it will be easier to change.
Yves
On 8 septembre 2014 22:12:25 UTC+02:00, Andrew Buck <andrew.r.b...@gmail.com>
wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Responses inline...
>
>
>
>On 09/08/2014 02:53 PM, Frederik Ramm wrote:
>> Hi,
>>
>> I think using alt_name:1 was not the greatest idea at the time.
>>
>> So you have a
>>
>>> hand-picked team of people using private task manager jobs so
>>> that the work is done carefully and no one just "blindly" dumps a
>>> load of data in without first checking it.
>>
>> but you can't be bothered to discuss with the wider OSM community
>> how to best address the multiple alternative name issue; instead
>> you pick something that works by accident.
>>
>> Then you plan to "make it right" by using the unprecedented and
>> illogical scheme of "alt_name_x", and before you discuss the issue
>> with people who might help you devise a better way, you ask the
>> Nominatim maintainer to add a quick patch for you.
>
>Yes, we are using what GNS has for the various alt_name entries. We
>are checking each place name against 3 different sets of topographic
>maps and have seen some of these spelling variants on the various maps
>and when we do see them they agree nicely. Additionally, the alt_name
>variants have proved to be used in various places like news reports
>and field reports from medical workers in the area so they seem to be
>good data, at least as far as we can tell. The scheme is not
>unprecedented, it was already in use in the database (which is why we
>adopted it) and I don't see how it is illogical, it seems like the
>obvious thing to me.
>
>> alt_name_x sounds like a bad idea to me as well - why is there an
>> alt_name_x but no old_name_x or official_name_x for when something
>> has two old names or two official names? The patch that has been
>> suggested for osm2pgsql
>>
>>
>https://github.com/openstreetmap/osm2pgsql/commit/29ccee0859fa4728378d7299e9deeab737da347d
>>
>> simply accepts alt_name_whateversomething but doesn't afford the
>> same to other name tags. Is this matter really so urgent that we
>> have no time to think it through?
>
>I would suspect that it just hasn't come up for old_name and such. I
>am sure there are cases of this but since there aren't that many
>old_name's to begin with there probably just hasn't been much of a
>need for it. A similar patch for the others might make sense if they
>are used, but I just don't think it has been an issue so far. Looking
>at taginfo shows 31 old_name_2 and 39 old_name:2 so it is there but
>not enough to have encountered problems due to how rarely it exists,
>hence no patch for it so far. If we want to discuss those as well
>(and consolidating them in a similar fashion) then I am fine with
>that, but for expediency's sake I would like to get these sorted out
>so they are consistent first.
>
>>> (with the 2 extending to higher numbers as well, some of these
>>> places have as many as 6 or 7 alt_name entries).
>>
>> Do the people who carefully add the data have the knowledge to
>> assert whether keeping these 6 or 7 names really adds value, or are
>> they instructed to simply copy whatever GNIS has?3
>
>As I outlined above, we are keeping them as they are; they seem to be
>in good agreement anytime we are able to check them so there is no
>reason to be distrustful of the ones we don't have alternate sources
>for.
>
>>> Thank you for your consideration in this matter, and I would ask
>>> that we try to expedite the discussion on this
>>
>> Missing - or expedited - discussion has got you into this
>> situation. You're now trying to introduce a badly thought out
>> schema on the quick; a change to our instance of Nominatim would
>> make things worse by actually encouraging people to use this.
>>
>> I am very unhappy with the whole process and I can only hope it's
>> the exception not the rule.
>
>It has been discussed in great detail just not on the global mailing
>lists. I am sorry we made a small mistake regarding the tag fields,
>but we have caught it now and are trying to correct it.
>
>- -AndrewBuck
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.11 (GNU/Linux)
>
>iQIcBAEBAgAGBQJUDg2kAAoJEK7RwIfxHSXb1qwP/1BzOs154u+LQToHI4n6n3S+
>u0Eepu2/W+H5GyfLD7otvvB/f5G4wjVal0BPk0cdgA6XjQyxx02u1/l7XqiM1zyG
>IlcDunAhIXkjd4AxwKaqWSXaMzuS8wNy+9OoobjEclLg5vin4Gjbl8+V70elWz9g
>yl33zcasYqMynOGw+v68sVbgoGJGQwDab1qTYcO+VZJXAbG4bVrc/gaZBJzojU+B
>kOUnMu/cYnH6g8S3ViGOAAKpqhEXJ9GPAMS8BoBFDIRRtq9Qh4bCx6cfROVOJ3QQ
>JFMc4wAg4bRuOthIWwA5znhhD/KGATj/Y1/T+qPRTt6uMvHkxBoun+91ljrRpo0V
>QuQ+l+8blktqSwzKO05q8xhgfFR/U+cojuPU5C5qz2MsHoXgslufvscEC8go4X+3
>JRgrF1Z6iDmHnAQt98300G8ju3/CxpI32ZokHVaUrcx6wJGeBdcQJX3NdQO7AyXA
>WsKtZ0suCHlIvGlgvBwCyXx1CaqQHRMyXC3PQ/At3KbVPdcDL/WoZmsOFfG6skka
>oIsa5lKnuhbVCq05Xes8KVwWF2YeWd9zuib0yDeD1NUim568t01LQ98rl6E3Uxq2
>cTaP9lWfryCGX2xi9Djno6H+ld6FG2MsesJgcuFoGQR/0hIjQTL+ldqSOKYmQyfn
>LMibzQjrYmQ7n584VGxj
>=bqwg
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
--
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
