Re: [Tagging] Discouraging frequency=* on power lines and cables

2017-03-08 Thread David Marchal

> Le 8 mars 2017 à 23:04, Michael Reichert  a écrit :
> 
> Please keep OSM simple. I don't want to add a power route relation on
> every tiny minor distribution line/cable (230 V).
> 
Totally agree with that. I don’t understand the usage of a relation binding the 
distribution network elements: the connections between them can be retrieved 
from the nodes and ways, and the relation would merely be use for group 
tagging. IMHO, the relation would only make sense for transport lines, which 
are often viewed and treated as continuous, even if their characteristics 
change along their path (overhead, underground…). At a distribution level, 
however, this sounds overkill to me.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels and building:min_level for building:part

2017-03-08 Thread Eugene Alvin Villar
On Thu, Mar 9, 2017 at 1:32 AM, Martin Koppenhoefer 
wrote:

> there are only 33 991 objects with a building:min_level tag now
>

I'm not now commenting on whether the proposal is good or not, but other
redefinition proposals have been shot down for numbers much less than the
number given in the argument above.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - amenity=courier

2017-03-08 Thread Philip Barnes
On Thu, 2017-03-09 at 10:33 +1100, Warin wrote:
> At least some courier firms have offices where you can go to;
> send things - saves waiting for a courier to arrive at "some time" 
> during the day.
> pick something up .. when you have not been home when the courier 
> arrived (supposedly).

True, I think that it should be mapped as office. It doesn't really fit
in with amenity. When an estate agent says close to the amenities they
are not considering a nearby Fed-ex depot.

Phil (trigpoint)

> 
> On 09-Mar-17 08:56 AM, John F. Eldredge wrote:
> > Are you trying to map the location of an office of a courier
> > service? 
> > Couriers themselves are people, and by the nature of their
> > business 
> > have no fixed location.
> > 
> > 
> > On March 8, 2017 3:32:23 PM Warin <61sundow...@gmail.com> wrote:
> > 
> > > On 08-Mar-17 08:42 PM, muzirian wrote:
> > > > A company that transports commercial packages and documents.
> > > > 
> > > > https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcourier
> > > > 
> > > 
> > > What physical feature are you mapping?
> > > 
> > > The description says "A company.." Companies are legal entities
> > > ... not
> > > physical features.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - amenity=courier

2017-03-08 Thread Warin

At least some courier firms have offices where you can go to;
send things - saves waiting for a courier to arrive at "some time" 
during the day.
pick something up .. when you have not been home when the courier 
arrived (supposedly).


On 09-Mar-17 08:56 AM, John F. Eldredge wrote:
Are you trying to map the location of an office of a courier service? 
Couriers themselves are people, and by the nature of their business 
have no fixed location.



On March 8, 2017 3:32:23 PM Warin <61sundow...@gmail.com> wrote:


On 08-Mar-17 08:42 PM, muzirian wrote:

A company that transports commercial packages and documents.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcourier



What physical feature are you mapping?

The description says "A company.." Companies are legal entities ... not
physical features.






___
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] Discouraging frequency=* on power lines and cables

2017-03-08 Thread François Lacombe
Hi Warin,

More than a guide, wiki sounds like a reference to me.
Actually, editors presets, QA tools and consumers - all after contributors
- will rely on it to define their behaviour and targets.

Agree with you there are no rules, just material to discuss and important
basis to built up on.

Yes, I'm not against a statement encouraging contributors to use relations
to separate logical things than physical things.
There is this proposal on that particular topic :
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal


Michael,

It wasn't about deprecating anything. Frequency is a good key.

No point to add relations on every minor line, but at neighbourhood scale,
it can mean something regarding the network organization
Like this : https://www.openstreetmap.org/relation/6087750

Network map can't be completed unless we put logical relations on physical
lines to know where the power actually flows. Believe me it's useful and
have a high value.
Mappers aren't force at all to use those advanced techniques, but someone
who wants to should be encouraged.

That's why I want to tidy up this tiny piece of wiki without needing a lot
of arguments and energy.


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


Re: [Tagging] Discouraging frequency=* on power lines and cables

2017-03-08 Thread Michael Reichert
Hi François,

