Re: [Tagging] Positioning motorway exits

2017-03-08 Thread Johan C
I just took another look at several exits in Germany. As in the past I
found out that the OSM standard is to have the motorway_junction to the
link road before or at the legal point to transition. This is perfectly in
line with the motorway_junction page, which states: 'Add a highway
=*motorway_junction* tag
at each node [image: Node]
 along a highway with
named or numbered junctions where a driver can legally exit'.

So we already WIKIed a communis opinio

2017-03-08 18:42 GMT+01:00 Colin Smale :

> Navigation systems, including commercial ones, mostly count down to the
> LAST point - where the white triangle or lines make it illegal for you to
> transition. This is in line with the wiki and current OSM
> practice. Countdown signs on the approach to an exit however go to zero at
> the FIRST point you can join the exit lane. People may expect, or prefer,
> one or the other. Let's make sure we can accommodate both.
>
> //colin
>
>
>
> On 2017-03-08 18:33, Volker Schmidt wrote:
>
> At present we have many different approaches out in the field, which make
> life difficult to any routing software.
> I notice that we have another option, which I have not seen implemented in
> the database,  i.e. to place the exit tag on the highway at the position of
> the  last corresponding road sign before the actual split. This would
> require on-the ground knowledge or Mapillary/OpenStreetCam photos. It would
> also mean that the exit tag is not necessarily on the actual road split on
> the map. And it would require a lot of retrofitting work based
> on-the-ground checks.
> It would be in line with the wiki for "highway=motorway_junction", which
> states "This node should be positioned as the last point before the splay
> at which it is still possible to make a smooth turn."
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Positioning motorway exits

2017-03-07 Thread Johan C
Well, the WIKI more or less has a sort of consensus. Yes, we do have the
divided highways ('baulicher trennung'). But there is also the consensus
that it's important to make sure the requirements for navigational devices
like OSMAND should also be met. So, if the physical point is used by a
mapper some extra tagging is needed to show the legal point for the exit.
And the routers should then be altered to handle the extra tagging. OSM is
no toyland anymore, people (like myself) are more and more relying
on reliable OSM data for navigational purposes.

An example for Belgium shows the motorway_junction node way too early:
https://www.openstreetmap.org/?mlat=50.86948=4.48244#map=18/50.86948/4.48244=N
But that's safer for driving than having it too late.

Cheers, Johan


2017-03-07 15:45 GMT+01:00 Jo :

> Extra credit if we can come up with a 'universal' solution :-)
>
> Polyglot
>
> 2017-03-07 10:44 GMT+01:00 Volker Schmidt :
>
>> This touches on a "conflict of interest" between two requirements:
>> (1) OSM tagging practice is to map only physically separated ways as
>> separate ways in OSM.
>> (2) A routing algorithm needs to have information about legally separated
>> ways, e.g. by a continuous white line.
>>
>> In the specific case the exit for the routing algorithm is at the
>> beginning of the continuous white line, i.e node
>> https://www.openstreetmap.org/node/4337339247
>> whereas the split of the ways according to the rule of the separate ways
>> puts it at node https://www.openstreetmap.org/node/370544/, where the
>> motorway junction is placed at the moment.
>>
>> To my knowledge there is no agreed upon common practice.
>>
>> I do not map motorways in Germany, but have mapped motorways and trunk
>> roads in Italy where we have no established common approach, and you can
>> find a nice mix of different approaches. I think we should come to a
>> general best-practice or best-practices agreement. This may imply
>> country-dependent recommendations.
>>
>>
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Positioning motorway exits

2017-03-06 Thread Johan C
370544 is the one.

2017-03-07 0:53 GMT+01:00 Warin <61sundow...@gmail.com>:

> 10 nodes on that changeset - 6 were deleted .. one is a new node (as
> indicated by its version number, leaving a choice of 3
>
>
>- 3236281590, v3 <http://www.openstreetmap.org/node/3236281590>
>- 3236281562, v2 <http://www.openstreetmap.org/node/3236281562>
>- Kreuz Köln-Süd (370544, v13)
><http://www.openstreetmap.org/node/370544>
>
> So the question is which node ... the answer should contain the number of
> one of the above nodes.
>
>
> On 07-Mar-17 10:20 AM, Johan C wrote:
>
> The motorway_junction node of the A4 towards A555, which was moved
> westwards by 100 meters.
>
> 2017-03-07 0:02 GMT+01:00 Paul Johnson <ba...@ursamundi.org>:
>
>> Which node?
>>
>> On Mon, Mar 6, 2017 at 4:39 PM, Johan C <osm...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm in a discussion with a user who positions the motorway exit in a,
>>> IMHO, uncommon way. Though it's not uncommon for OSM to have multipiple
>>> solutions for the same problem I would like to have your opinion on this
>>> one: http://www.openstreetmap.org/changeset/41264608
>>>
>>> Kind regards, Johan
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Positioning motorway exits

2017-03-06 Thread Johan C
The motorway_junction node of the A4 towards A555, which was moved
westwards by 100 meters.

2017-03-07 0:02 GMT+01:00 Paul Johnson <ba...@ursamundi.org>:

> Which node?
>
> On Mon, Mar 6, 2017 at 4:39 PM, Johan C <osm...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm in a discussion with a user who positions the motorway exit in a,
>> IMHO, uncommon way. Though it's not uncommon for OSM to have multipiple
>> solutions for the same problem I would like to have your opinion on this
>> one: http://www.openstreetmap.org/changeset/41264608
>>
>> Kind regards, Johan
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Positioning motorway exits

2017-03-06 Thread Johan C
Hi,

I'm in a discussion with a user who positions the motorway exit in a, IMHO,
uncommon way. Though it's not uncommon for OSM to have multipiple solutions
for the same problem I would like to have your opinion on this one:
http://www.openstreetmap.org/changeset/41264608

Kind regards, Johan
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [Talk-us] destination:street

2017-01-22 Thread Johan C
2017-01-22 22:32 GMT+01:00 yo paseopor :

> I need help. How to tag a roundabout destination traffic sign
> https://www.mapillary.com/map/im/6bMYhgICHVBL_H70ZnyPAg ? With
> correspondence it is easy (for me), but I don't know how to do it with
> multiple values.
>
>
Please check it out (in JOSM for example). A bit strange, but the motorway
exit had an exit_to instead of a destination. I added the destination to
it. And the symbol as a separate value.


> Also I hope OSM people will advise strongly Finnish people as they are
> using suffixed tags..
>
> And at last but not least Mapbox Streets will need help to process
> correctly all the information of OSM without cropping some information.
>
> Cheers (Salut i senyals)
> yopaseopor
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [Talk-us] destination:street

2017-01-22 Thread Johan C
I don't like your idea yopaseopor.

Why:
1. It's not forbidden to use a semicolon: 'But there are cases where
semicolons work and, anyway, we can’t completely avoid them. Let’s work on
defining our data model better and make it clearer where those semicolons
can and should be used and how they are to be interpreted.'
(*https://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html
) *

2. As you think it's more easy to use destination1=* for newbies, I think
it's way more complicated, since 1 has no meaning. And it creates
confusion: you might use destination1, others destination_1, and some
others destination:1

3. As pointed out here:
https://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki
name_1 suffixed name tagging for multiple values is deprecated

4. The semicolon in destinations, and refs, are already in use for quite a
long time. So what you are proposing creates (again) multiple tagging
systems in OSM to solve the same challenge.

5. Any renderer can make a split, simply by checking for the semicolon.

Cheers, Johan

2017-01-22 11:09 GMT+01:00 yo paseopor :

> It's true, but OSM wiki, the tool people like me who tries to learn how to
> do something uses says that: https://wiki.openstreetmap.org/wiki/Semi-
> colon_value_separator#When_NOT_to_use.
> Change the wiki please if it is not.
>
> Wiki explains
>
> "In general *avoid ';' separated values whenever possible*. Don't use
> them in your mapping, and don't propose them on the wiki if there are
> better ways of representing things. This is because use of semi-colons as
> value separators is contrary to the aim of *keeping it simple* both for
> data *contributors* (mappers) and data *users*. For the sake of new
> contributors and anyone trying to *use* the data (people building
> software for rendering, searching, "find my nearest cafe" mobile apps, etc)
> we should minimise use of values with special characters.
>
> It is particularly important to (wherever reasonably possible) avoid ';'
> separated values in more important "top-level" tags. That is, tags which
> define what an element is." Is not Destination value also so important?
>
>
> Also there's some software who...does not support semicolon:
>
>
> "Mapbox Streets
> 
>  replaces ; with a spaced em dash ( — ) in any name
> =* or name:*
> =* tag. For primary keys
> such as amenity =* or
> shop =*, it considers only
> the portion up to the first semicolon and drops the rest."
>
>  I think dropping data is not a good way of working with OSM :(
>
>
> Taginfo says also there's some destination:x in Germany. For example
> http://taginfo.openstreetmap.org/keys/destination%3A1
>
> http://taginfo.openstreetmap.org/keys/destination%3A2
>
> http://taginfo.openstreetmap.org/keys/destination%3A3
>
> and so on...
>
> Also if you see the list in taginfo about destination values you will see
> only two in top20 list (well ,one is with comma so also there's some
> problems of standarization)  from the most tagged values: http://taginfo.
> openstreetmap.org/keys/destination#values
>
> And if you search top100 list there are only 12 values with semicolon , 2
> with comma . All these values together are only 1792 tagged values...from
> 71665 total values.
>
>
> I think one tag one value it is the best standard for traffic signs also
> to make it easier for the begginners and newbies.
>
>
> Cheers (Salut i senyals)
>
> yopaseopor
>
>
>
>
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [Talk-us] Freeway exit tagging

2016-08-26 Thread Johan C
It is quite simple, If there is a through arrow, the value is through. If
there is no arrow, the value is none. Groundtruth mapping!

Cheers, Johan

2016-08-26 15:41 GMT+02:00 Paul Johnson :

> On Fri, Aug 26, 2016 at 8:19 AM, yo paseopor  wrote:
>
>> I think you can specify the information you know instead this information
>> is not explicit written on the road. So for me , in my opinion it is better
>> specify through or whatever will be the direction that none or   |" "
>> (blank) or something like that.
>>
>
> Agreed.  If you know (either by regional context/knowledge or by markings
> visible) the turns, go ahead and tag it as the explicit direction.  I
> suggest the "none" tag be used for lanes that don't go anywhere for some
> reason (rare, but consider a permanently closed lane) and a null answer
> when it's not clear which way the lane goes (armchair mapping in an
> unfamiliar region, for example).
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Turn Lane Tagging?

2016-06-11 Thread Johan C
In that case they also missed the examples on the same page :-)
Op 11 jun. 2016 20:04 schreef "Mike N" <nice...@att.net>:

