[OSM-talk] Proposed mechanical edit to convert alt_name tags

[Andrew Buck]

-----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-----