Am 2017-03-08 um 15:18 schrieb François Lacombe:
> frequency=* tag aims to qualify active elements on telecom or power
> networks (among others, see wiki
> http://wiki.openstreetmap.org/wiki/Key:frequency)
> 
> I see it as an optional property of power lines or cables.
> http://wiki.openstreetmap.org/wiki/Tag:power%3Dline
> 
> In practice, a physical line/cable section isn't operated at, nor designed
> for, any dedicated frequency but it's all about the supported power circuit
> (a logical relation going from a place to another place through the grid).
> It always exists if line is actually powered on.
> We use to map such logical circuits with route=power relations where
> frequency is more relevant.
> 
> Can we drop frequency on power lines and cables wiki page ?
> It can't be guess by looking at the line (instead of voltage) in landscape
> and there may be inconsistencies between circuits relations and lines
> members.

frequency=* should not be deprecated (if that is ever possible at OSM at
all) or removed from the wiki page because otherwise mappers are forced
to add a useless relation on every single power line. If you map a power
line, you usually know its frequency. For example, 50 Hz is the default
frequency in Europe. If the line belongs to the separated 16.7 Hz
network, it is signed (signs with the name of the operator, e.g. DB
Energie GmbH at the towers).

Please keep OSM simple. I don't want to add a power route relation on
every tiny minor distribution line/cable (230 V).

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - amenity=courier

2017-03-08 Thread John F. Eldredge
Are you trying to map the location of an office of a courier service? 
Couriers themselves are people, and by the nature of their business have no 
fixed location.



On March 8, 2017 3:32:23 PM Warin <61sundow...@gmail.com> wrote:


On 08-Mar-17 08:42 PM, muzirian wrote:

A company that transports commercial packages and documents.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcourier



What physical feature are you mapping?

The description says "A company.." Companies are legal entities ... not
physical features.






___
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] Discouraging frequency=* on power lines and cables

2017-03-08 Thread Warin

On 09-Mar-17 03:19 AM, François Lacombe wrote:

Hi Tom,

2017-03-08 16:08 GMT+01:00 Tom Pfeifer >:



The wiki documents for what particular tags are for. This tag is
used 826577 times, so this documentation is essential.

Also, we normally do not delete wiki pages at all. The process
would be to discourage or deprecate the tag, however the reasons
you gave above are very weak for me.

My point wasn't to delete any page but to remove frequency=* as a 
possible tag for power lines.



frequency=16.7 is used a lot on railway networks where it is
clearly distinguished from the 50 (Europe) or 60 (America) Hz
regular energy distribution.

frequency=0 (used on 35% of the tags) means DC power which is used
on specific railways, and could also apply to DC distribution
networks that I vaguely remember are constructed differently from
traditional 50/60Hz-Networks.


I didn't say frequency isn't used but it is actually misused.
Frequency refers to power routes, not physical power lines


While the lines themselves don't have a frequency (well there are limits 
as to what they will take) themselves, as you say the supporting 
infrastructure (transformers, generators etc) have a nominal frequency.


If you want include a statement that power distribution lines themselves 
do not require a tag of frequency but relationships that have those 
lines as members should have a tag of frequency?
Is that what you are after? Do remember that the wiki is a guide, not 
rules... try not to be pedantic.




Example :
A 400 kV 50Hz route : http://www.openstreetmap.org/relation/6359644
Which has lines as members : http://www.openstreetmap.org/way/41773490 
http://www.openstreetmap.org/way/41828020 where frequency isn't mentioned.


If a 16.7 Hz line would have shared same sections, the relation would 
have frequency=16.7 and line sections wouldn't.



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


Re: [Tagging] Feature Proposal - RFC - amenity=courier

2017-03-08 Thread Warin

On 08-Mar-17 08:42 PM, muzirian wrote:

A company that transports commercial packages and documents.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcourier



What physical feature are you mapping?

The description says "A company.." Companies are legal entities ... not 
physical features.







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


Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels

2017-03-08 Thread Christian Müller
> Gesendet: Mittwoch, 08. März 2017 um 18:32 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Tag discussion, strategy and related tools" 
> Betreff: [Tagging] simple 3D buildings, proposed redefinition of 
> building:levels
> 
> NEW:
> 
> - building:min_level unchanged
> 
> - building:levels=amount of levels for this part

I support this proposal, although I guess that tag-voting by mailing list will 
reach even less people than doing it in the wiki.  What we'd actually need is 
some kind of feed to inform mappers while mapping (i.e. while using an editor), 
but it would need some intelligence to sort messages relevant to the field 
you're working on.