> On 6/11/2016 12:00 PM, Johan C wrote:
>
>> I completely agree with Marc. Using none as a value in case no turn
>> indication is present is valid, using || isn't. See the values of the
>> turn:lanes key on this page:
>> http://wiki.openstreetmap.org/wiki/Key:turn:lanes for reference.
>>
>
>   And I just realized that the editors may have interpreted the word
> 'none' as nothing/blank (no text required).
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Turn Lane Tagging?

2016-06-11 Thread Johan C
I completely agree with Marc. Using none as a value in case no turn
indication is present is valid, using || isn't. See the values of the
turn:lanes key on this page:
http://wiki.openstreetmap.org/wiki/Key:turn:lanes for reference.

Cheers, Johan



2016-06-11 7:44 GMT+02:00 Marc Gemis :

> I must admit I have never seen none;slight_right in any of the lane
> tagging.
> None is only used in cases where there are no arrows on the ground for
> that particular lane. Furthermore empty is also not a valid value.
> Empty is only valid in e.g. maxspeed:lanes to indicate that the lane
> has the default value set by maxspeed. Since there is no default
> defined for turn:lanes, one has to specify a value for each lane.
>
> Please take a look at
>
> https://wiki.openstreetmap.org/wiki/User:Dex2000#zeitliche_Auswertungen_Overpass-turbo-abfragen
> It contains several OverPass queries for the validation of turn:lanes
> (the page is in german, but search for turn:lanes)
> Those queries were used by the German community for their week
> assignment on turn:lane mapping.
>
> In order to express that 1 lane becomes 2 lanes, one could use the
> proposal http://wiki.openstreetmap.org/wiki/Proposed_features/transit,
> unfortunately imagic is no longer active on OpenStreetMap.
>
> regards
>
> m ( a heavy lane mapper from Belgium).
>
> On Sat, Jun 11, 2016 at 6:00 AM, Bryan Housel 
> wrote:
> > Thanks James for the explanation, it does make sense now. I hope I wasn’t
> > the only person confused to see that tag..
> >
> > I appreciate all the work that you’ve put into adding lane details OSM.
> My
> > goal is to make lane tagging easy for everyone.
> >
> > That said, I think you might be the only person in the world tagging turn
> > lanes with `none;something`.  I checked taginfo and it seems like for
> value
> > combinations like `left;none` there are around 5 in the world.  Yes, that
> > count is off because Mapbox data team deleted some of yours and they
> > shouldn’t have, and it’s great that they apologized, but still we are
> > talking about something that looks kind of like an error and hasn’t been
> > discussed anywhere that I can find.
> >
> > For what it’s worth, I have also seen a few people suggest tagging like
> > `width:lanes:start = 4|0`  `width:lanes:end = 4|4` (e.g. in meters) to
> > describe the shape of that segment of road that widens into the turn
> lanes.
> > Taginfo also suggests that this is used like 10 times in the whole world,
> > and I also haven’t found it discussed anywhere.
> >
> > Maybe this is a situation where the tagging list can discuss and come to
> > consensus and do the whole wiki proposal voting thing?
> >
> > We still have several months before the turn lane tagging will be
> available
> > in iD, so there is plenty of time to work out these details.  In the
> worst
> > case, we just won’t support it, and instead show a ‘?’ in the interface
> to
> > indicate that there is some unrecognized tag in that lane and we will
> leave
> > it alone.
> >
> > Thanks, Bryan
> >
> >
> >
> >
> > On Jun 10, 2016, at 10:16 PM, James Mast 
> wrote:
> >
> > I've been using the "turn:lanes:*=none;slight_right" & "slight_left;none"
> > tags to indicate which side a new lane has been added on a highway when
> > going from 1 to 2 lanes (sometimes "slight_left;slight_right" if the
> > original lane is centered between the two new lanes).  How else are
> people
> > to properly identify which side the new lane is being added to?  Take a
> look
> > at this way ( https://www.openstreetmap.org/way/419799887 ) and take a
> look
> > at the Bing imagery and look at the 'turn:lanes:forward' tag, and you'll
> see
> > how this can, and would be valid.  It's allowing the router to know that
> a
> > new lane is being added when combined with the next way
> > (https://www.openstreetmap.org/way/419799886 ) which has the
> > "lanes:forward=2" tag.  It also allows the routers to properly tell
> people
> > to get in the left lane if just ahead, there's a left turn they need to
> > make.
> >
> > 
> > From: Tod Fitch 
> > Sent: Friday, June 10, 2016 9:45:56 PM
> > To: Tag discussion, strategy and related tools
> > Subject: Re: [Tagging] Turn Lane Tagging?
> >
> > I haven’t seen “none;slight_right” as a value and am not sure how that
> > should look different than “slight_right” by itself. However “none” is a
> > value listed in the wiki [1] and I use it a lot as I find multiple
> vertical
> > bars hard to manually count/edit but I can see and count things like
> > “left|none|none” easier than “left||” when editing in JOSM.
> >
> > [1] https://wiki.openstreetmap.org/wiki/Key:turn#Turning_indications
> >
> > -Tod
> >
> >
> > On Jun 10, 2016, at 6:07 PM, Bryan Housel  wrote:
> >
> > Hey James,
> >
> > (Disclaimer:  I work for Mapbox, but I am not part of the team that is
> doing
> > the 

Re: [Tagging] Deprecation of associatedStreet-relations

2015-01-25 Thread Johan C
2015-01-24 1:07 GMT+01:00 Christian Quest cqu...@openstreetmap.fr:


 Le 22/01/2015 22:49, Johan C a écrit :
  Good to have this discussion. From a computer expert point-of-view
  relations are fantastic for data integrity and to keep database size
  low. From an OSM point-of-view, which includes being friendly towards
  novice users, relations should be avoided whenever possible. And
  associatedStreet relations are avoidable.

 A novice user will hardly break an associatedStreet relation, but will
 more often break addr:* when updating a streetname without updating
 related addresses.


In my experience it's quite rare that streetnames change. But indeed, some
programs like mkgmap rely on matching addresses to streets based on names,
so these (rare) changes will create errors for renderers using the same
technique mkgmap does.

It is much harder to detect the second at the QA level.


It's not. Geofabrik Inspector is very precise, even with upper and lower
capitals:
http://tools.geofabrik.de/osmi/?view=addresseslon=2.27745lat=48.83361zoom=12overlays=street_not_found


 If simplicity is our new mantra, who will be the first propose to
 deprecate the public_transport relation based tagging scheme ?


I didn't use the word simplicity in my previous posting. Though the KISS
principle could be applied on relations. When I started mapping it took me
about 6 months to understand the idear of relations and when they had to be
applied in OSM. In these six months I had already mapped dozens of POI's
including full address info. Which, from an associatedStreet point-of-view,
is wrong mapping.

The thing with relations is that logically everything relates to other
things. A POI inside a building relates to that building, the lantern and
the tree in front of that building relate to a street, the building itself
relates to a street, a street relates to a neighbourhood, a neighborhood
relates to a city, a city relates to a country and a country relates to a
continent. Logically all these relations should be built manually into OSM,
that is if one loves relations. Out of that logical string one (why one?)
is chosen to be good for mapping addresses: associatedStreet.

The situation is black and white: for addresses it's not necessary to use
relations, so associatedStreet can be deprecated. In cases like a bus route
and a turn restrictions it's impossible not to use a relation to achieve a
certain goal (like good routing), so these are examples where relations
need to be kept. I don't have any problem keeping OSM simple when it can be
kept simple. Not for me as an experienced mapper, but for the mappers OSM
will attract in the coming years.

Cheers, Johan

--
 Christian Quest - OpenStreetMap France


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deprecation of associatedStreet-relations

2015-01-22 Thread Johan C
Good to have this discussion. From a computer expert point-of-view
relations are fantastic for data integrity and to keep database size low.
From an OSM point-of-view, which includes being friendly towards novice
users, relations should be avoided whenever possible. And associatedStreet
relations are avoidable.

Cheers, Johan

2015-01-22 21:46 GMT+01:00 Michael Reichert naka...@gmx.net:

 Hi,

 Am 2015-01-22 um 16:14 schrieb Vincent Pottier:
  Le 22/01/2015 14:00, althio a écrit :
  Hi all - does anyone know what the geographic distribution of
  associatedStreet is like? taginfo doesn't render a map (it seems it
  doesn't do that for relations).
  UK http://taginfo.openstreetmap.org.uk/tags/type=associatedStreet
 ~9000
  PL http://taginfo.openstreetmap.pl/tags/type=associatedStreet ~1700
  CZ /tags/type=associatedStreet ~ 100
  HU http://taginfo.openstreetmap.hu/tags/type=associatedStreet ~ 130
  SE http://se.taginfo.openstreetmap.se/tags/type=associatedStreet 
 900
  RU http://taginfo.openstreetmap.ru/tags/type=associatedStreet 1850
  FR is down
  No stats for DE
  This shows a map, I don't know if this is what you are looking for:
  http://taginfo.openstreetmap.org/tags/type=associatedStreet#map
 
 
 http://taginfo.openstreetmap.org/tags/type=associatedStreet#combinations
  also shows that
  61 307 / 218 176 = 28.10% are also tagged with ref:FR:FANTOIR=*
  so from France.
  28 % at least !

 Overpass-API results for Germany (count function which is marked as
 experimental): 48.732 relations (I did not count their members)

 housenumbers in Germany total (including those which belong to
 associatedStreet relations): 7.762.395 [1]

 For comparison, number of addr:housenumber (number of associatedStreet
 relations in brackets, copied from above) in
 United Kingdom: 840 437 (9000)
 Poland: 5 173 771 (1700)
 Czech Republic: 2 824 442 (100)
 Hungary: 64 276 (130)
 Sweden: 341 533 (900)
 Russia: 2 444 832 (1850)

 [1] data from 2015-01-11, user Gehrke,

 https://wiki.openstreetmap.org/wiki/User:Gehrke#Entwicklung_des_Adressbestandes

 Best regards

 Michael


 --
 Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Overhead signs (Überkopfwegweiser)

2015-01-19 Thread Johan C
2015-01-16 10:19 GMT+01:00 Andreas Labres l...@lab.at:


 To map:
 Put a node on the way of the street exactly where the sign is located
 and tag it something like this:

 overhead-sign=|| Brno, Gänserndorf, Stadlau [A23]; | Praha [A23]; / Kagran
 [B3];
  Ölhafen Lobau

 * with the arrows represented by:

 |     up arrow
 /     slight right arrow
      turn right arrow
 \     slight left arrow
      turn left arrow

 * the text indicates the text that is written on the sign
   (the text should match any destination= tags given on exits)

 * refs are given within square brackets [...]

 * a semiconlon ; separates the arrows

 This gives a router the possibility to show a drawing of
 the sign, depending on the direction:



 Of course this should match the information given in any lane tags,
 but it gives the exact position of the sign and it works without
 the need of lane tags! That way it should be much easier for
 routing app developers to implement hints which lane to use.


I prefer the existing destination:lanes and turn:lanes tagging, which
already provides enough data for a lane assistant (and which is already a
bit difficult for novice mappers).
http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details

For the driver, it's simpler to match the sign given by the app
 with the real sign.


You do have a point on photorealistic signpost view. At the time this was
written:
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Destination_details#Photorealistic_signpost_view
Mapillary didn't exist yet. It might be useful to have a node at the
location of the signpost referring to a Mapillary photo. Like this:
mapillary=http://www.mapillary.com/map/im/TpBBU2PzDPfO4lWNGfTSJg
This will provide support to both a map and a smartphone routing app

Cheers, Johan


 /al


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] name and brand tags

2014-09-25 Thread Johan C
It's not uncommon that actually the brand (e.g. Texaco) is being used on
either operator, or brand, or name. Only the latter is rendered, which can
be logical as in common speaking one easily says: I'll fill my car up at
the next Texaco' rather than saying 'I'll fill my car up at the fuel
station of Mr. xxx'

Due to the current Mapnik rendering I often use name where it's actually
the brand (yeh, I know, it's tagging for the renderer)

2014-09-25 4:34 GMT+02:00 Paul Johnson ba...@ursamundi.org:

 I'm pretty sure operator=Batman wouldn't work for name=Batman's Good Food,
 which is brand=Phillips 66...

 On Wed, Sep 24, 2014 at 9:24 AM, Richard Welty rwe...@averillpark.net
 wrote:


 On 09/24/2014 10:22 AM, Philip Barnes wrote:

 Besides in my experience petrol stations do have a name, it may not be
 obvious until you are close to the shop. Other than supermarket petrol
 stations, the name of the petrol station will appear on your receipt, not
 the name of the oil company. Phil (trigpoint)


 true, but are we better off with that in operator= than in
 name= ?

 richard



 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging



 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] key:destination Signpost question

2014-08-29 Thread Johan C
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:
http://www.openstreetmap.org/#map=15/51.8726/4.5695). An example of tagging
the exact locations of all signposts is shown here:
http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Destination#Sophisticated_variant.
Personally, I think that's a bit difficult to map, so I prefer the simple
variant

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

However any router supporting lane assist, like TomTom, shows the lane a
driver should take. It's at that point where 'obvious connectivity' in
conjunction with relations come in. I'm personally no fan of relations,
since it's almost undoable for a newbie to edit relations. And in a lot of
situations they are not necessary (like a standard motorway exit, in which
a 1 lane motorway_link departs from a 2 lane motorway). Sometimes relations
can't be avoided. I've written a text on obvious connectivity in
conjunction with relations which you can find here:
http://wiki.openstreetmap.org/wiki/User:It%27s_so_funny#Lane_connectivity

Cheers, Johan



2014-08-29 21:16 GMT+02:00 Paul Johnson ba...@ursamundi.org:

 On Fri, Aug 29, 2014 at 12:26 PM, Kam, Kristen krist...@telenav.com
 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 page). Using the destination tag on the ways
 (e.g., motorway_link) can provide one with the signpost information, but
 how would one easily identify the signpost? Are we going to use the
 'destination%' tags in conjunction with the highway=motorway_junction tags
 on the nodes where the bifurcation point is? This isn't clear in the main
 article for 'Key:destination'


 Destinations are supposed to be relations, and the members are pretty
 clear.
 http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members

 For the sign itself, I pick the centroid of the sign location (which isn't
 necessarily linear to the other members, especially when the sign is not
 overhead!).  The important (and only required) member is to.


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Follow up on destination= and destination:ref=

2014-07-10 Thread Johan C
Martijn, great to hear that Telenav will be using the destination keys.
Since this tagging will only be used for informational purposes to the
motorist (routing won't be affected) I recommend to tag all info on the
signposts, like the signs, and not only the destination and
destination:ref. Examples can be found here:
http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details

Also I would recommend to tag the lane information at the same time, since
this also gives extra info to the motorist.

Cheers, Johan

p.s. you can use the Netherlands as a European test bed: 85% of the
motorways has been tagged with signpost and lane info :-)


2014-07-10 17:21 GMT+02:00 fly lowfligh...@googlemail.com:

 Am 10.07.2014 15:43, schrieb Martijn van Exel:
  Hi,
 
  (I am sorry if this message appears twice - I wasn't yet subscribed to
  this list with my Telenav account.)
 
  I posted about destination= and destination:ref= a few days ago,
  linking to my diary entry. I have since received a lot of useful
  comments. I just wanted to bump this topic because all the discussion
  has been going on there and not on the list:
 
  http://www.openstreetmap.org/user/mvexel/diary/22419#comment27109
 
  Here at Telenav, we have now adopted destination= and destination:ref=
  for signpost information. We have two people adding information about
  signposts where they don't exist, prioritizing corridors that are of
  particular importance to us. You can follow their work here:
 
  http://www.openstreetmap.org/user/Dami_D/history
  http://www.openstreetmap.org/user/ChrisZontine/history
 
  We are not removing or replacing existing exit_to tagging. We are
  focusing on exits that don't have signpost information at all yet.
 
  We are also building support for this convention into our OSM model,
  retaining the existing support for exit_to for now.
 
  From the comment thread on my diary entry I get the feeling that there
  is some sense of agreement that we can move towards finally
  deprecating exit_to. As much as I would love to, that would require
  more discussion around what we will do with the existing exit_to tags,
  support in editors, etc. I would like to start talking about these
  things, but not before I am comfortable that we want this as a
  community.
 

 I did follow the comments on your diary but did not comment so far.

 * as there is still a traffic sign at the junction you might keep the
 information on the node.
 * if we want to keep the separation in the destination:ref, I would
 prefer destination:ref_to over ref:to. Though there is no problem with
 semi-colon separated values of destination:ref.
 * if we need information about the junction on ways, we already have
 junction=* and junction:ref=* or even junction:ref:lanes:forward=* might
 work.

 Just my 2ct
 fly

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting Extended - amenity=boat_sharing

2014-03-30 Thread Johan C
@ Andre, Nounours,

welcome to a project without goals. If you want to change the things you're
writing about, then you're most welcome to join the Future Group
http://wiki.openstreetmap.org/wiki/Future

Cheers, Johan


2014-03-30 22:25 GMT+02:00 André Pirard a.pirard.pa...@gmail.com:

  On 2014-03-29 14:13, SomeoneElse wrote :

 On 29/03/2014 12:41, nounours77 wrote:

 As discussed in my earlier post, I think voting is important even for
 specific service tags to make them offical.


 Not really - OSM doesn't have official tags.  It has commonly used
 ones, and people agree not to use the same tag to mean different things,
 but a lack of interest in a proposal is a pretty good indicator that, er,
 no one is actually interested.

 If you think that something is important enough to be mapped, then map
 it!  If you think people are using different tags to express what is
 essentially the same concept, discuss it with those people to see if it is
 the same concept or if there are nuances that anyone is missing.  Please
 don't expect people who have no knowledge of the real-world concept that
 you're trying to capture to be able to offer a useful opinion.

 Unfortunately, this is the kind of fuzziness that makes GPSes send cars to
 forbidden places or through mud (1) or hikers on a 5 km useless detour,
 that makes people laugh at OSM users, that makes OSM taggers laugh at
 themselves and laugh at me when I say that routing is a prominent
 application of OSM. That disparages OSM as a whole.
 Different features have different degrees of importance. Mapping every
 details like trees and their species is adorning and less important. But
 mapping the features that tourists look for like Nounours wants to do or
 road hazards, especially to spare a child's life while looking for the
 features, like I want to do are important, and both are disregarded.
 I have tried to show that renting is akin to selling, that they fit in the
 same framework, that if you have car renting defined and you want to
 support boat renting too, you almost just add the word boat to the
 framework (like reusing an object in object oriented programming) and that
 this lessens the fuss of voting new propositions. No one seems interested.
 I also had rendering problems. In the same reasoning vein, I suggested to
 use object oriented like generic rendering (e.g. landuse=leisure) that
 would be used if no particular rendering exists
 (leisure:miniature_golf=yes). Such frameworks tend to have everybody think
 in the same direction. No interest.
 If you look at (random cases) associatedStreet relation or addr:country=*,
 some discussions will say that you should not use it and other discussions
 will say that you should, but the wiki is mute about that or almost.  The
 reasoning about addr:country can be found under is_in=* which is an older
 alternative but none of them points to each other and it's not said that
 addr:country is better that is_in=* because it shows that the name is a
 country. In conclusion, half of the taggers will do it one way and half the
 other way. And as the discussions say that one of the ways is not supported
 by all data consumers, half of the tagging won't work for that consumer.
 What about everybody doing the same thing so that the consumer did the job
 only once, whichever way it is?

 Yes, Nounours is right. If tagging is not precisely defined, the taggers
 will tag each their own way and data consumers will not understand it and
 it will have been tagged in vain.  It is true that some cases are less
 strict than others but the problem is that many taggers have a tendency to
 make no difference and tag everything à la Picasso.

 Last but not least, I think we forgot to thank Nounours deeply for the
 work he does. Or tries to do.

 Cheers,

   André.
 (1) I had found (with Osmand too) and corrected several similar GPS
 routing tagging mistakes (there are many) and I was wondering why the same
 mistakes repeat over and over again. Then I found that the same mistake
 existed in my country's national wiki instructions!!!  I put that right,
 but I was told off by someone standing himself as a chief and I was
 commanded to put the error back to the wiki because 1) no one would tag it
 that way (too complicated (3 tags)), 2) everybody knows that signal XXX
 means what I wanted to have the tags mean 3) there had been no discussion.
 A little bit of thinking leads to these conclusions: 2a: such tagging is
 not a matter of people but of programs understanding it, which I had
 corrected it for; 2b: if one sees tags, they don't say which road sign they
 describe, so that not even a human can interpret it rightly; 3: if a car is
 sent to where it shouldn't go by the tagging, replacing it with the tags
 that send it to the right way needs little discussion beyond fine,
 thanks; 1: if nobody will do it that way and wiki instructions are to not
 do it that way and OSM is laughed at and even laughs at themselves, well,
 how should 

Re: [Tagging] tag covered questions

2014-01-23 Thread Johan C
It was a bit confusing to me, but tunnel=building_passage seems to be a
better one than covered=yes for the situations when a highway is under a
building. I think ideally such a building should be split giving the
building a different layer than the highway. Strange enough the wiki
says'' *The
layer has to be the same as the building*.' Too bad JOSM keeps displaying
validator warnings for these situations.


2014/1/23 Richard Z. ricoz@gmail.com

 On Thu, Jan 23, 2014 at 01:34:42PM +0100, Martin Koppenhoefer wrote:
 
 
  
   Related, in cases where covered is used without a layer tag should
 there be
   a common node in the place the way is crossing the building boundary
 in the
   same way there are supposed to be common nodes when streams cross
   riverbanks
   or weirs?
  
 
 
  IMHO there should always be a layer tag to store topology.

 there are many cases where you can not apply a layer tag meaningfully.
 There
 is a way going through a building - which means the building is on both
 sides
 of the way, above the way and supposedly also some underground levels
 bellow
 the way.

 Richard

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tag covered questions

2014-01-23 Thread Johan C
maybe covered=building_passage is better from a semantical point of view,
as a building_passage is not a tunnel...

As often, it depends on the definition :-) : A tunnel is an underground
passage for a road or similar.
http://wiki.openstreetmap.org/wiki/Key:tunnel

