[Tagging] Mindistance=*

[Joachim]

I added mindistance=* to the section "statutory restrictions" on wiki
page for access=*
(https://wiki.openstreetmap.org/wiki/Key:access#Size_and_statutory_restrictions).
It's the signed minimum trailing distance, in metres as it is default
for lengths.

Current taginfo (on ways)
68 mindistance
47 mindistance:hgv
6 mindistance:hgv:lanes

It's often used for hgv vehicles in tunnels
(http://openstreetcam.org/details/27490/65) or on old bridges
(https://www.mapillary.com/map/im/6ZQory0nWk0uwwuenNM-Rw).

I will also create a wiki tag page. It there anything else to add?

regards Joachim

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

[Tagging] Feature Proposal - RFC - Place areas

[Joachim]

The mapping of settlements as place areas has long been hindered by
several problems:
* The usability of place=* polygons (huge closed ways, multipolygons)
* The centre information would be lost
* The extend of a settlement is not explicitly defined
(https://en.wikipedia.org/wiki/Settlement_geography). This might lead
to disputes

For the first two points I present a solution. For the third I thrust
national/local mappers to converge.

I present two new tags and three scenarios of which the first one
holds the most promise:

For settlements (or parts of) which have a centre the tag
boundary=place is introduced to be used on
- closed ways (areas)
- also on type=boundary relations.
... as already done by administrative boundaries, postal codes and low
emissions zones.

The place node is kept and put in the relation as role place_centre.

Places without a centre can be represented by place area as they are
usually smaller and more maintainable.

Additional tags:
- name=* - to facilitate handling
- admin_level=* - for linking to administrative borders, usually a
place area is inside an administrative area (debatable)
Other tags are not necessary since present on the linked place node.

Rationale for usage of boundaries:
- Larger settlements (probably from place=city on) cannot by
represented by a simple closed way (area) because this will be
unmaintainable and there is also the issue of a 2000-nodes limit per
way.
- The next solution would be Multipolygons. But they they do not
support other roles than inner/outer.
- The next solution would be a a relation type=place. But then mappers
will be tempted you use the edge of existing landuse=* areas members.
This would lead to wide-spread use/conversion of landuse=* to
multipolygons - which is a maintenance nightmare ("Multipolygonwahn").

The solution is to separate landuse and place areas. Although place
boundaries are only technically necessary for large settlements they
should be used for area representation on all place=* which have a
centre in order to have consistent tagging.

Detailed proposal with summary tables:
https://wiki.openstreetmap.org/wiki/Proposed_features/place_areas

Regards Joachim

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

Re: [Tagging] dispersed settlements / scattered settlements

[Joachim]

I agree that landuse should usually get no names.

If a settlement has a name which is used only for administrative or
postal purposes there is no need for a place=* feature, just use
boundary=administrative/postal_code.

If the dispersed settlement is perceived as an settlement (I'm living
in...) it should get a place=* element.

Currently we categorize settlements by number of inhabitants, modified
by importance. I would rather not open another dimension. The type of
of a settlement can be deduced by processing the landuse inside. If
there is use in a binary (yes/no) property it should be added to the
place=* feature: e.g. dispersed_settlement=yes. But this looks more
like job for Wikidata.

Another big problem is the exclusive usage of settlement place as
nodes. But dispersed settlements have no centre. I just drafted an
article which presents solutions for settlements with centres. This
would allow dispersed settlements to migrate from place node to area
since they would not considered be problematic any more. All is
detailed here: https://wiki.openstreetmap.org/wiki/Proposed_features/place_areas

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

Re: [Tagging] Feature Proposal - RFC - Carport

[Joachim]

I thought the same now: Discussion was positive and the tag is already
in use. So I created the feature page
https://wiki.openstreetmap.org/wiki/Tag:building%3Dcarport and set the
status of the feature and the proposal to "in Use".

Thanks
Joachim

2017-02-04 20:40 GMT+01:00 Yves <yve...@gmail.com>:
> I think here that no comment means not controversial, you should move away
> the page from proposal to document an established tag and that's it.
> Yves
>
>
>
> --
> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
>
> ___
> 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 - snow removal station

[Joachim]

Here the wiki page link, I just forgot to link it :(

https://wiki.openstreetmap.org/wiki/Proposed_features/Snow_removal_station

Regards Joachim

2017-01-31 20:16 GMT+01:00 Joachim <nore...@freedom-x.de>:
> Lorry drivers are usually required to remove ice and snow from their
> vehicles as they pose a safety hazard when falling on the ground. In
> order to allow drivers to reach the roof, structures (e.g. made of
> scaffolding) have been erected along some major highways. They are
> called "Räumstation" in Germany.
>
> I propose the tag amenity=snow_removal_station. This feature is a
> useful and important facility, fitting well to the Key:amenity key. It
> is comparable to amenity=bicycle_repair_station or
> sanitary_dump_station.
>
> I could not find a picture with free license, so head over to google
> image search 
> (https://www.google.de/search?tbm=isch=r%C3%A4umstation+schnee).
>
> I'm interested in comments under which name such features are known in UK.
>
> Regards Joachim

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

[Tagging] Feature Proposal - RFC - snow removal station

[Joachim]

Lorry drivers are usually required to remove ice and snow from their
vehicles as they pose a safety hazard when falling on the ground. In
order to allow drivers to reach the roof, structures (e.g. made of
scaffolding) have been erected along some major highways. They are
called "Räumstation" in Germany.

I propose the tag amenity=snow_removal_station. This feature is a
useful and important facility, fitting well to the Key:amenity key. It
is comparable to amenity=bicycle_repair_station or
sanitary_dump_station.

I could not find a picture with free license, so head over to google
image search (https://www.google.de/search?tbm=isch=r%C3%A4umstation+schnee).

I'm interested in comments under which name such features are known in UK.

Regards Joachim

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

Re: [Tagging] Admin_level=2 for non-independent countries

[Joachim]

So regarding my question you say the implicit admin_level of a capital
should mirror the boundaries. A difference between "independent" and
non-independent should be developed there if needed.

2016-10-08 14:32 GMT+02:00 Colin Smale :
> Instead of labelling the city itself with capital=yes, consider adding the
> city to the admin boundary with a role of "capital". Like that a city can
> easily be capital of multiple administrative units (it might be a national
> capital and a provincial capital at the same time) and it stays distinct
> from the administrative centre.
>
> A city cannot simply be a "capital" based on its own characteristics like
> population or area. Being a capital is a role of a place in the context of a
> territory, so putting this on the relation for the territory seems the most
> logical place to me.
>
> As the capital and administrative centre are mostly coincident, I would
> suggest that adding the "capital" role would only be required for the
> exceptional cases. If no capital is specified explicitly, I would assume
> that the admin_centre also has that role.
>
> //colin

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

[Tagging] Admin_level=2 for non-independent countries

[Joachim]

While editing capital=yes I came across capitals of non-independent
countries which have their national border tagged with admin_level=2
(I just did a browser site search in
https://osm.wno-edv-service.de/boundaries/).

Wikipedia was used to assemble the list
(https://en.wikipedia.org/wiki/List_of_national_capitals_in_alphabetical_order)

The countries fall into the categories:
- Realm of New Zealand (only Tokelau)
- British Overseas Territories with Bermudas, Gibraltar, Turks and
Caicos Islands and others
- Crown Dependencies with Isle of Man, Jersey and Guernsey (quite independent)
- Danish Realm with Greenland and Faroe Islands

The following are grouped below their respective states:
- French overseas departments and territories
- United States Territories
- Australian External Territories
- Kingdom of the Netherlands (Dutch Caribbean)

Question: Are there any improvements possible, e.g. creating some of
the constructs above and order the countries below?

Question: Should capital=yes mirror admin_level=2 or should
capital=yes be used for independent countries and capital=2 for the
other?

Regards Joachim

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

Re: [Tagging] Capital=* and admin_level on cities

[Joachim]

Wikipedia[1] tends to agree with you. So we need another role=capital
which just means capital plus administrative centre and capital only
when in addition role admin_centre is used? For lower entities (below
admin_level=4) the word "capital" seems to be not used much, so
admin_centre should suffice here like it is now.

There are other arrangements described on the Wikipedia page, mostly
of different parliament seat and judicial seat. Would they need to be
modelled as well? There should not be stuffed everything into the
country border relations.

[1] https://en.wikipedia.org/wiki/Administrative_centre
[2] https://en.wikipedia.org/wiki/Capital_city#Unusual_capital_city_arrangements

2016-10-03 19:43 GMT+02:00 Colin Smale <colin.sm...@xs4all.nl>:
> On 2016-10-03 18:23, Joachim wrote:
>
> Wouldn't look right for the Netherlands. The capital is Amsterdam, but the
> seat of government (admin_centre) is The Hague. So capital and admin_centre
> are different things here.
>
>
>
> I see no problems giving both the role admin_centre. The naming of the
> role shouldn't be taken too literally.
>
>
> Sorry, I don't agree with this. Admin centre is admin centre, capital is
> capital. Often they coincide, sometimes they don't. Amsterdam is not the
> admin centre of the country, it is also not even the provincial capital
> (that is Haarlem BTW). It is just the admin centre of its own municipality.
>
> See also:
> https://en.wikipedia.org/wiki/Capital_city#Capitals_that_are_not_the_seat_of_government
>
> //colin
>
> ___
> 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] Capital=* and admin_level on cities

[Joachim]

> Wouldn't look right for the Netherlands. The capital is Amsterdam, but the
> seat of government (admin_centre) is The Hague. So capital and admin_centre
> are different things here.


I see no problems giving both the role admin_centre. The naming of the
role shouldn't be taken too literally.

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

[Tagging] Capital=* and admin_level on cities

[Joachim]

The recent rendering of capitals in osm-carto[1] brought new interest
in the tag capital=*[2]. I edited the feature page according to the
latest summary in the proposal (linked in feature page) which also
mirrors actual data usage.

Claim 1: Capital=yes should be used for capitals of countries.
Capital= should be used for administrative subdivisions
in countries.

Another tagging approach (used widely in Russia) is to tag capital=yes
+ admin_level= on cities. This usage depends on how
admin_level on place is actually defined!
For example Berlin[3] is inside boundary=administrative+admin_level=4
(Berlin State). But currently Berlin has place=city+admin_level=2 and
is at the same level as Germany!
For example Yakutsk[4] is inside boundary=administrative+admin_level=6
(Yakutsk Urban District). But currently Yakutsk has
place=city+admin_level=4 and is at the same level as the Sakha
Republic.


Claim 2: Capital=yes/number is more than enough to describe the
capital status, we don't need admin_level for it. Admin_level on place
should not be used for describing capital=yes or national importance
but just for administrative level of the place as defined by the
borders around it.

Just a heads-up: the long-term solution is to use admin_centre on
national boundaries.

[1] https://github.com/gravitystorm/openstreetmap-carto/pull/2314
[2] https://wiki.openstreetmap.org/wiki/Key:capital
[3] https://www.openstreetmap.org/node/240109189
https://www.openstreetmap.org/relation/62422
[4] https://www.openstreetmap.org/node/191652335
https://www.openstreetmap.org/relation/1444344
https://www.openstreetmap.org/relation/151234

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

[Tagging] Setting as access=official as abandoned/deprecated

[Joachim]

I want to set the access=official proposal[1] to abandoned and the
feature page[2] to deprecated. Since this tag is mostly used in
Germany I have documented the case in the german forum[3] and got only
positive feedback so far.

Key points in english:
- compared to designated, official is used much less (foot 3.3%,
bicycle 2.0%, horse 4.1%, psv 15,1%)
- The usage apart from foot=official is not increasing since 2014 [4]
- Regarding the main pages, Wiki currently uses it only on
Tag:access=designated, Key:bicycle_road
- designated is now defined as official was meant to be regarding
"dedicated usage"
- designated is not defined as official regarding access - designated
still allows other traffic
- wanderreitkarte.de uses blue signs for official and grey for designated
- iD does not use official
- JOSM does use it in the Road Signs plugin and some presets as drop-down

Is anybody against this change?

Regards Joachim

[1] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Officially_dedicated_usage
[2] https://wiki.openstreetmap.org/wiki/Tag:access%3Dofficial
[3] http://forum.openstreetmap.org/viewtopic.php?id=55927
[4] 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Officially_dedicated_usage#Current_usage_trends

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

[Tagging] Feature Proposal - RFC - building=carport

[Joachim]

The tag building=carport is used for is used for one carport building.
The carport might provide more than one parking space.

Rationale:
A carport is distinctive enough from building=garage and building=roof
so that an own tag should be used. The plural (like building=garages)
is not defined since all wide carports I could find can be classified
as one structure. The key building=* is used since a carport is a type
of building=roof.

Add amenity=parking/motorcycle_parking/bicycle_parking +
building=carports to mark the parking facility. If there are multiple
carports at a parking site add the tags to an area surrounding them.
These tags are usually not necessary for private parking.

https://wiki.openstreetmap.org/wiki/Proposed_features/carport_buildings

Regards Joachim (Jojo4u)

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

Re: [Tagging] Feature Proposal - RFC - scheduled lifecycle value

[Joachim]

2016-05-17 10:22 GMT+02:00 Martin Koppenhoefer :
> how "secure" must secured funding be? Just because money is reserved/foreseen 
> to build something doesn't mean it will be spent in all cases, and that it is 
> sufficient to complete the construction. Shall we evaluate the probability 
> that the entity giving the money could default? I believe yet another 
> intermediate level for planning and construction states will not change the 
> situation significantly.

No, unforeseen events don't have to be considered. If a already
started construction is not finished it will already be in lifecycle
construction:.
What do you mean by "yet another" level? At the moment there is only
proposed and construction, planned is considered the same as proposed.

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

Re: [Tagging] Feature Proposal - RFC - scheduled lifecycle value

[Joachim]

2016-05-17 18:42 GMT+02:00 Bryce Nesbitt :
> A major milestone in a project is when the right of way is secured (meaning
> land is purchased,
> or easements signed).
>
> That still does not guarantee a project will be constructed, but it a
> definite step above "planned".

I added that point. The list now:

- planning is finished
- construction has been approved by authorities
- funds have been secured
- right to build on the affected land has been obtained
- start of construction is in the near future

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

Re: [Tagging] Should greenhouse et al have building=yes? (was building=digester)

[Joachim]

2016-05-22 10:31 GMT+02:00 Volker Schmidt :
> I am surprised by his long discussion
>
> Two (extreme) examples:
> http://www.ikea.com/us/en/catalog/products/70186603/
> amenity=greenhouse
> building=no
>
> http://www.ortobotanicopd.it/il-giardino-della-biodiversit%C3%A0
> amenity=greenhouse
> building=yes
>

And I'm surprised about your proposal amenity=greenhouse ;) It's a bad
tag since a greenhouse is not an amenity. It's usage count is around
300, please don't promote.

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

[Tagging] Feature Proposal - RFC - scheduled lifecycle value

[Joachim]

https://wiki.openstreetmap.org/wiki/Proposed_features/Scheduled_lifecycle

Fitting between proposed:=* and construction:=* the key/value/prefix
scheduled is used for to-be-built features where all of the following is
true:

* planning is finished
* construction has been approved
* funds have been secured
* start of construction is in the near future

Scheduled can be used as:

* lifecycle prefix (e.g. scheduled:highway=primary)
* status value and key on highways and railways (e.g. highway=scheduled +
scheduled=primary)

Rationale

The rendering of the proposed=* was dropped from osm-carto in 2015[1]
because of problems with verifiability. Discussion about a stricter defined
value planned followed[2].  But planned has too few semantic differences
compared to proposed and for many does not include secured funding. The
master plan for federal highway construction in Germany
Bundesverkehrswegeplan uses the words "fest disponiert" for projects which
will surely start in the next years. This translates to scheduled. If there
is any better word than scheduled please let me know!

[1] https://github.com/gravitystorm/openstreetmap-carto/issues/1654
[2] https://lists.openstreetmap.org/pipermail/tagging/2015-July/025630.html

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

Re: [Tagging] do aerodromes need a relation?

[Joachim]

Often aerodrome as areas get added without removing the older node.
IMHO an aerodrome as area/multipolygon is a more detailed way of
tagging an aerodrome. With the rule "one feature = one OSM element"
either the node or the area should be deleted.

About your proposed use of a relation with a label as node: This is
strongly opposed by map style editors and the "label" role was removed
by me from the (proposed) site relation because of this.

About Munich: The duplicated node
(https://www.openstreetmap.org/node/4089995869) was added recently by
mihaii_telenav and will be removed. I already removed it on Stuttgart
airport.

regards Joachim

2016-04-09 11:16 GMT+02:00 Martin Koppenhoefer <dieterdre...@gmail.com>:
>
>
> sent from a phone
>
> Am 08.04.2016 um 13:14 schrieb Marc Gemis <marc.ge...@gmail.com>:
>
>>> The wiki for aerodromes suggests looking at the mapping of Munich airport.
>>> It also has a node and a way that live in separate worlds. Shouldn't most
>>> tags live in a relation, with the node as a label (similar to administrative
>>> boundaries)?
>
>
> I suggest to do only an area and delete the node.
>
> 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] bicycle=use_sidepath applicable to bicycle lanes?

[Joachim]

Use_sidepath was invented to solve the *routing* problem of compulsory
*separate* cycle paths. Usage of use_sidepath together with
highway=*+cycleway=* was hotly discussed after the proposal got
accepted.[1]

The question is: Are there somewhere on this world non-compulsory
cycle lanes (cycleway=lane)? If yes, we have two possibilities:

1. use_sidepath/-lane
First use_sidelane has to invented for cycleway=lane.
Afterwards it's technically not difficult to define: "A highway with
bicycle=use_sidepath/-lane and with tag cycleway=track/lane does mean
the track/lane is compulsory". But this looks odd.
Also very important is :lanes tagging, which is the advanced way of
tagging a cycle lane:
bicycle:lanes=use_sidelane|use_sidelane|designated looks good and
allows using one lane for turning.

2. bicycle:obligatory[2]
The obligatory suffix proposal is by me. A highway with
cycleway=track/lane and cycleway:bicycle:obligatory=yes looks very
natural.
Lanes tagging looks also good: bicycle:obligatory:lanes=||yes.



[1] 
http://wiki.openstreetmap.org/wiki/Talk:Tag:bicycle%3Duse_sidepath#bicycle.3Duse_sidepath_only_if_the_cycleway_is_a_separate_highway_.28like_highway.3Dcycleway.29
[2] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Obligatory_access_suffix#Rationale

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Joachim]

In my practice I use relations for every route, but leave ref on the
ways for signed routes. For roads these are motorway and
"Bundesstraßen" (mostly primary) in Germany.
While checking e-roads in Germany I came across a relation which was
empty. Viewing the history failed because of a timeout from the API
(history too large). Luckily the ways still had int_ref so restoring
the relation was easy. What other chances are there to retrieve older
versions of relations other than JOSM/osm.org? I read something about
overpass.

Regards Joachim

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

Re: [Tagging] Feature Proposal - Voting - Motorway link no default oneway

[Joachim]

I can understand your concern, but please have a look at the reactions when
the proposal still included "don't route over motorway_link without
oneway". The reactions said there is no chance in enforcing this.

https://lists.openstreetmap.org/pipermail/tagging/2015-September/026453.html

2015-10-30 0:51 GMT+01:00 André Pirard <a.pirard.pa...@gmail.com>:

> On 2015-10-29 20:45, Joachim wrote :
>
It says:
>
> Strongly recommend explicit tagging of oneway=* on highway=motorway_link.
>
> For routing purposes no recommendation for ways with *undefined oneway*
> is made. A provider should decide on it's own considering the documentation
> history and current data.
>
> It is totally unacceptable to let a GPS provider "decide on its (not it's)
> own" (what?) based on fuzzy and vague "documentation history and current
> data".  OSM is the place that *must* contain the data to be used and,
> should the oneway status be undetermined, routing must obviously be
> *requested* to not let the cars go through that place.
> If that undetermined status existed, contributors should not be
> recommended but requested explicit tagging.
> And hence, quality assurance providers should be *requested* to check
> motorway_link statuses and to warn the culprit and not an innocent as
> Osmose does, and even this Tagging list in such grave security cases.
>
> Please let us not make OSM responsible for car crashes.
>
> Cheers
>
> André.
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] highway=residential_link

[Joachim]

Many see _link only as slip roads. But using it for at-grade junctions
like described in the wiki has one advantage: _link is usually tagged
without a name because it connects two named roads and has none
itself. Using no link gives many warning in QA tools. Using
highway=residential plus noname=yes might be a workaround in the
current situation.

Examples where unclassified_link and residential_link might fit:
https://www.openstreetmap.org/way/286954889
https://www.openstreetmap.org/way/193840995
https://www.openstreetmap.org/way/155949371
https://www.openstreetmap.org/way/286954889

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

Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link

[Joachim]

2015-09-13 23:38 GMT+02:00 Paul Norman <penor...@mac.com>:
> On 9/10/2015 5:20 AM, Joachim wrote:
>>
>> Define on the wiki page of highway=motorway_link that oneway=* must
>> also be tagged for every motorway_link. If not tagged, the oneway=*
>> status of this way is undefined.
>
> Explicitly tagging oneway on links is preferable for obvious reasons, but
> you need to be careful with must, which is wrong for two reasons.
>
> - The wiki can document, but not set out requirements, as people can ignore
> the current state of the wiki.
> - Your next sentence discusses the lack of oneway
> - There is not a concept of formal validity, so must doesn't apply
> - Data consumers will make their own decisions

Your concerns are valid and I changed the tone of the proposal with a
rename from "obligatory oneway" to "no default oneway". I know the the
meaning of "MUST" from IETF RfCs, but "SHOULD" would be more
appropriate here.

The first sentence about the proposal is now: "Strongly recommend
explicit tagging of oneway=* on highway=motorway_link." "

I also put this sentence in:
"The goal of this proposal is removing the implied oneway=yes on
highway=motorway_link from documentation. The following implied
default oneway=no is also undesireable and could lead to dangerous
situations in navigations. "

The statement about the routing was already changed, so I will put
this on for voting soon if no other objections are coming.

http://wiki.openstreetmap.org/wiki/Proposed_features/Motorway_link_no_default_oneway

Regards, Joachim

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

Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link

[Joachim]

2015-09-14 2:40 GMT+02:00 Richard Welty <rwe...@averillpark.net>:
> quite. there are sections of motorway_link highways along the taconic
> parkway in NY which are two way and so lack oneway tags. now it's not that 
> hard
> to go through and fix it, but i'm reasonably sure this is not the only place 
> where
> this situation exists.

Most of Taconic Parkway is trunk and trunk_link which never implied
oneway. You should go through in order to improve safety.

> if you impose a restriction like this, then routing will be broken for
> some not yet
> identified set of links for an unknown period of time. nobody is going
> to do that.

Routing is already dangerously broken on some of the ~1400
motorway_link without oneway=* in North America since Mapquest and
Graphhopper don't imply oneway. Without turn restrictions, which I
doubt existing, they might lead you the wrong way.
Example routing: http://preview.tinyurl.com/qxyavwd
Overpass: http://overpass-turbo.eu/s/bu9

I checked a good amount of the North America Overpass query and many
of them, but no majority, implied oneway=no.

Regards, Joachim

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

Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link

[Joachim]

> Though I agree in principle with the idea of making tagging more
> explicit, how big of a practical concern is this? i.e. how many times in
> the real world is motorway_link a two-way road?

This is quite common in some parts parts of Europe. Here an Overpass
Turbo link which covers south-western Germany, Switzerland and parts
of France. The are 186 motorway_link ways with oneway=no:
http://overpass-turbo.eu/s/bp5
An usual design of a motorway exit in Germany has a shared section
near the lower road and then splits up nearer to the motorway (shaped
like a "Y").

Regards, Joachim

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

Re: [Tagging] New proposal: Obligatory tagging of oneway on motorway_link

[Joachim]

Considering that most replies where not in favour of dropping routing
over "undefined oneway" I changed the sentence about routers:
"- For routing purposes no recommendation for ways with undefined
oneway is made. A provider should decide on it's own considering the
documentation history and current data."

The main part of the proposal is about the requirement of explicit
tagging, so I'm going with the consensus about routing. If you have
better wording, feel free to change the sentence.

Regards, Joachim

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

[Tagging] New proposal: Obligatory tagging of oneway on motorway_link

[Joachim]

I drafted up a proposal about oneway=* for highway=motorway_link.
Please comment.
http://wiki.openstreetmap.org/wiki/Proposed_features/Motorway_link_obligatory_oneway

Proposal:
Define on the wiki page of highway=motorway_link that oneway=* must
also be tagged for every motorway_link. If not tagged, the oneway=*
status of this way is undefined.

- For rendering purposes ways with undefined oneway should be
displayed like the default, i.e. without oneway arrows.
- For routing purposes it is recommended to not route over ways with
undefined oneway since any assumption may be wrong and it would be
best to correct the data.
- In map editors undefined oneway should be displayed as tagging error.

Cheers, Joachim (Jojo4u)

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

[Tagging] Feature Proposal - RFC - Site Relation

[Joachim]

The relation type=site proposal [1] has been around for seven years
now. Milliams is the original creator of the draft while Joshdoe
cleaned up the proposal page, added some to the discussion and also
sent out an RFC in 2011 [2].

The relation has a bit of troubled history since the original idea -
usage for a typical school - is strongly discouraged now. The RFC
brought up the point that the relation is not needed if the feature
can be represented by a polygon.

The definition now is: "A way to group features (represented by
nodes/ways/areas/relations) which belong together but cannot be
adequately described by an area/multipolygon. [...] This relation is
understood to group man-made objects. For groups of natural objects
which share the same name see proposed relation Cluster. "
Further changes since the last RFC:
* The key site=* has been deprecated, better use the full tag instead
(e.g. amenity=university).
* The label role has been removed since this is strongly resisted by
cartographers.[3]
* The entrance role has been removed since it did not fit the new
definition. Discussion is ongoing to readd it.
* The perimeter role has been moved to a sub-proposal with new definition.
* Documented usage examples from the wiki have been added.

I'd like to bring your attention to the proposal. Please visit the
proposal page [1] and add your comments to the discussion.

Cheers, Joachim (Jojo4u)

[1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
[2] https://lists.openstreetmap.org/pipermail/tagging/2011-February/006730.html
[3] 
https://github.com/gravitystorm/openstreetmap-carto/pull/546#issuecomment-45504933

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

Re: [Tagging] symmetrical guardrails

[Joachim]

Just draw a closed way. This also represents the reality since there
are two rails.

2015-07-11 11:04 GMT+02:00 Volker Schmidt vosc...@gmail.com:
 The wiki page
 http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dguard_rail
 says:
 If there is a clear inner/outer demarcation to the guard rail, construct
 the line so that the right side is inner and left side is outer.
 Often you find perfectly symmetric guardrails
 (example: http://www.mapillary.com/map/im/9-9-x8ynIiIdpNQHeA5CWg)

 I would like to tag this fact. Any examples or suggestions?


 ___
 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] How to recognize memorial from monument?

[Joachim]

The size: If you can walk in it's a monument. There might be cases
where there is clearly enough space for many people but no provisions
have been made. Here I would compare to other monuments in
city/country.

2015-07-11 13:03 GMT+02:00 Daniel Koć daniel@koć.pl:
 Simple question, hard problem: how to recognize (1) memorial from (2)
 monument?

 Definitions on Wiki are not clear and I think they need some love to make
 them easier to use in practice:

 1) A feature for tagging smaller memorials, usually remembering special
 persons, peoples lost their lives in the wars.
 Memorials can be often found at public greens or cemeteries.

 2) A memorial object, especially large (one can go inside, walk on or
 through it) and made of stone, built to remember, show respect to a person
 or group of people or to commemorate an event.
 Monuments are often built in homage to past or present political / military
 leaders or religious figures / deities.

 So what is a deciding factor here:
 a) size (all examples of monuments are 15+ m),
 b) wartime/all other (however military leaders are sometimes also
 causalities of war),
 c) unknown and real people / widely known and legendary
 d) being the landmark (statue in park is typically much less important and
 visible than the same statue in the middle of a square)

 or maybe it's just purely subjective choice?

 It is important for me, because in Warsaw we have a lot of such places and I
 like to have some uniformity in tagging across the whole city.

 BTW: memorial can be war_memorial, but it can also be in the form of statue,
 stone or any other type at the the same type, so it seems the form and
 function are unfortunately mixed here.

 --
 The train is always on time / The trick is to be ready to put your bags
 down [A. Cohen]

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

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