I.e. when mapper X is not mapping buildings he/she will be less 
inclined/qualified to vote on building related tags.  However, sorting messages 
like this may also raise privacy / big brother issues that we will want to 
avoid. Because sorting messages like this essentially means an algorithm will 
need to look at individual contributions to do some kind of basic profiling. 
This sounds scary (and it is), but has some tempting, undeniable benefits. The 
project would need to offer more protection and anonymity to user accounts 
before advertising such features as being useful. -> After all, a case in the 
news where osm mapping led to personal disadvantage could lead to massive loss 
of man power and trust in the project.  So while this may sound convenient, it 
may be too hard of a task to do for a free project.  (In part, some of these 
issues may also apply to any scheme of a more direct democracy.)


Greetings

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


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


Re: [Tagging] Positioning motorway exits

2017-03-08 Thread Volker Schmidt
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] simple 3D buildings, proposed redefinition of building:levels and building:min_level for building:part

2017-03-08 Thread Martin Koppenhoefer
I propose to deprecate the current definition of building:levels which is:

OLD:

- building:min_level is the amount of levels of the underneath
building_part below the tagged building:part

- building:levels=building:min_level + amount of levels for this part

in favor of

NEW:

- building:min_level unchanged

- building:levels=amount of levels for this part


What do you think? We could migrate the existing building:levels with the
time or in one go.
I don't think it's too late for this, there are only 33 991 objects with a
building:min_level tag now, (the rest will not change), and you can easily
see if the indication is according to the old or the new scheme by looking
at the values:

building:levels - building:min_level < 0
yes: new
no: old

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


Re: [Tagging] Discouraging frequency=* on power lines and cables

2017-03-08 Thread François Lacombe
Hi Tom,

2017-03-08 16:08 GMT+01:00 Tom Pfeifer :

>
> The wiki documents for what particular tags are for. This tag is used
> 826577 times, so this documentation is essential.
>
> Also, we normally do not delete wiki pages at all. The process would be to
> discourage or deprecate the tag, however the reasons you gave above are
> very weak for me.
>
My point wasn't to delete any page but to remove frequency=* as a possible
tag for power lines.


>
> frequency=16.7 is used a lot on railway networks where it is clearly
> distinguished from the 50 (Europe) or 60 (America) Hz regular energy
> distribution.
>
> frequency=0 (used on 35% of the tags) means DC power which is used on
> specific railways, and could also apply to DC distribution networks that I
> vaguely remember are constructed differently from traditional
> 50/60Hz-Networks.
>

I didn't say frequency isn't used but it is actually misused.
Frequency refers to power routes, not physical power lines

Example :
A 400 kV 50Hz route : http://www.openstreetmap.org/relation/6359644
Which has lines as members : http://www.openstreetmap.org/way/41773490
http://www.openstreetmap.org/way/41828020 where frequency isn't mentioned.

If a 16.7 Hz line would have shared same sections, the relation would have
frequency=16.7 and line sections wouldn't.



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


Re: [Tagging] Positioning motorway exits

2017-03-08 Thread Paul Johnson
On Wed, Mar 8, 2017 at 3:38 AM, Marc Gemis  wrote:

> On Wed, Mar 8, 2017 at 12:47 AM, Tom Pfeifer 
> wrote:
> > On 08.03.2017 00:01, Johan C wrote:
> >>
> >> make sure the requirements for navigational devices like OSMAND should
> >> also be met
> >
> >
> > I don't think OsmAnd would have a problem with the node being at the
> > physical separation, in particular if the turn:lanes are tagged
> correctly.
> > OsmAnd will give advance advice to turn and display the lanes to use.
>
> While OsmAnd might show the turn lanes on time, it does announce the
> distance to the split as the distance to the exit-node. It does not
> inform you about the need to be in the right lane based on a (long)
> solid line of several hundred meters
> As Paul Johnson wrote, the change:lanes tag is useful in such cases,
> but OsmAnd does not know about it.


Yet!  Don't tag for any specific data consumer, tag what's on the ground in
situations like this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Positioning motorway exits

2017-03-08 Thread Tom Pfeifer

On 08.03.2017 10:38, Marc Gemis wrote:

On Wed, Mar 8, 2017 at 12:47 AM, Tom Pfeifer  wrote:

I don't think OsmAnd would have a problem with the node being at the
physical separation, in particular if the turn:lanes are tagged correctly.
OsmAnd will give advance advice to turn and display the lanes to use.