Cherio, Johan


2014/1/23 Martin Koppenhoefer dieterdre...@gmail.com


 2014/1/23 Johan C osm...@gmail.com

 It was a bit confusing to me, but tunnel=building_passage seems to be a
 better one than covered=yes for the situations when a highway is under a
 building.



 maybe covered=building_passage is better from a semantical point of view,
 as a building_passage is not a tunnel...

 cheers,
 Martin

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Ace Hardware

2013-08-30 Thread Johan C
It's also nice to keep things a bit simple in OSM, because all records in
the database need correct input and maintenance. I'm already seeing a lot
of confusion on petrol stations. Where I just want to find the nearest fuel
station (yes, I would like to have 99% coverage of amenity=fuel in OSM
worldwide) the next thing is already less important: 'is it a Shell or an
Esso, or ...'. There's not one way, but three to put Shell/Esso in: name,
brand, operator. I see them mixed up already. Please no extra confusing
tags with are hard to maintain and to explain.

Cheers, Johan


2013/8/30 Bryce Nesbitt bry...@obviously.com

 While ACE is indeed a franchise since they file an annual FDD with the
 FTC how about something weaker than franchise?

 operator  = North East McD Operating Company
 affiliation = McDonalds Corporation

 operator  = Joe Smith, Proprietor.
 affiliation = ACE Hardware Corporation
 affiliation_2 = North East Hardware Cooperative

 With ACE what's important (I suppose) is that the store probably carries a
 bunch of ACE products.

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Photo links in OSM

