On Sat, Nov 15, 2014 at 7:27 PM, Bryce Nesbitt wrote:
> On Fri, Nov 14, 2014 at 10:51 PM, Marc Gemis wrote:
>> Maybe they are sometimes tagged in another way as shop=bicycle +
>> service:bicycle:repair=yes and service:bicycle:retail=no
>> (see http://wiki.openstreetmap.org/wiki/Tag:shop=bicycle?
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]+:=
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 u
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 o
On 27/11/2014, Colin Smale 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 good bit of use accor
2014-11-27 12:59 GMT+01:00 moltonel 3x Combo :
> 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 look for it, or
On Thu, Nov 27, 2014 at 12:59 PM, moltonel 3x Combo
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 would a
2014-11-27 13:43 GMT+01:00 althio forum :
> 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 can get
> several
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 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.
Could you provi
On 27/11/2014, Martin Koppenhoefer wrote:
> 2014-11-27 12:59 GMT+01:00 moltonel 3x Combo :
>> 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 practi
I have a question about creating custom road shields, and I know this ties into
-carto - but I think it needs tags to work, so I’ll start here in the tagging
list.
I was thinking of a method for adding custom badges or shields to roads and
generic objects - usually country specific things, suc
On 27/11/2014, Andy Mabbett wrote:
> On 27 November 2014 at 11:59, moltonel 3x Combo 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 semincolon
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 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 m
If I recall correctly from a discussion on the Talk-us list a while back, the
preferred way in the US is now to specify the shield in a route relation. I did
not follow the discussion fully but my impression is that the tagging allowed
for custom specification of the shield. It looks like
https
On 11/27/14 10:39 AM, Tod Fitch wrote:
If I recall correctly from a discussion on the Talk-us list a while back, the
preferred way in the US is now to specify the shield in a route relation. I did
not follow the discussion fully but my impression is that the tagging allowed
for custom specific
I think having it on the relation is a great idea, especially since adding the
tags to all the road segments sounds like an insane amount of tagging . Is this
something that we should ask Phil to create a formal proposal page for the
tags, so we can start adding symbol key values to relations? I
On 11/27/14 6:48 PM, johnw wrote:
I think having it on the relation is a great idea, especially since
adding the tags to all the road segments sounds like an insane amount
of tagging . Is this something that we should ask Phil to create a
formal proposal page for the tags, so we can start addin
Why not just compose this from the network tag on the relation? I'm almost
certain that was one of the motivating factors to going to route relations
in the first place.
On Thu, Nov 27, 2014 at 7:48 AM, johnw wrote:
> I have a question about creating custom road shields, and I know this ties
>
> On Nov 28, 2014, at 9:53 AM, Richard Welty wrote:
>
> On 11/27/14 6:48 PM, johnw wrote:
>> I think having it on the relation is a great idea, especially since adding
>> the tags to all the road segments sounds like an insane amount of tagging .
>> Is this something that we should ask Phil to
19 matches
Mail list logo
