Am 28.08.2014 um 23:02 schrieb Xavier Noria:
> On Thu, Aug 28, 2014 at 10:39 PM, Peter Wendorff
> wrote:
>
>> No, it isn't.
>> The interpretation of the database, and the meaning, restricted to the
>> fact of the streets oneway-ness is the same, but no value at all does
>> not say "this is no one
On Fri, Aug 29, 2014 at 9:43 AM, Peter Wendorff
wrote:
> +0.5, as UIs are decoupled from the data in OSM. You may write your own
> editor with a completely different UI, even one that doesn't know about
> oneway at all, so reasoning on UI preferences may help to get the best
> default, but not to
Am 29.08.2014 um 09:58 schrieb Xavier Noria:
> On Fri, Aug 29, 2014 at 9:43 AM, Peter Wendorff
> wrote:
>
>> +0.5, as UIs are decoupled from the data in OSM. You may write your own
>> editor with a completely different UI, even one that doesn't know about
>> oneway at all, so reasoning on UI pref
Hi,
I would like to unify the keys for google-plus-pages of objects in the
Database. In TagInfo I found this variants:
contact:google+
contact:google_plus
link:google_plus
contact:google
Google +
Google Plus
Google+
contact:googleplus
contact:google +
GooglePlus
googleplus
contatc:google+
google
It can be done easily with JOSM, you just need to download all
nodes/ways/relations, select them all and rename the offending tags in one
go.
On Fri, Aug 29, 2014 at 11:39 AM, Andreas Neumann
wrote:
> Hi,
>
> I would like to unify the keys for google-plus-pages of objects in the
> Database. In
Am 29.08.2014 um 11:48 schrieb Éric Gillet:
> It can be done easily with JOSM, you just need to download all
> nodes/ways/relations, select them all and rename the offending tags in
> one go.
I know, how to do it:
1. Download via Overpass
2. Open the file in JOSM
3. Change the keys
But I have to
This all seems sensible, with the exception that I can only ever recall
seeing the former referred to as "Google +", and I think most people will
use the "+" sign.
On Aug 29, 2014 10:39 AM, "Andreas Neumann" wrote:
> Hi,
>
> I would like to unify the keys for google-plus-pages of objects in the
>
I would like to unify the keys for google-plus-pages of objects in the
Database.
I think that's usually fine.
I would like to change the Keys in "contact:google_plus"
change them in "contact:facebook"
I'm not in support of this though. contact: is not commonly used and I
don't think is has
To suggest that we now have to include every possible tag with an
explicit value on every element is just ridiculous: the logical
consequence of an explicit oneway on all ways.
Where there really is a need to remove ambiguity, surely something like
an area or perhaps relation (less obvious to the
The problem is the "+" and the space sign. Both are bad chars for a key.
Maybe someone can tell why.
[http://taginfo.openstreetmap.org/keys/contact%3Agoogle%20%2B]
Andreas
On 29.08.2014 11:57, Andy Mabbett wrote:
> This all seems sensible, with the exception that I can only ever recall
> seein
The character plus (+) is an unusual character for keys indeed.
I believe it's because people usually say x=y + a=b when talking about a
combination of two tags.
2014-08-29 11:36 GMT-03:00 Andreas Neumann :
> The problem is the "+" and the space sign. Both are bad chars for a key.
>
> Maybe some
Good Day,
I am writing to receive additional clarity with regards to using the
'destination%' tag in the context of signposts.
For a while now, the status quo was to use the 'exit_to' tag on the node where
the signpost would be (bifurcation points typically) when representing a
signpost locat
I note that the domain name for Google+ is plus.google.com, so there is
no objection to substituting 'plus' for '+' in some way.
Steve
On 29/08/2014 15:36, Andreas Neumann wrote:
The problem is the "+" and the space sign. Both are bad chars for a key.
Maybe someone can tell why.
[http://tagi
Hi,
I disagree.
Example:
https://plus.google.com/+ConciergeCleanersCo is the same like
https://google.com/+ConciergeCleanersCo
And there are a lot of other URL-schema.
Andreas
On 29.08.2014 19:49, Steve Doerr wrote:
> I note that the domain name for Google+ is plus.google.com, so there is
> no
On 29.08.2014 12:44, Andreas Goss wrote:
>> I would like to unify the keys for google-plus-pages of objects in the
>> Database.
>
> I think that's usually fine.
>
>> I would like to change the Keys in "contact:google_plus"
>> change them in "contact:facebook"
>
> I'm not in support of this thoug
That's as may be. But the widget Google gives you to switch between
their various apps uses a URL beginning https://plus.google.com to
switch to Google+. At least, it does for me.
Steve
On 29/08/2014 19:07, Andreas Neumann wrote:
Hi,
I disagree.
Example:
https://plus.google.com/+ConciergeCle
On Fri, Aug 29, 2014 at 12:26 PM, Kam, Kristen wrote:
> For a while now, the status quo was to use the 'exit_to' tag on the node
> where the signpost would be (bifurcation points typically) when
> representing a signpost location and information. This tag is being
> deprecated (hence this wiki p
FWIW, in my area (northeastern US), "sett" is referred to as "Belgian
block", but most people would indiscriminately refer to both surfaces as
"cobblestone".
--
Chris Hoess
On Sat, Aug 23, 2014 at 2:57 AM, Mateusz Konieczny
wrote:
> How one should tag surfaces:
> - paved with equally sized, f
Why the value description table of
http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway states that
aeroway=taxiway should not be used on areas?
Is there a valid point for this?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openst
On 08/29/2014 10:38 PM, Nelson A. de Oliveira wrote:
Why the value description table of
http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway states that
aeroway=taxiway should not be used on areas?
Is there a valid point for this ?
If you are going to perform airport routing (now that woul
On 08/28/2014 10:49 AM, Dave F. wrote:
I've just looked up common on taginfo & I'm very surprised to see
virtually all are tagged with leisure= (39348). If I ever used it (&
I'm unsure I have) I would have used landuse= (123). I genuinely
believe this is an example of where it being the majorit
I'm using the motorway_junction node on exits, with the ref and the name as
tags. Reasons: it has been done since the early days of OSM, and it looks
nice on Mapnik. I'm also using the motorway_junction up to four times per
interchange to have the name of the interchange appear on Mapnik (example:
On 29.08.2014 20:09, Andreas Neumann wrote:
> I don't want to change the addr:-, website-, phone-, fax- or
> email-key!!! I never said it.
But we have to look at these to decide whether it's better to move
towards the contact namespace as a whole or move away from it. It makes
little sense to move
On 29.08.2014 21:16, Paul Johnson wrote:
> Destinations are supposed to be relations, and the members are pretty
> clear. http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members
I believe Kristen was talking about Key:destination, which is what
should replace exit_to. There are no re
I don't want to change the addr:-, website-, phone-, fax- or
email-key!!! I never said it.
As Tobias pointed out, we have to look at the bigger pucture. Why use
contact: here, when it's not used by the majority anywhere else.
The contact-namespace associate, that the defined facebook- or
goo
On Fri, Aug 29, 2014 at 6:46 PM, Johan C wrote:
> For motorways it's not necessary to know the location of the signposts,
> since every split is signposted (except for some very few exceptions
> maybe).
>
There have been some rather notorious examples where this has not always
been the case. The
On Fri, Aug 29, 2014 at 6:55 PM, Tobias Knerr wrote:
> On 29.08.2014 21:16, Paul Johnson wrote:
> > Destinations are supposed to be relations, and the members are pretty
> > clear.
> http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members
>
> I believe Kristen was talking about Key:d
> the tag
> is used directly (e.g. destination=Exampletown) on the ways leading away
> from a bifurcation, and/or in the form of destination:lanes (e.g.
> destination:lanes=Exampletown|
> Foobarcity) on the way leading towards the
> bifurcation.
Thanks for this explication! I was always in doubt
28 matches
Mail list logo