2013-06-23 Thread Johan C
My one year old Samsung Galaxy S3 has got the ability to geotag photos. If
there would be an app which can use such a geotagged photo and link it to
an OSM POI nearby, than I would go for that. Upload it under ODbL, no
copyright issues, Cost is a secondary thing which can be solved.

Cheers, Johan


2013/6/23 Bryce Nesbitt bry...@obviously.com

 On Sun, Jun 23, 2013 at 4:21 AM, Tac Tacelosky tac...@gmail.com wrote:

 Has the idea of an image archive for OSM been brought up before?  I
 know about openstreetview.org, but as far as I can see, it's mostly
 geotagged photos, there's not a lot of metadata there, nor integration
 explicitly with OSM.  Plus, the project seems to be inactive.


 It comes down to cost and focus.

 The cost, into perpetuity, of storing thousands of images is substantial.
  The organization would have to make that a priority.
 Projects like openstreetview.org don't scale, and are not sustainable
 over the long term.

 Plus images from wikimedia commons satisfy a huge fraction of the current
 use cases for images attached to osm objects
 (need a picture of a particular castle?  Wikimedia commons probably has
 it).

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Through_route next steps

2013-06-18 Thread Johan C
For my Garmin both B5065 examples are routed correct by Mapsource. If the
OSRM heuristics are wrong, than OSRM should get a ticket to make its engine
better.

Cheers, Johan


2013/6/18 Philip Barnes p...@trigpoint.me.uk

 On Tue, 2013-06-18 at 16:45 +0100, News wrote:
  
   You are correct, we are talking about unclassified and tertiary roads.
   Although this problem also occurs on secondary, primary and trunk
 roads,
   a classification is a measure of importance and not always quality. But
   where did the turning lane come from? or even lanes in many cases?
  
   Here is an example of why this tag is needed, and obviously support
 from
   routers.
  
   http://osrm.at/3Hs
  
   This route misses two important left turn instructions, the
 instructions
   should be
   Turn left onto B5065 in both cases.
  
   Here is the first junction http://goo.gl/maps/ouXTC
  
   and the second, which is a very definite left turn, but easily missed
 as
   routers assume you are continuing on the same road, without the
   instruction anyone following instructions is likely to carry straight
 on
   http://goo.gl/maps/DSDbt
  
 
  Excellent examples Phil. I hope to redo this so may well use those

 I can provide some photos to replace the streetview if it will help.

 Phil


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Through_route next steps