While OsmAnd might show the turn lanes on time, it does announce the
distance to the split as the distance to the exit-node. It does not
inform you about the need to be in the right lane


Well it does show you the turn:lanes that should be mapped in such case, 
thereby it informs you to be in the right lane. These turn:lanes would 
start in an area where changing lanes is legal.


The rule is to split road ways at physical separation, consistently. 
Thus all different data consumers can rely on it.



based on a (long)
solid line of several hundred meters
As Paul Johnson wrote, the change:lanes tag is useful in such cases,
but OsmAnd does not know about it.


Fine, you found an issue how a data consumer could improve by 
implementing a specific tag. Open an issue there and ask for it to be 
implemented.


tom

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


Re: [Tagging] Discouraging frequency=* on power lines and cables

2017-03-08 Thread Tom Pfeifer

On 08.03.2017 15:18, François Lacombe wrote:

frequency=* tag aims to qualify active elements on telecom or power
networks (among others, see wiki
http://wiki.openstreetmap.org/wiki/Key:frequency)

I see it as an optional property of power lines or cables.
http://wiki.openstreetmap.org/wiki/Tag:power%3Dline

In practice, a physical line/cable section isn't operated at, nor
designed for, any dedicated frequency but it's all about the supported
power circuit (a logical relation going from a place to another place
through the grid). It always exists if line is actually powered on.
We use to map such logical circuits with route=power relations where
frequency is more relevant.

Can we drop frequency on power lines and cables wiki page ?
It can't be guess by looking at the line (instead of voltage) in
landscape and there may be inconsistencies between circuits relations
and lines members.

If no further comments, i'll remove this option in 15 days for the above
reason.


The wiki documents for what particular tags are for. This tag is used 
826577 times, so this documentation is essential.


Also, we normally do not delete wiki pages at all. The process would be 
to discourage or deprecate the tag, however the reasons you gave above 
are very weak for me.


frequency=16.7 is used a lot on railway networks where it is clearly 
distinguished from the 50 (Europe) or 60 (America) Hz regular energy 
distribution.


frequency=0 (used on 35% of the tags) means DC power which is used on 
specific railways, and could also apply to DC distribution networks that 
I vaguely remember are constructed differently from traditional 
50/60Hz-Networks.


Summary: don't touch it.

tom

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


[Tagging] Discouraging frequency=* on power lines and cables

2017-03-08 Thread François Lacombe
Hi,

frequency=* tag aims to qualify active elements on telecom or power
networks (among others, see wiki
http://wiki.openstreetmap.org/wiki/Key:frequency)

I see it as an optional property of power lines or cables.
http://wiki.openstreetmap.org/wiki/Tag:power%3Dline

In practice, a physical line/cable section isn't operated at, nor designed
for, any dedicated frequency but it's all about the supported power circuit
(a logical relation going from a place to another place through the grid).
It always exists if line is actually powered on.
We use to map such logical circuits with route=power relations where
frequency is more relevant.

Can we drop frequency on power lines and cables wiki page ?
It can't be guess by looking at the line (instead of voltage) in landscape
and there may be inconsistencies between circuits relations and lines
members.

If no further comments, i'll remove this option in 15 days for the above
reason.


All the best

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


[Tagging] Feature Proposal - RFC - amenity=courier

2017-03-08 Thread muzirian
A company that transports commercial packages and documents.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcourier

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


Re: [Tagging] Positioning motorway exits

2017-03-08 Thread Marc Gemis
On Wed, Mar 8, 2017 at 12:47 AM, Tom Pfeifer  wrote:
> On 08.03.2017 00:01, Johan C wrote:
>>
>> make sure the requirements for navigational devices like OSMAND should
>> also be met
>
>
> I don't think OsmAnd would have a problem with the node being at the
> physical separation, in particular if the turn:lanes are tagged correctly.
> OsmAnd will give advance advice to turn and display the lanes to use.

While OsmAnd might show the turn lanes on time, it does announce the
distance to the split as the distance to the exit-node. It does not
inform you about the need to be in the right lane based on a (long)
solid line of several hundred meters
As Paul Johnson wrote, the change:lanes tag is useful in such cases,
but OsmAnd does not know about it.

m

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


Re: [Tagging] Positioning motorway exits

2017-03-08 Thread Paul Johnson
On Mar 7, 2017 03:47, "Volker Schmidt"  wrote:

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.


change:lanes=* is a good tag for situations where there is a lane change
restriction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging