Or would it be better – if a consens is difficult – to wait until a general
resolution for the problem “one key with more than one value” has come up?
Lukas Sommer
2014-11-29 5:03 GMT+00:00 Brian Quinion openstreet...@brian.quinion.co.uk:
On 29 Nov 2014 00:26, Lukas Sommer sommer...@gmail.com
On 29/11/2014, Lukas Sommer sommer...@gmail.com wrote:
Okay. I’ll try a summary:
[...]
Thanks for those insights.
Note that this multiple-values discussion has gone beyond the alt_name
key (which is itself a multiple-value key for the name key, making
'multiple alt_name values' kind of silly),
Okay. I’ll try a summary:
We have the choise between two systems:
– semicolon system
– alt_name_1 system
(Other versions like alt_name:1 or alt_name1 seem to be not interesting and
have very little occurence in the database, probably errors during the HOT
imports).
Both have its advantages
On 29 Nov 2014 00:26, Lukas Sommer sommer...@gmail.com wrote:
Okay. I’ll try a summary:
We have the choise between two systems:
– semicolon system
– alt_name_1 system
I added support for alt_name_1 because this kept coming up and people were
actively abusing alt_name:1 because it happened
Friedrich Volkmann wrote on 2014-11-27 03:38:
On 26.11.2014 18:23, Brian Quinion wrote:
At the moment nominatim supports
alt_name_[0-9]+:language_code=name
for alt names
I've added this to the wiki
Please don't document values supported by single applications. The wiki
should represent
Big +1 for that.
To me, solving it from the root means formalising the use of the
semicolon as a value separator, and cracking some hard nuts like how to
handle a legitimate semicolon in the data itself and how to handle the
quoting/escaping that that will involve.
But let's do it once and
On 27/11/2014, Colin Smale colin.sm...@xs4all.nl wrote:
Big +1 for that.
-1.
On what do you base your assumption that nominatim is the only
software implementing numbered keys ? How is documenting what a major
osm software does a bad thing ? For better or worse, the numbered keys
scheme sees a
2014-11-27 12:59 GMT+01:00 moltonel 3x Combo molto...@gmail.com:
Either the
data user forgets to do the split, or he does it when it wasn't the
mapper's intent, or litteral semincolons in the data get in the way.
Yes, formally introducing the semicolon practise will force data consumers
to
On Thu, Nov 27, 2014 at 12:59 PM, moltonel 3x Combo molto...@gmail.com
wrote:
alt_name is already a way to encode 1
additional value for the name key, so if you're describing a scheme
to add any number of additional values, apply this scheme to name
and not alt_name.
+1
An ideal(?) scheme
2014-11-27 13:43 GMT+01:00 althio forum althio.fo...@gmail.com:
An ideal(?) scheme would apply to name=* so that:
[name+1]=* is equivalent to alt_name=* and
[name+2]=* is equivalent to alt_name_1/alt_name:1/alt_name1/[alt_name+1]=*.
The same scheme should also apply to old_name=* because you
So the root problem is how to support multi-valued keys.
Using the semicolon puts the solution into the value, using numbered
keys puts the solution into the keys. As (AFAIK) both the keys and the
values are limited to 255 chars, I can see that being a limitation for
value-based solutions.
On 27 November 2014 at 11:59, moltonel 3x Combo molto...@gmail.com wrote:
To me, the semincolon scheme as a general solution is a very bad idea,
Either the data user forgets to do the split, or he does it when it wasn't the
mapper's intent, or litteral semincolons in the data get in the way.
On 27/11/2014, Martin Koppenhoefer dieterdre...@gmail.com wrote:
2014-11-27 12:59 GMT+01:00 moltonel 3x Combo molto...@gmail.com:
Either the
data user forgets to do the split, or he does it when it wasn't the
mapper's intent, or litteral semincolons in the data get in the way.
Yes, formally
On 27/11/2014, Andy Mabbett a...@pigsonthewing.org.uk wrote:
On 27 November 2014 at 11:59, moltonel 3x Combo molto...@gmail.com wrote:
To me, the semincolon scheme as a general solution is a very bad idea,
Either the data user forgets to do the split, or he does it when it wasn't
the
On Wed, Nov 26, 2014 at 6:23 PM, Brian Quinion
openstreet...@brian.quinion.co.uk wrote:
On 25 November 2014 at 13:30, althio forum althio.fo...@gmail.com wrote:
I don't even know which keys are currently under use by Nominatim and
other
data consumers and how that could evolve in the
On 25 November 2014 at 13:30, althio forum althio.fo...@gmail.com wrote:
I don't even know which keys are currently under use by Nominatim and other
data consumers and how that could evolve in the future.
At the moment nominatim supports
alt_name_[0-9]+:language_code=name
for alt names
I've
On 26.11.2014 18:23, Brian Quinion wrote:
At the moment nominatim supports
alt_name_[0-9]+:language_code=name
for alt names
I've added this to the wiki
Please don't document values supported by single applications. The wiki
should represent values which are in use in the database, or
On 24.11.2014 22:54, fly wrote:
Do we recommend any order ? youngest to oldest ?
name=most common name
alt_name=second most common name;third most common name;...
...because data consumers certainly use these in the same order. Two examples:
1) Rendering: Say, there's space for one alternative
2014-11-25 14:09 GMT+01:00 Friedrich Volkmann b...@volki.at:
On 24.11.2014 22:54, fly wrote:
Do we recommend any order ? youngest to oldest ?
name=most common name
alt_name=second most common name;third most common name;...
...because data consumers certainly use these in the same order.
On Sun, Nov 23, 2014 at 6:20 PM, Lukas Sommer sommer...@gmail.com wrote:
I think it could be useful to have a clear documentation on the wiki about
which solution is the preferred one.
Oh yes! I would appreciate clear and explicit documentation on this one!
On Mon, Nov 24, 2014 at 11:51 PM,
Also, parsing a semicolon-delimited string into an array of strings is a simple
task in most programming languages.
On November 24, 2014 5:35:21 PM CST, Frederik Ramm frede...@remote.org wrote:
Hi,
On 11/24/2014 11:51 PM, Tobias Knerr wrote:
The semi-colon is not universally accepted, for
Okay, so I would place a hint at the corresponding wiki page …
Lukas Sommer
2014-11-23 18:46 GMT+00:00 Zecke z...@saeuferleber.de:
Am 23.11.2014 18:20, schrieb Lukas Sommer:
Would a feature proposal be a good way to get there?
No need to do so. The semi-colon is the accepted way to
Am 24.11.2014 um 20:32 schrieb Lukas Sommer:
Okay, so I would place a hint at the corresponding wiki page …
+1
Do we recommend any order ? youngest to oldest ?
2014-11-23 18:46 GMT+00:00 Zecke z...@saeuferleber.de
mailto:z...@saeuferleber.de:
Am 23.11.2014 18:20, schrieb Lukas Sommer:
On 23.11.2014 19:46, Zecke wrote:
Am 23.11.2014 18:20, schrieb Lukas Sommer:
Would a feature proposal be a good way to get there?
No need to do so. The semi-colon is the accepted way to separate multi
values in cases where there's no other scheme defined.
Hi,
On 11/24/2014 11:51 PM, Tobias Knerr wrote:
The semi-colon is not universally accepted, for good reasons. Contrary
to what you said, it should only be used if it is explicitly defined as
an option for that particular key. To introduce such a convention to an
old and widely used set of
+1
I agree with alt_name=name1;name2
On Mon, Nov 24, 2014 at 1:20 AM, Lukas Sommer sommer...@gmail.com wrote:
Some time ago, there was a discussion on the “talk” mailing list about how
to deal with the situation of more than one alt_name:
Hi,
On 11/25/14 00:35, Frederik Ramm wrote:
There was a discsussion on the talk/imports lists recently (September,
Duh. I should have read Lukas' post before writing ;)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33
Am 23.11.2014 18:20, schrieb Lukas Sommer:
Would a feature proposal be a good way to get there?
No need to do so. The semi-colon is the accepted way to separate multi
values in cases where there's no other scheme defined.
http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
Cheers,
28 matches
Mail list logo