2013-06-18 Thread Johan C
No, it doesn't. Two reasons for that:
1. the road names in your example are wrong, see:
http://www.ordnancesurvey.co.uk/oswebsite/opendata/viewer/ . If the correct
road names are applied, the routing engine will know that one road is
connected through an interchange to another road
2. it's important to use Bing here to map the roads correctly: Markfield
Lane should be in an angle of 90 degrees to Botcheston road. Any routing
engine algorithm will turn 90 degrees into 'left' or 'right'.

Cheers, Johan


2013/6/18 Philip Barnes p...@trigpoint.me.uk

 On Tue, 2013-06-18 at 19:23 +0200, Johan C wrote:
  For my Garmin both B5065 examples are routed correct by Mapsource. If
  the OSRM heuristics are wrong, than OSRM should get a ticket to make
  its engine better.

 That is just one of many examples, does this one work?
 http://osrm.at/3Is
 http://goo.gl/maps/tHHkf

 It should give a turn right or turn slightly right instruction, the
 through route continues onto Main Street.

 This is the one reported by a Scobbler user that set me off on this
 campaign.

 Phil (trigpoint)





 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


[Tagging] Key: turn

2012-12-26 Thread Johan C
The key:turn http://wiki.openstreetmap.org/wiki/Key:turn has values for
slight_left/right and sharp left/right. There are no signs associated to
these four values. I also couldn't find any corresponding signs on this
page: http://en.wikipedia.org/wiki/Comparison_of_European_road_signs. The
rationale of these values is missing on the key:turn page. What is the
rationale?

One rationale could be to help the router in the following instructions:
turn sharp right, turn right, bear right, take the exit right However,
these values should then have to be applied on every turn. And routers do
have a calculation for these: turn sharp right = turn angle  90 degrees,
turn right = about 90 degrees, bear right =  90 degrees, take the exit =
the _link on motorway/trunk exits. I suppose routers also use streetnames,
to determine automatically if there's a turn onto a different street since
nobody likes to hear 'straight on' too often when there's a slight angle in
the road ahead.
Since the routers can calculate these instructions based on a turning
angle, it's somewhat strange to use values for it.

A second rationale could be to help the router in displaying a lane assist.
But, lane assist is correlated with traffic signs. So through, right and
left are perfect values for a lane assistant. But slight_left/right and
sharp left/right?

So, I can't figure out a proper rationale for these four values. Is there a
rationale for these four values?
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag: Legally separated ways (2nd Part)

2012-12-07 Thread Johan C
I've uploaded my example to this page:
http://wiki.openstreetmap.org/wiki/Lane_assist

I would also like to add a link to this page from the motorway_link page,
since lane assist will be supported: Mapfactor has started working on
it. Any comments are still welcome!



2012/11/9 Johan C osm...@gmail.com

 After reading the several posts I have made a simplified example on the
 tagging of a motorway exit. I would like to receive your comments on it.
 http://wiki.openstreetmap.org/wiki/User:It's_so_funny

 Cheers, Johan



 2012/10/18 Alberto albertoferra...@fastwebnet.it

 Just to be clear: I agree with Martin Koppenhoefer on splitting the ways
 only if there is a physical division. However, for the sake of geometry, I
 prefer to anticipate the split a bit, which is why I would put the split
 in
 section 5 or maybe even earlier - the actual position depends on how long
 section 5 is and how harsh the split is.

 +1 I agree with Simone and Martin K.
 Regards
 Alberto


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] exit_to on motorway_junction

2012-11-21 Thread Johan C
Overlooking the discussion so far, I think exit_to cannot be deprecated.
However, there's strong feelings to support both destination and exit_to.
In my opinion, the following things can be done:

1. keep things the way they are now (where exit_to is the preffered choice,
because the text on the motorway_junction page states that it should be
used). The disadvantages of exit_to are not solved:
a. no description of exit_to
b. no solution of the exit_to_left yet to support both branches
c. not clear why other items of a exit ramp are not used in the
motorway_junction tag (like lanes, maxspeed)
d. no support for advanced lanes tagging
to summarize: no support for a lane assistant

2. deprecate destination
disadvantage the same as above, so no support for a lane assistant

3. deprecate exit_to
several U.S. OSM'ers do want to keep on using exit_to

Possible solution in this discussion. The non-U.S. OSM'ers in this
discussion seem to favour destination. The U.S. OSM'ers seem to favour
exit_to. Lets split it in the text of motorway_junction tag. I do have a
text suggestion for that. Please send your thoughts on this. You can see I
also try to adress the realtion discussion, which I think can be handy, but
I don't see the value for motorway exit tagging. Destination can do the
trick there, and a relation is more complex = less KISS

Destination
The tags destination http://wiki.openstreetmap.org/wiki/Key:destination=*
 , destination:ref http://wiki.openstreetmap.org/wiki/Key:destination:ref
=* (according to information on road signs) and *lanes*=* should be used on
the ways directly after the exit. The tag
destination:laneshttp://wiki.openstreetmap.org/wiki/Key:destination
=* can be used on complex motorway_junctions. These tags are needed to
support a lane assistant in navigation devices.

In the United States exit_tohttp://wiki.openstreetmap.org/wiki/Key:exit_to
=* on the motorway_junction node should be used to detail the destinations
where the junction exits to. The tag
Relation:destination_signhttp://wiki.openstreetmap.org/wiki/Relation:destination_sign
can
be used in non-motorway situations.


This part of the exit_to will in my text suggestion be moved to the exit_to
Wiki page:

—for example, if signage states a road leads to Anytown on the A1000…
exit_to http://wiki.openstreetmap.org/wiki/Key:exit_to=Anytown
A1000http://wiki.openstreetmap.org/w/index.php?title=Tag:exit_to%3DAnytown_A1000action=editredlink=1;
if multiple destinations are shown on signage, tag them with semicolons:
for example, exit_to http://wiki.openstreetmap.org/wiki/Key:exit_to=Anytown
A1000; Elsewhere A1001;
Anyvillagehttp://wiki.openstreetmap.org/w/index.php?title=Tag:exit_to%3DAnytown_A1000;_Elsewhere_A1001;_Anyvillageaction=editredlink=1;
note that Anyvillage doesn't have a ref number.


2012/11/21 Colin Smale colin.sm...@xs4all.nl

 Using only exit_to there is no way to handle junction topologies other
 than a straightforward highway exit, where there is one big through road
 and one small road leaving. What about wrong-side exits? Or where the
 highway splits into two (or more) roads of equal importance?

 Destination tagging is used a lot in the Netherlands, placed on the first
 segment of each way *after* the node where they split. My Garmin warns me
 ahead of time which side to keep to, so there doesn't seem to be a need to
 start the tagging at the first sign (which may be 1km or more before the
 actual junction). I have not yet found a case where adding destination=*
 around a junction felt like the wrong thing to do.

 IMHO destination=* on the ways is the right balance between the
 rudimentary exit_to on the node and using a relation which will have
 problems with support/adoption by both mappers and toolmakers.

 Colin

  I don't see any reason to deprecate exit_to, it seems to be the simplest
  method of mapping a destination sign on a motorway junction or similar
  exit. I use exit_to fairly frequently and it has been a documented tag
  for a while (although on the motorway junction page rather than it's own
  page) and is also used in JOSM presets.
 
  I feel it is a less ambiguous tag than destination (as a tag on a way)
  as it shows the specific point where a destination is signed, unlike
  destination tagged on a way. If you use destination as a tag on a way
  then I think you'd need to be sure that at every point along that way
  the destination(s) given is the same throughout and if not or you didn't
  know you'd need to split the way. The Taginfo stats also seem to show
  that exit_to is the most popular of the three different ways of mapping
  destinations: a destination relation, exit_to on a junction node, or
  destination as a tag on a way.
 
  A destination relation is also a clear way of mapping a destination as
  the intersection and both the 'from' and 'to' ways are part of the
  relation, and is particularly useful in mapping situations where exit_to
  wouldn't work (like at a crossroads) so I do also use 

Re: [Tagging] exit_to on motorway_junction

2012-11-20 Thread Johan C
JOSM supports exit_to. JOSM doesn't support destination.

Following the text by Martin I updated
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction#Destinations.
I indeed think it's a good idear to be clear in the communication of any
(to be) deprecated tag.

Most exit_to's seem to be used in the US. I checked upon a
motorway_junction in the US (New York) where I noticed that the name=* of
the motorway_junction had been replaced by exit_to=* with the same value.
The US does not seem to use the name=* on the motorway_junction. Two
questions on that:

1. does the tag exit_to=* on a motorway_junction in your opinion have the
same meaning as the tag name=* on that motorway_junction?
2. if your answer to the first question is no, than what is the difference?

2012/11/20 William Rieck bi...@thinkers.org

 maybe the reference to a template was to this wiki page
 http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction where
 it seems to emphasize the 'exit_to' key over 'destination'


 On Tue, Nov 20, 2012 at 3:36 AM, Martin Vonwald imagic@gmail.comwrote:

 I created a short wiki article about exit_to:
 http://wiki.openstreetmap.org/wiki/Key:exit_to

 I did NOT add examples or a detailed tagging instruction for obvious
 reasons.

 I added a link to this discussion and also put an excerpt of it on the
 talk page. I did not take all comments completely but instead tried to
 take the most important statements. If you think I quoted you
 incorrectly/incompletely please excuse me and update the page.

 I think that someone mentioned somewhere that exit_to is used in some
 template in some editor (yes, I don't remember it perfectly) - maybe
 potlatch? Can someone verify this? If we want to deprecate exit_to we
 should remove it from that template.

 regards,
 Martin

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging



 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


[Tagging] Fwd: exit_to on motorway_junction

2012-11-20 Thread Johan C
Forwarded message by NE2

-- Forwarded message --
From: Nathan Edgars II nerou...@gmail.com
Date: 2012/11/20
Subject: Re: [Tagging] exit_to on motorway_junction
To:
Cc: Johan C osm...@gmail.com


On 11/20/2012 3:43 PM, Johan C wrote:

 JOSM supports exit_to. JOSM doesn't support destination.

 Following the text by Martin I updated
 http://wiki.openstreetmap.org/**wiki/Tag:highway%3Dmotorway_**
 junction#Destinationshttp://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction#Destinations
 .
 I indeed think it's a good idear to be clear in the communication of any
 (to be) deprecated tag.

 Most exit_to's seem to be used in the US. I checked upon a
 motorway_junction in the US (New York) where I noticed that the name=*
 of the motorway_junction had been replaced by exit_to=* with the same
 value. The US does not seem to use the name=* on the motorway_junction.
 Two questions on that:

 1. does the tag exit_to=* on a motorway_junction in your opinion have
 the same meaning as the tag name=* on that motorway_junction?
 2. if your answer to the first question is no, than what is the difference?


exit_to is what's on the sign. name is a name given to the interchange,
which doesn't usually exist in the U.S. A few examples where it does exist
(mainly on toll roads):

http://www.alpsroads.net/**roads/pa/i-276/e343.jpghttp://www.alpsroads.net/roads/pa/i-276/e343.jpg
name=Willow Grove
exit_to=PA 611; Doylestown; Jenkintown

http://www.aaroads.com/**northeast/massachusetts050/i-**
090_wb_exit_008_04.jpghttp://www.aaroads.com/northeast/massachusetts050/i-090_wb_exit_008_04.jpg
http://www.alpsroads.net/**roads/ma/i-90/ticket.jpghttp://www.alpsroads.net/roads/ma/i-90/ticket.jpg
name=Palmer
exit_to=SR 32 to US 20; Palmer; Amherst


I know there was a discussion somewhere about replacing name with exit_to,
but I don't remember where. Thus the wheel is being reinvented for no
reason.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] exit_to on motorway_junction

2012-11-20 Thread Johan C
Well Paul, the fundamental question is: where do you store the information
needed for any router, in a node, in a way or in both? In my opinion
destination on a way can work very well, please take a look at this example:

http://wiki.openstreetmap.org/wiki/User:It's_so_funny

Cheers, Johan

ps no destination relation needed in this example, which makes it more
compliant to KISS

2012/11/20 Paul Williams pjwde...@googlemail.com

 I don't see any reason to deprecate exit_to, it seems to be the simplest
 method of mapping a destination sign on a motorway junction or similar
 exit. I use exit_to fairly frequently and it has been a documented tag for
 a while (although on the motorway junction page rather than it's own page)
 and is also used in JOSM presets.

 I feel it is a less ambiguous tag than destination (as a tag on a way) as
 it shows the specific point where a destination is signed, unlike
 destination tagged on a way. If you use destination as a tag on a way then
 I think you'd need to be sure that at every point along that way the
 destination(s) given is the same throughout and if not or you didn't know
 you'd need to split the way. The Taginfo stats also seem to show that
 exit_to is the most popular of the three different ways of mapping
 destinations: a destination relation, exit_to on a junction node, or
 destination as a tag on a way.

 A destination relation is also a clear way of mapping a destination as the
 intersection and both the 'from' and 'to' ways are part of the relation,
 and is particularly useful in mapping situations where exit_to wouldn't
 work (like at a crossroads) so I do also use this method. It is however
 more complex (and so is unlikely to be a method that a new mapper would be
 able to use) particularly where there are multiple destinations given on a
 sign which requires a relation for each destination.

 Cheers,
 Paul Williams
 (Paul The Archivist)


 __**_
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


[Tagging] exit_to on motorway_junction

2012-11-18 Thread Johan C
On http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction you
can find the following description on the exit_to tag.
'exit_tohttp://wiki.openstreetmap.org/wiki/Key:exit_to
=* should be used to detail the destinations where the junction exits
to—for example, if signage states a road leads to Anytown on the A1000…
exit_to http://wiki.openstreetmap.org/wiki/Key:exit_to=Anytown
A1000http://wiki.openstreetmap.org/w/index.php?title=Tag:exit_to%3DAnytown_A1000action=editredlink=1;
if multiple destinations are shown on signage, tag them with semicolons:
for example, exit_to http://wiki.openstreetmap.org/wiki/Key:exit_to=Anytown
A1000; Elsewhere A1001;
Anyvillagehttp://wiki.openstreetmap.org/w/index.php?title=Tag:exit_to%3DAnytown_A1000;_Elsewhere_A1001;_Anyvillageaction=editredlink=1;
note that Anyvillage doesn't have a ref number'

Unfortunately, exit_to is not documented. The destination in my opinion has
same purpose as exit_to, but is a better choice because you can use it on
both outgoing parts of the Y-branch and because you can use in in
conjunction with destination:lanes. Some questions on this:

1. Have you ever used exit_to?
2. Have you ever used destination?
3. are you willing to document exit_to?
4. is it clear for you when to use exit_to and when to use destination?
5. do you have any problems (and if so: which ones) when the exit_to
description is removed from the wiki?

I'm looking forward to your answers

Cheers, Johan.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag: Legally separated ways (2nd Part)

2012-11-09 Thread Johan C
After reading the several posts I have made a simplified example on the
tagging of a motorway exit. I would like to receive your comments on it.
http://wiki.openstreetmap.org/wiki/User:It's_so_funny

Cheers, Johan



2012/10/18 Alberto albertoferra...@fastwebnet.it

 Just to be clear: I agree with Martin Koppenhoefer on splitting the ways
 only if there is a physical division. However, for the sake of geometry, I
 prefer to anticipate the split a bit, which is why I would put the split
 in
 section 5 or maybe even earlier - the actual position depends on how long
 section 5 is and how harsh the split is.

 +1 I agree with Simone and Martin K.
 Regards
 Alberto


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Exclusive access rights

2012-10-31 Thread Johan C
I don't think I understand both responses (Georg/Martin). Why should a hgv
and a psv use 'a kind of' motor_vehicle? According to the map features
motor_vehicle is used for: 'Access permission for motor cars and
motorcycles.'
A bus or a truck is not one of these two types.  If I put
'motor_vehicle=no' on any highway, then psv and hgv are still allowed to
drive on that highway.  Am I misreading the map features?

2012/10/31 Martin Vonwald imagic@gmail.com

 2012/10/31 OSM o...@bavarianmallet.de:
  I am sorry to disagree, but if hgv and psv use a kind of motor_vehicle,
 they
  are still not allowed on the rightmost lane then ... according to the
  tagging.
 
  Georg

 I have to agree with Georg... of course unless the lanes are
 exclusively for horse-drawn cabs or carriages ;-)

 Martin

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Exclusive access rights

2012-10-31 Thread Johan C
Ok, so what you guys are saying is that
http://wiki.openstreetmap.org/wiki/Map_Features#Restrictions is wrong on
the description of motor_vehicles. Fine to me, but I would appreciate an
improvement of that page then. How can that be achieved?

2012/10/31 Philip Barnes p...@trigpoint.me.uk

 **
 On Wed, 2012-10-31 at 18:56 +0100, Johan C wrote:

 I don't think I understand both responses (Georg/Martin). Why should a hgv
 and a psv use 'a kind of' motor_vehicle? According to the map features
 motor_vehicle is used for: 'Access permission for motor cars and
 motorcycles.'

  A bus or a truck is not one of these two types.  If I put
 'motor_vehicle=no' on any highway, then psv and hgv are still allowed to
 drive on that highway.  Am I misreading the map features?


 In terms of road signs, the stunt motorcycle sign ( no motor vehicles )
 includes buses and hgvs. That is the way I would certainly see it and the
 wiki seems to agree.

 http://wiki.openstreetmap.org/wiki/File:UK_traffic_sign_619.svg

 If buses are allowed, then there will be a plate below saying except
 buses.

 It is rare to prohibit hgvs as such, the way this is achieved is by weight
 or length. The most common is to prohibit vehicles over 7.5t, the historic
 breakpoint between a vehicle that could be driven on a car license and one
 requiring a hgv licence. At some point that weight was reduced, not sure
 what to or when. I can still drive a 7.5t truck due to when I passed my
 test.

 Phil




  2012/10/31 Martin Vonwald imagic@gmail.com

 2012/10/31 OSM o...@bavarianmallet.de:

I am sorry to disagree, but if hgv and psv use a kind of
 motor_vehicle, they
  are still not allowed on the rightmost lane then ... according to the
  tagging.
 
  Georg


   I have to agree with Georg... of course unless the lanes are
 exclusively for horse-drawn cabs or carriages ;-)

 Martin


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging



  ___
 Tagging mailing 
 listTagging@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/tagging



 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Exclusive access rights

2012-10-30 Thread Johan C
I believe there is a solution, which is consistent to current tagging
styles and which complies to the Keep It Simple  Smart principle.

In the situation of a motorway with three lanes, of which the rightmost
lane is forbidden for motorvehicles (and PSV and HGV can use all three
lanes) the tagging would be: motor_vehicle:lanes=yes|yes|no
No other access=*, hgv=* or psv=* tag needed in this situation.

Cheers, Johan

2012/10/30 Martin Vonwald imagic@gmail.com

 2012/10/29 Ole Nielsen on-...@xs4all.nl:
  Here is a simple proposal that avoids confusion with the existing access
  restrictions.
 
  special_use_lanes = no | no | hgv
 
  (or special_use:lanes = .. to be consistent with other lanes tags)
 
  Values can be 'no' (no special limitations apply to this lane), 'hgv',
  'psv', 'hov' etc.
 
  special_use_lanes is just a suggestion, other words not making an
  association to access could also be used. Other ideas: special_lanes,
  exclusive_use_lanes
 
  Would this be a useful way forward?

 I thought about that also but I'm not sure if I want to go down that
 road. Any new key raises the (already present) risk of being
 inconsistent. Just imagine hgv:lanes=yes|no and
 special_use:lanes=no|hgv on the same way.

 I'm not sure if there's a simple solution to this problem.

 Martin

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] destination_ref vs. dest_ref vs. destination:ref

2012-10-18 Thread Johan C
Since I love consistency: this page
http://wiki.openstreetmap.org/wiki/Key:destination shows destination fully
written with a colon. So I prefer destination:ref

I'm looking forward to your proposal, you've got my vote for introducing it
:-)


2012/10/18 Martin Vonwald imagic@gmail.com

 Any more comments/opinions on this?

 2012/10/15 Martin Vonwald imagic@gmail.com:
  Hi!
 
  Up to now I usually used the tag destination_ref to specify the ref of
  the road where a link-road is heading, in analogy with the destination
  key. Now I've seen the key dest_ref in use and also destination:ref.
  Of course none is documented in the wiki ;-)
 
  What should we do? I could write a proposal but what for what tag?
  Martin

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag: Legally separated ways (2nd Part)

2012-10-18 Thread Johan C
I today got the following response by joedalton85 (tags a lot of motorways
in France):

pour ma part, je prefere mettre les _link dés qu'elle commence ou
finnissent pour plusieurs raisons.

   - Ca permet d'avoir une longueur de voirie plus proche de la réalité
   - Ca permet d'avoir une occupation du sol plus proche de la réalité
   - Ca permet au GPS de prevenir  prenez à droite au bon moment
   - En france on doit se tourner à droite des que possible

Translated (and based on viewing some of joedalton's edits):

For my part, I prefer to put the _link where the deceleration lane starts
or where the acceleration lane finishes for several reasons.

   - a long road is closer to reality
   - It provides a land closer to reality
   - It allows the GPS to show turn right at the right time
   - In France one must turn to the right when possible.

(translations welcome, both French and English are not my native language)


2012/10/18 Paul Johnson ba...@ursamundi.org


 On Oct 17, 2012 5:35 PM, Johan C osm...@gmail.com wrote:
 
  good thing to have this discussion. Too often I've seen OSM discussions
 end up in 'everything is possible' which in the long run will prevent OSM
 to ever grow-up and eventually become competitive to the commercial boys
 and girls. (why the f... are millions of Android users using G.. maps and
 not OSMAND, Navfree or Mapfactor?)

 I haven't tried Mapfactor or Navfree yet, but OSMand is pretty godawful.
 It's ugly and cluttered, doesn't support MapDust and the voice guidance is
 annoying.  If I'm going to recommend something that supports OSM, it needs
 to be easy to use, visually inviting and have a pleasant voice that says
 something descriptive at an interval that isn't obnoxious.  Bonus points if
 it has a good Mapdust interface and does lane guidance and speed alerts.

 I would love to know if it's possible to get lane guidance and speed
 limits into a gmapsupp.img.  If so, then Garmin brings everything but the
 bug reporting interface.

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging