Re: [Tagging] RFC: vaccination / COVID-19 vaccination centres

2020-11-30 Thread Florian Lohoff
On Wed, Nov 25, 2020 at 02:36:06PM -0800, Joseph Eisenberg wrote:
> The proposed new tag, vaccination= available>, seems like a reasonable idea.
> 
> However, it might be necessary to discuss a main feature tag to use in the
> case when these are not administered by a clinic or doctor's office or
> hospital.
> 
> There does not seem to be a widely used, suitable tag under healthcare=* or
> amenity=* for a place that specializes in administering immunizations only.
> 
> healthcare:speciality=vaccination is not a primary feature tag, but a
> secondary tag which needs to be added to something under the key amenity=*
> or healthcare=*.
> 
> Perhaps amenity=vaccination_centre would work?

Yes please - I can see planning coming up for vaccinations centers here 
in Germany and these are not planned in hospitals but in vacant commercial
buildings which have loads of parking spaces. So using some
healthcare specific tag is probably misleading.

These will be temporary things (Timeframe be years) but LOADS of people
will try to find it. And its a global issue.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Benches and hostile architecture

2020-08-24 Thread Florian Lohoff
On Sun, Aug 23, 2020 at 01:22:38PM -0700, Joseph Eisenberg wrote:
> The term "hostile architecture" is too vague. As an alternative
> "anti-homeless" is also not precise enough. We are getting closer with the
> initial suggestion that the feature is to prevent lying down, sleeping or
> sitting.

Its not just anti-homeless there are also features which are explicitly 
anti-skateboard etc

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] ref on roundabout

2020-08-23 Thread Florian Lohoff
On Sat, Aug 22, 2020 at 01:28:07PM +0200, Mateusz Konieczny via Tagging wrote:
> Aug 22, 2020, 12:17 by f...@zz.de:
> 
> > On Sat, Aug 22, 2020 at 12:09:14PM +0200, Mateusz Konieczny via Tagging 
> > wrote:
> >
> >> I would expect roundabout to be split in parts where
> >> ref is applying and parts where it is not applying, in other words
> >> without any special handling and tag it as usual.
> >>
> >
> > But the point is that on a roundabout the "name" references the name
> > of the _roundabout_ not one of the streets connected to it. 
> >
> Yes
> 
> > Same should apply to ref as it will reference the Roundabout
>
> why?

1. How do you tag a reference number for a roundabout when suddenly
the ref contains a ref of one of the streets?
2. Inconsistency - Some informations on the roundabout contain
informations about itself, and some are just copied over from 
attached streets.

> So it is about case where road has its own reference number
> and junction has its own reference number, separate from
> reference number of road routes?

Yes - We should be consistent that an object carries informations about
itself and ONLY itself and not carry on some information of related
objects. To glue objects together or describe their relation 
we typically use relations. We do this in Germany a lot - So primary
roads typically have relations carrying all road segments including
the roundabout. 

> In Poland road route continues through roaundabout and roaundabout way
> is part of such route.

Correct - In Germany - at least for "Straßen NRW" thats the same. The
road surface of the roundabout is part of the Road through it. But
nevertheless - OSM has had a different Data Model to address/reference
roundabouts itself to be able to do landmark routing e.g

"Take 1st exit at the Hampstead Roundabout, then take the 2nd exit at
the Foobar Roundabout".

For this to work you have to put the information about the roundabout
itself somewhere. This has been documented for ages to be the
way carrying the junction=roundabout which has a name tag on its own.

So using ref on the roundabout for either the road, or a reference
of the roundabout breaks the assumptions that informations on the
junction=roundabout only refer to the roundabout. With this concept
it may sometimes refer to one or more roads which are connected to the
roundabout. This basically makes the information useless.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] ref on roundabout

2020-08-22 Thread Florian Lohoff
On Sat, Aug 22, 2020 at 12:09:14PM +0200, Mateusz Konieczny via Tagging wrote:
> I would expect roundabout to be split in parts where
> ref is applying and parts where it is not applying, in other words
> without any special handling and tag it as usual.

But the point is that on a roundabout the "name" references the name
of the _roundabout_ not one of the streets connected to it. 

Same should apply to ref as it will reference the Roundabout e.g.
otherwise there would be no way to e.g. say tag a roundabout
with "East 1" or "No 1" because the Ref is taken by one or all
of the streets. 

Adding all refs of all streets PLUS that of the roundabout would
make it even worse as you couldnt distinguish which of the refs
references the Roundabout and which of the refs is that of the streets.

So i simply say when the logic is that the way with
"junction=roundabout" is not part of the streets and has a life of
its own with e.g. established with the name tag - same should and must
apply to the ref.  This does not prohibit adding the roundabout to some
kind of relation containing all parts of a road in a road network.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] ref on roundabout

2020-08-22 Thread Florian Lohoff

Hi,
there is a little Discussion in the German forum concerning ref
tagging on Roundabouts. After looking at the Wiki again somebody
added (In April 2019) a section saying refs of the roads should 
continue on the ways with "junction=roundabout":

"[[File:Roundabout_Ref_Consistency.png|thumb|Roundabout with ref tagging
consistent with connecting roads]] For roundabouts that have ways either
continuing through, or ending at the roundabout, {{Tag|ref}} and
{{Tag|int_ref}} tags from those ways should be added to that roundabout.
This allows routing to navigate through the roundabout more fluidly."

Has this been discussed somewhere? This is highly inconsistant with
the name meaning the roundabout and the ref not meaning the roundabout.

I strongly disagree with this section and i doubt there has been some 
concensus about this so i would like to revert this.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Is there any case of valid numeric addr:housename - for example addr:housename?

2020-07-01 Thread Florian Lohoff

Hi *

On Tue, Jun 30, 2020 at 03:16:38PM +0200, Martin Koppenhoefer wrote:
> sent from a phone
> > On 30. Jun 2020, at 15:08, Mateusz Konieczny via Tagging 
> >  wrote:
> > 
> > Is there some chance that any of them is valid?
> 
> 
> IMHO not, these are likely autocompletion bloopers. I’d support an
> automatic retagging effort to addr:housenumber (unless there is
> already a different housenumber)

I had a quick look as addr:housename around where i feel interested
and 99% are broken. Most of the time it belongs into name as its
the companys name, sometimes its abused as replacement for ref
of buildings. Sometimes its just a duplication of some other
tags content.

And most of the time you find that you'll find even more tag abuse 
and random invented tags. In my case they were mostly 8+ years old.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] QA Tag for addr:city vs al8/al9 boundary

2020-06-30 Thread Florian Lohoff
Hi Tod, Simon,

On Tue, Jun 30, 2020 at 09:49:50AM -0700, Tod Fitch wrote:
> Simon is being much more polite and succinct than my first reaction.
> Checking the addr:city against the enclosing administrative boundary
> will not work well in the areas I am familiar with.

Then make it a broader request for QA based tag hinting like noexit=yes
I dont care if this matches internationally. Addresses are basically
such a can of worms that one size will never fit all. And it fits
in Germany for i guess 90% of all al8/6/4

So i'd be happy to have some hierarchy of tags which are implementation
specific like

qahint:addrcity=Marienfeld

or the like.

Currently all the people doing QA do their own little QA
override/exception list maintenance which is a pain in the ass.

We share the same goal, we have the same problem and we have no
place to put this type of QA hinting/override. From OSM history
we do have tags like noexit for QA hinting. 

And i do have other issues i would like to QA hint aswell. We
do have 1% of strange constructs in the OSM Database which wont
fit into automatic checking and before we keep that beeing
red in every QA frontend and people breaking data because
some QA frontend showed it red, i'd rather do some universal
and consensual hinting of "you dont need to look at this data"
from a consistency based approach, please ignore it, or better
hint the QA to make better decisions. 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] QA Tag for addr:city vs al8/al9 boundary

2020-06-30 Thread Florian Lohoff

Hi,
i am running some address validation pipeline as others do aswell. In
Germany we have the case that most of the time the addr:city
on the addresses matches the name on the admin_level 8 boundary
(Sometimes admin_level 6).

So normally you have:

boundary=administrative
admin_level=8
name=Gütersloh

And all addresses carry a

addr:city=Gütersloh

Now there are some exceptions. One example i always paint red in the
validator is 33428 Marienfeld.

For Marienfeld there is an admin_level=8 which carries the
name=Harsewinkel which is correct for all "suburbs" or villages
belonging to Harsewinkel except Marienfeld.

Marienfeld itself carries a admin_level=9

So i'd like to have a place in OSM where i store this exceptions
information (There are plenty other places which have this
exception).

So i would propose to set an "addr:city=Marienfeld" on the admin_level=9
boundary. So the address validator knows that addresses contained within
this al9 should carry a different addr:city than they normally would
using the al8.

Other ideas?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Adding mapillary tags to every building

2020-06-05 Thread Florian Lohoff

Hi Mateusz,

On Thu, Jun 04, 2020 at 06:13:12PM +0200, Mateusz Konieczny via Tagging wrote:
> Jun 4, 2020, 16:00 by vinc...@bergeot.org:
> 
> > Le 04/06/2020 à 15:49, Mateusz Konieczny via Tagging a écrit :
> >
> >> You have right to use your own images, AFAIK there is also a special 
> >> permission
> >> for OSM mapping but otherwise images are owned by them.
> >>
> >
> > mapillary picture are CC-BY-SA, you can use pictures and download them 
> > without pay nothing.
> >
> Scroll down on https://www.mapillary.com/pricing to "Commonly asked questions"
> "Can I download image files?"
> 
> You can download thumbnails (up to 2048 pixels wide) of Mapillary public 
> imagery,
> and originals of images you've contributed yourself. If you have a 
> subscription to 
> Mapillary public imagery, you can use and access the imagery for commercial 
> use 
> through the Mapillary platform, integrations, and APIs. You will not be able 
> to 
> download original image files.
> 
> I have no idea how at at the same time Mapillary claims on the same page
> "Mapillary imagery is also available under an open license (CC BY-SA)."
> and offers "Use Mapillary public imagery" for 2000$/year (up to 25km of roads
> is free according to this page)

> Mapillary claims that it is not possible to download original images even if 
> you 
> are a paying customer.
> 
> Overall it leaves me even less interested in their project.

I guess downloading original images cant be done for legal reasons e.g.
privacy. Mapillary would only be allowed to publish images with
processing e.g. blurring faces, number plates etc. 

As a registered user i can access my originals. 

But my workflow is different. I changed to keep all images i upload. 
So in case Mapillary is going "belly up" i still have all my images
i still can use or reupload somewhere else. And i tried uploading
to openstreetcam aswell.

So - I am pretty clear about limits of Mapillary and i once wrote
my own toolchain to store and visualize and i could revive that.

I am still happy they exist and i uploaded 12+ images covering
1000km+ - I did systematic street overview images for the towns i 
care about mapping. I did it in 2014/15 and now refreshing.

I wished OSM would offer a similar service integrated into our
toolsets etc. As long as we dont have it we need to be thankful
somebody else has build a businessmodel which pays for the gigantic
storage and processing needed.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Overlapping naturals

2020-06-04 Thread Florian Lohoff

Hi Mateusz,

On Tue, Jun 02, 2020 at 11:19:10PM +0200, Mateusz Konieczny via Tagging wrote:
> You can have forested military base with wetland (real case).
> 
> You can probably find military base (landuse=military) with landuse=farmland.
> 
> There are residential areas in forests, there are industrial zones in 
> military bases,
> there are railway areas in military bases.
> 
> etc etc
> 
> You will have overlapping areas or stuff like
> landuse=military_industrial_area_under_tree_cover_with_intermittent_wetland

If you have a residential area in a forest - Is that area used for
residential or for forestry purposes? 

Isnt that a landuse=residential with landcover=forest?

IMHO a square meter has ONE predominant usage and thats what we tag. It
might be that there are trees in my backyard - still its a residential
area. People try to map the trees and use landuse=forest for that but
thats simply broken.

I have seen people map every single backyard with landuse=grass,
landuse=meadow, leisure=common or leisure=park which is completely bogus.
Its still a residential area its just grass growing there.

So i am still standing on the issue that there can only be ONE usage of
an area. I could agree on that a military area could contain a
natural=beach, or a wetland - but still landuse may not overlap landuse
and natural not natural. Its either a residential or miliary or
industrial or commercial or forest.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Overlapping naturals

2020-06-02 Thread Florian Lohoff

Hi Rafael,

On Tue, Jun 02, 2020 at 04:05:47PM +0200, Rafael Avila Coya wrote:
> Hi, all:
> 
> Let's say we have a natural=scrub for example. Inside it (a part of it)
> becomes seasonally wet, for example during the rainy (wet) season. How would
> you better map this? Some possible approaches:
> 
> 1. Having the area of all the scrub as natural=scrub, and the area that
> becomes wet in its interior as natural=wetland + seasonal=yes (or
> seasonal=wet_season)
> 
> 2. Having a natural=scrub for the whole area, and for the wetland area
> temporary:natural=wetland @ (May-Oct) or temporary:natural=wetland @
> (wet_season)
> 
> 3. Using a relation, with the tag natural=scrub, and the inner way with the
> tags natural=scrub + temporary:natural=wetland @ (...)

For me overlapping natural or landuses are broken. An area can either
be a natural=wood or a landuse=farmland. You cant include the same
area in two types of usages or naturals.

So in any case you need a MP relation.

But that might just be me. I have created a validation layer for parts
of Germany for this.

In your specific case - Its a wetland which IMHO implies that it may
fall dry sometimes. 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Highway mistagging ... again

2020-05-30 Thread Florian Lohoff

Hi,

On Fri, May 29, 2020 at 04:10:42PM -0600, Mike Thompson wrote:
> I know we just had a similar discussion, but I am discovering more and more
> cases where mappers have changed every dirt road they can find to
> "highway=track".  For example, it looks like all of the dirt roads in the
> area of this way: https://www.openstreetmap.org/way/17051445 have been
> changed to "highway=track", when at least most of them should be
> "highway=residential."  What can be done to better communicate that OSM has
> a functional highway classification system (I did leave a change set
> comment, but I doubt it will do any good)?

I am fighting for this now 10+ years and its a hard fight. I live in the
countryside and regularly people show up, retagging everything to track.
Most of the times its people living far away in pretty urban areas.

I found the description of what a track is good. All osm wiki articles
for highways classes miss the point "When does this _not_ apply".

For tracks i have simple criteria when it cant be a track:

- residential buildings (or used for reaching them)
- (school) buses
- garbage collection trucks
- postal services

If anything is seen on that road it cant be a track. A track is defined
as a road for exclusive or mostly agricultural usage. So as soon as
there is a single residential building the amount of traffic for that
building outweights the amount of agricultural traffic by orders.

So a farms driveway is also not a track.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-27 Thread Florian Lohoff
On Wed, May 27, 2020 at 08:17:20AM +0200, Arne Johannessen wrote:
> I interpreted "random person" as meaning "random traffic, not destined
> for your uncle's residence".
> 
> But perhaps you meant that the person is in fact a visitor destined
> for your uncle's residence – maybe trying to sell something or
> conducting a poll or whatever – and that doing so would be illegal? If
> so, in what way is it "clear" to the visitor that what they're doing
> is illegal?

I guess 90% of the typical driveways are "cul de sac" anyway - So there
cant be any through traffic. Technically the ones driving on that
way have a clear intent and will be visitors.

So tagging cul-de-sac with destination is nice - but basically a "no
op" for many reasons (Already has penalty in routing, technically no
through traffic possible etc etc)

Thats the point with the whole driveway discussion. Tagging any further
restriction on a driveway does at best change nothing, worst 
case make it unusable. You wont _gain_ anything.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Change of wiki page Key:access

2020-05-26 Thread Florian Lohoff
On Tue, May 26, 2020 at 06:46:11PM +0200, Mateusz Konieczny via Tagging wrote:
> May 26, 2020, 18:04 by fernando.treb...@gmail.com:
> 
> > Bikes may "pass" in two different ways: riding
> > (bicycle=yes/permissive/destination) or pushing (bicycle=dismount).
> > Bikes are only completely forbidden if bicycle=no/private.
> >
> bicycle=no does not mean that you cannot push bicycle
> bicycle=no and bicycle=dismount are de facto equivalents
> we have no widely used tag to indicate "walking with bicycle is illegal here"

Is it that in every jurisdication a cyclist pushing his bike is
considered a pedestrian?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Change of wiki page Key:access

2020-05-26 Thread Florian Lohoff
On Tue, May 26, 2020 at 11:10:17AM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 25. May 2020, at 20:37, Florian Lohoff  wrote:
> > 
> > i'd expect OSM
> > offering me a conflict free (in legal and physical terms) route based
> > on the tags it finds.
> > 
> > This is especially true for transit e.g. traversing something. This is
> > pretty inline with my in-car-nav (Mercedes E Class). It will not send
> > you where you are not allowed to go.
> 
> You must acknowledge that (supposedly) most countries are not applying
> traffic rules the way Germans do, particularly when it is about
> bicycles and not about motor vehicles. Car navigation is in no way
> comparable to bicycle navigation, and not only because as a cyclists
> you can become a pedestrian any time you want by dismounting and
> pushing, but also because bicycles may not be considered “real”
> traffic by the police.

But still - Are we going to send people where we are in doubt they are
legal to go? I guess anyone will answer no - So how do we translate
that into good language.

My intention is to remove as much interpretation, fiction, feelings
from the access tag creation as possible. I'd like to get something
into hands of mappers as a "decision tree" - "When in doubt do this"

If you have better wording i am happy with that.

For me there does not need to be a restriction if there is no clear 
intention visible - And that should be the case for most countries.
You cant expect people to not do something until instructing them.

The opposite - Whether a way may be used for bicycles which we talk
about right now is not in the scope of the original modified article
as we are not talking about setting bicycle=yes on EVERY way. There
are ways which have this as a default, and if your impression is that
this specific way is only for foot - use footway and be done?

My impression was that a

[bicycle|foot|car|hgv|...]=no/private/permissive/...

is always a matter of signage as you are restricting from the
defaults, whereas 

[bicycle|foot|car|hgv|...]=yes

is either from the defaults of a way or a signed exception so for
an example there is a cycleway which allows cars for destination or
something.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Change of wiki page Key:access

2020-05-25 Thread Florian Lohoff
On Mon, May 25, 2020 at 01:38:57PM +0200, Florimond Berthoux wrote:
> I have encounter this issue many times : reality vs traffic sign.
> No vehicle acces to the wood in Paris, except that cyclist go there and
> that normal.
> A living street sign on a transit road.
> Etc.
> 
> I would like to be able to tag separately the sign/law and the 'on the
> ground' reality.
> 
> For the default I'd say tag the reality if there almost no change to be
> blamed for violating the sign.
> 
> So for me the new tag would be
> motor_vehicle=no
> bicycle:dejure=no
> 
> Or if there is a little change to be blamed, bicycle:defacto=yes is nice
> too.
> 
> Could work also for highway :
> highway=tertiary
> highway:dejure=living_street

What would be your expectation which rules a router should honor? The
ones on the signs or the ones people actually do?

My expectation would be that an OSM based routing engine should never
send me where there is doubt i am allowed to go. It is okay for locals
to use it, but a someone from a different area/country i'd expect OSM
offering me a conflict free (in legal and physical terms) route based
on the tags it finds.

This is especially true for transit e.g. traversing something. This is
pretty inline with my in-car-nav (Mercedes E Class). It will not send
you where you are not allowed to go.
If there is some area with restrictions e.g. "Drop off zones at
Airports" or "Taxi spaces at railway stations" it will only send you
there at the final leg of your journey, and it'll warn you that you are
entering a restricted area before turning into it.

As a little anecdote what happens: I once tried to reach a campsite and
following my little Garmin on the bike. I ended in clear sight of the
campsite but with a River of ~40 meter width between me and the campsite. 
The reason was that the track i was on was actually the nearest point
on the routable network to the campsite. The divert was actually
something like 15km of which 10km were simply going back where i came
from. Somebody had tagged all the surrounding roads with access=private
so there was no other legal way of getting to the campsite by osm
tagging specs. This is one of the reasons why i am an opponent
of excessive and non justified access tagging. If we violate the on the
ground and verifyability of access restrictions there is no way to turn
back to a common ground. Reality will not matter anymore and we will
have tons of discussions with mappers about some invented or fictional
access restrictions.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] [OSM-talk] Should we map things that do not exist?

2020-05-25 Thread Florian Lohoff
On Mon, May 25, 2020 at 10:12:34PM +0800, Phake Nick wrote:
> > So - To quote from Postels Law - On of the inventors of the Internet:
> >
> > "Be conservative in what you do, be liberal in what you accept from others"
> 
> Your email initially sound like you thinl they shouldn't be deleted but
> then it sound like you think they shouldn't be kept?

Its a matter of common sense. No we dont want to delete everything
immediatly - but for the sake of common ground for decisions we should
try to stick near the "On the ground" rule.

So be liberal but in case of dispute we need to stick with "On the
ground"

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Access tag abuse examples

2020-05-25 Thread Florian Lohoff
On Mon, May 25, 2020 at 01:48:20AM +0200, Mateusz Konieczny via Tagging wrote:
> >
> Wrong tagging is not interesting by itself.
> 
> I was looking for real-world situation where 
> 
> (1) there is some seemingly good overcomplicated tagging
> (2) there is a good and simpler replacement


The classic case is that people to not use "vehicle" or "motor_vehicle"
but tag all individual subtypes individually, sometimes even
with their parent.

So there is no need for

motorcycle=destination
goods=destination
hgv=destination
car=destination
mofa=destination

When there is a "motor_vehicle=destination"

Some mappers live under the impression that the more they tag the
better. So it is important to tell them to match the best and most exact
scope of the signage. 

Most signs just exclude all vehicles or all motor_vehicles. So no needs
to list them individually. We have a tag for that.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] [OSM-talk] Should we map things that do not exist?

2020-05-25 Thread Florian Lohoff

Hola,

On Mon, May 25, 2020 at 08:52:21AM +0200, Colin Smale wrote:
> 1. Live and let live - OSM has always been a broad church. It might not
> be your hobby, but it is their's. The bar to actively deleting other
> people's work should be set very high indeed. 

I subscribe to this aswell. As long as it does not collide with stuff
in use we should be able to tolerate data of historic or special purpose
most of us probably do not aim for.

The broad scope of your subject must otherwise be answered with: "No"

It IS Best Common Practice to follow the "On the ground" rule with only
very few exceptions.

And IMHO we cant lift that. OSM needs to have a common ground to discuss
matters and sometimes reality is already pretty hard to agree on. If we
now add stuff in history or in the minds of mappers we open a pretty
difficult can of worms.

So - To quote from Postels Law - On of the inventors of the Internet:

"Be conservative in what you do, be liberal in what you accept from others"

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Change of wiki page Key:access

2020-05-24 Thread Florian Lohoff
On Sun, May 24, 2020 at 11:42:09PM +0200, Volker Schmidt wrote:
> -- Forwarded message -
> The OpenStreetMap Wiki page Key:access has been changed on 24 May 2020
> by Flohoff, see https://wiki.openstreetmap.org/wiki/Key:access for the
> current revision.

This follows HUGE changes to that article currently discussed on talk@osm
which introduced a ton of issues.

> To view this change, see
> https://wiki.openstreetmap.org/w/index.php?title=Key:access=next=1994688
> -
> In my country (Italy) there are literally thousands of ways where it is
> most likely legal to pass by bicycle, but there is no (practical) way of
> finding out.
> Essentially two classes:
> 
>- plenty of ways that look from the layout like combined foot-cycle
>paths but have  no signage at all
>- plenty of service roads which show the "no transit for any vehicle"
>sign <https://images.app.goo.gl/Uh6yNJ5V646TMrWw7>, but in reality you
>can happily pass with your bicycle and no policeman will ever say anything,
>or even know that "no vehicle" legally includes "no bicycle", There are
>plenty of cases where even signposted cycle routes follow such roads.
> 
> I am consistently using bicycle=permissive in these cases, well being aware
> that I do not know of he owner has given permission. Basically any
> cycle-routing would come to a halt without this trick.
> 
> The strict wording introduced by Florian is simply not practically
> applicable here.
> My questions are:
> Is Italy the only country with this problem?
> Is there any better proposal for tagging the situation "from all I can see
> on the ground, you are allowed ride through with your bicycle"

But from the point of expectation. Could a OSM User expect the 
tagging in OSM to be legally perfect? I suggest we as OSM would
not send people through roads we are not shure are legally usable.

And if you are unshure if a cyclist is allowed to go there shouldnt
you avoid sending others there? At least if you are in serious doubt.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] oneway=yes on motorways

2020-05-24 Thread Florian Lohoff
On Sun, May 24, 2020 at 11:52:54PM +0200, Volker Schmidt wrote:
> I am aware of the histroy - I only wanted to bring up the contradiction
> between the two wiki pages *before* changing the wiki.

Feel free - The "new" (Most likely a decade old) way is that motorways
and roundabouts have an implicit oneway=yes and dont need it.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] oneway=yes on motorways

2020-05-24 Thread Florian Lohoff
On Sun, May 24, 2020 at 10:26:19PM +0200, Volker Schmidt wrote:
> I just noticed an apparent contradiction regarding the use of the oneway
> tag between the wiki pages key:oneway
> <https://wiki.openstreetmap.org/wiki/Key:oneway> and motorway
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway> .
> The former states:
> "Some tags (such as junction
> <https://wiki.openstreetmap.org/wiki/Key:junction>=roundabout
> <https://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout>, highway
> <https://wiki.openstreetmap.org/wiki/Key:highway>=motorway
> <https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway> and others)
> imply oneway=yes and therefore the oneway tag is optional,
> the latter states:
> "These ways should all point direction of travel and be tagged with oneway
> <https://wiki.openstreetmap.org/wiki/Key:oneway>=yes"
> <https://wiki.openstreetmap.org/wiki/Tag:oneway%3Dyes>
> 
> What is the agreed standard, if any?

In ancient OSM history roundabouts and motorways had oneways. This has
since been obsoleted and implicitly assumed on those ways.

At least thats my memories from 1 1/2 decades.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] natural=water inside natural=wetland

2020-04-30 Thread Florian Lohoff
On Thu, Apr 30, 2020 at 04:36:31PM +0200, Jean-Marc Liotier wrote:
> Consider a wetland that contains a water body. I'm used to map that as
> natural=water inside natural=wetland - no multipolygon fanciness, just one
> on top of the other. JOSM validator complains about it, which irks me, so I
> opened a ticket at https://josm.openstreetmap.de/ticket/19171 - where mdk
> suggests that I may be doing it wrong...
> 
> Is my simple way incorrect ? It feels correct to me because wetlands are
> complex objects - water bodies are part of them, cross them or partially
> overlap them. From a tagging point of view, it implies that some area is
> both natural=water and natural=wetland - I see no problem with that... But
> others might consider that a logical impossibility.
> 
> So, which is the correct way: plain natural=water inside natural=wetland, or
> a natural=water multipolygon with natural=wetland on its inner ?

I have myself some QA stuff running and i also do consider this a bug.
A squaremeter can either be wetland or open water e.g a pond. So
cant simply layer them.

I also do consider overlapping natural and landuses to be a bug,
either its a natural=scrub or a landuse=farmland. It cant be both.

I agree that there are corner cases where this fails. E.g a pond
in a landuse=residential or landuse=forest. Its still the forest.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Landfills timespan

2020-02-20 Thread Florian Lohoff
On Thu, Feb 20, 2020 at 10:32:05AM +, Jez Nicholson wrote:
> Mapping of things that cannot be verified on-the-ground has to be a very
> special case. Such as underground power cables.
> 
> A currently active landfill and a completed/capped-off landfill are not the
> same thing. One is verifiable on-the-ground, the other is not. One has a
> [surface] landuse of being a waste dump, the other has been returned to
> another landuse such as building or using as a park. Sure, under the
> surface there is some waste, but I don't believe the purpose of OSM is to
> map the subsurface.
> 
> Ex-landfills are notoriously difficult to spot and, in the UK at least,
> people just didn't keep records because "out of sight, out of mind".
> Geodata for ex-landfills is much prized in the property environmental risk
> industry.

Lately in my area old landfills from the 60ies and 70ies have been
opened again for maintenance. They are forest by now but all trees have
been removed beforehand. So those landfills are now observable.

I'd like to map them now - so i see the issue of mapping closed
landfills.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

2020-01-12 Thread Florian Lohoff
On Fri, Jan 10, 2020 at 09:39:44PM -0500, Jarek Piórkowski wrote:
> I was thinking about this whole thing earlier. Caution, wall of text.
> 
> At the risk of being philosophical, what is an address exactly?
> 
> Our wiki doesn't specify which address we're talking about:

Thats not the issue i am trying to solve. I am trying to solve the
issue

-> I want to go to point A - How do i get there and where is my
   best point to stop with a given mode of transport e.g. Car.

If my destination point A is defined by an address or a POI or
whatever - i dont care.

And this is not solvable without mapper input as a huge area like 
an Airport can not be mapped to a single "best point" on the
routable network.

And there are tons of "corner cases" which make this impossible.
In case of my example - there is confusing from which Street
a House is reachable by Car.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

2020-01-10 Thread Florian Lohoff
On Fri, Jan 10, 2020 at 09:34:32AM -0500, Jarek Piórkowski wrote:
> On Fri, 10 Jan 2020 at 04:22, Florian Lohoff  wrote:
> > OTOH in the dense urban areas you have the problem of Address for road A
> > nearer to Road B. So you get navigated to the wrong spot on the road
> > network. This view is generated with the OSRM Car profile and mapping
> > all addr:* objects with the "nearest" function and comparing the highway
> > name and the addr:street. If both are "filled" and non equal -> fail.
> >
> > https://osm.zz.de/dbview/?db=addresses-owl=namemismatch#51.98848,8.49342,18z
> 
> In the example of Cheruskerstraße 125a, how is it actually reached?
> Esri satellite imagery seems to suggest it's actually reached from Zum
> Alten Hammer. The tool flags this as a problem because of street name
> mismatch but it actually appears correct.
> 
> In the case of Cheruskerstraße 107g it looks like by far the easiest
> way to solve it is for the router to take footways into account. Or I
> guess we could create a new tag for "motor vehicle stop location to
> get to a given address" to work around router shortcomings...?

How can a router take footways into account when your mode of transport
is by car? Can it take ALL footways in the routing graph? Only some?
Which?

> Same with your later example of bicycle routing not checking for
> barriers like rivers and removing ways with access=private. That seems
> a lot easier to fix with software than by reorganizing the database.
> But then I'm not a router developer.

The processing of finding a point on the routeable network is a spatial
"nearest". I know if no nav solution which does something more
sophisticated. I'd like to be proven wrong.

And access=private has the mapper say - "This highway is NOT for general
consumption" so it is the correct processing in excluding this way from
routing. And i have heard this argument a hundret times. If you
take access=private into routing you break a gazillion of other cases
where the mapper explicitly wanted to exclude this way from routing.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

2020-01-10 Thread Florian Lohoff
On Fri, Jan 10, 2020 at 04:10:36PM +0100, Martin Koppenhoefer wrote:
> it is already linked spatially. What you have to do is map the campsite as
> area and map the reception within this area. Similarly for the parkings.
> Routing software should solve this contextually. If I am walking I want to
> be led to the main entrance (or given the choice which entrance), while
> when I am driving I will typically want a parking. A parking must not
> necessarily be inside the area, it can also be close by.

The point is there are literally thousands of possibilities and they may
even differ based on mode of transport. You go to point A by Foot, B if
on a Bike, C if using Car and D if you are in a HGV. 

Think of Ferry Terminal.

And for a single mode of transport you may even offer multiple destinations.  

So

- Mall A by Car and you get offered Parking North and Parking West
- Mall A by Bike you get offered the Bicycle Parking
- Mall A by Foot and you get offered the different entrances.

And i have literally thousands of buildings in my surrounding which fail
because they belong to street A, and have their parking on street A and
a footway to the entrance. Still they are nearest to street B. So anyone
routing there by car will end up on street B.
There is no way you'll be able to solve this by a spatial relation.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

2020-01-10 Thread Florian Lohoff
On Fri, Jan 10, 2020 at 12:37:21PM +0100, Martin Koppenhoefer wrote:
> For big buildings/POIs mapped as areas, I would expect the routing engine
> to bring me to the main entrance, or if not available, any entrance. I also

It doesnt. It generates a centroid of the area, searches for the nearest
road for that POINT. Routing is always to a POINT so you need to map
an area to a point. How do you achieve that?

> have seen similar problems, for example with the biggest airport in Rome:
> https://www.openstreetmap.org/search?query=fco
> Routing starts about 8 kilometers off the entrance and terminal buildings:
> https://www.openstreetmap.org/directions?engine=graphhopper_car=41.8144%2C12.2269%3B41.9010%2C12.5014#map=12/41.8377/12.3629
> 
> Route to the actual entrance:
> https://www.openstreetmap.org/directions?engine=graphhopper_car=41.8144%2C12.2269%3B41.7949%2C12.2522
> 
> I agree it will require more complicated heuristics to solve problems of
> this kind (e.g. a router could know, like a human does, that in an airport
> you want to arrive at the terminal, and not in front of a security fence at
> the closest point to some arbitrary "centre point"). IMHO the solution to
> the problem is not adding an address as a point (if it applies to a big
> area), but rather giving additional information (because where exactly you
> want to arrive may also depend on where inside the feature you want to go,
> so there won't be a single answer many of the times).

Heuristics will solve 90% for you - Normal buildings and a single
street.  This is what we have. How do you solve the rest of the 10%?
This is what i was talking about. Huge areas, Multiple Entrances,
Multiple Parking lots with different refs etc. You'd like to say -
"I'd like to go to Mall A" and the Nav Software asks "Parking West or
Parking North". How do you link that information?

How do you link the reception of a campsite to the area of the campsite?

I had the situation that i navigated to the campsite. I could see it -
just 30m in front of me. But a river inbetween. It was a 10km bicycle
ride to the next bridge. And from the algorithmic part everything
was correct in that case - Still broken for the user experience.

The cause was that all roads on the campsite were access=private so they
fell of the routing graph. So the nearest road to the area of the
campsite was the road on the other side of the river.

You need additional hinting to solve this. A machine cant do that for
you.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

2020-01-10 Thread Florian Lohoff
On Fri, Jan 10, 2020 at 12:11:10PM +0100, Marc Gemis wrote:
> > Footways are not part of the by car routeable network. And
> > access=no/access=private or highway=track and neither.

> This depends on the router, AFAIK Magic Earth navigates over private
> roads. It even combines it with access=destination roads that are
> connected to them.

I havent seen one in common use which does this. And i dont think any
navigatio solution right now does inter-modal selection of the nearest
spot on a road network, which you would need to do to include footways.

> > Commercial dataset map addresses back to nodes on the road - On specific
> > points. We as OSM rely on algorithms to do this automatically - And
> > fail in an astonishing large amount of cases.
> >
> > If you go to the center of a park by car there is no way the algorithm
> > can decide on the best spot to go there by _car_. So it uses the centroid
> > of the park, tries to find the nearest highway usable by your mode of
> > transportation. If that happens to be by car you might end up multiple
> > kilometers away from the optimal place to be. And there is nothing
> > we can do about it with this level of data abstraction.
> 
> There is no single 1 spot that is the best, even not for cars (or
> vehicles). Satnavs should allow you to refine the search for
> centroids. After telling the system that you want to drive to a park,
> it should (or could) offer you a few choices. Whether this is based on
> park entrances being mapped or parking places nearby is up to the
> software. I think this is not always solvable by mappers.

It is not solvable by algorithms. Mappers could select a node, or
multiple like on an Airport selecting multiple terminals and their
spots to go to.

> As for car navigation not taking paths and driveways into account.

> Again, that is a problem of the navigation software.
> I know OsmAnd uses driveways, as it always took my neighbour's
> driveway since in OSM it comes close to my house than my own driveway.
> OsmAnd does ignore any fence you draw. BTW, the private footpath to
> the frontdoor is not mapped.
> I do not think mappers should try to work around software limitations
> of their favourite satnav program. Those programs should be improved.

OSMAnd uses driveways, this is something i use extensively to fix
a lot of problems. But there are cases your CANT solve with this.
But OSMAnd (As all other Nav solutions - are not using inter-modal
road network nearest selection).

Think - Gated community with only footways. There is always a random
road near the building. But you never will get to the official parking
spot.

> We are so used to give an address and assume the software will bring
> us to the right spot, perhaps that flow has to be changed and not the
> data driving that flow.

Its not only we expect to reach the building for an address. We expect
this for ANY POI which is in our Database.

And as long as the mapper does not specific a very specific node
it is pure luck that we and up in the right spot. POIs on areas,
or addresses on areas and using a centroid of that area is just a
very broken approximation.

And the expectation is that a Nav Software offering a destination
to go to should REALLY know how to get there - Or show some
error bar e.g. "I can get you near the spot but its just an
approximation and my the error range is 1.5km"

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] POI data and Addresses on areas - Was: addresses on buildings

2020-01-10 Thread Florian Lohoff
On Fri, Jan 10, 2020 at 10:48:02AM +0100, Marc Gemis wrote:
> > OTOH in the dense urban areas you have the problem of Address for road A
> > nearer to Road B. So you get navigated to the wrong spot on the road
> > network.
> 
> I don't understand what this has to do with addresses on buildings vs.
> nodes. I would expect that an address is converted to coordinates. Then a
> route is created to get as close as possible to that point, regardless of
> the street names.
> So yes, if the router does not take services roads, footpaths etc. into
> account (or when they are not mapped), you might end up in the wrong
> street.

Footways are not part of the by car routeable network. And
access=no/access=private or highway=track and neither.

> IMHO, this also does not matter for POIs with an address on a building. The
> satnav should take the coordinates of the POI, not the centre of the
> building in which it is placed. Taking the centre of the (large) building
> might lead to problems.
> 
> So yes, one should try to map as many service roads, paths, internal
> corridors as possible to help routers. And yes, the coordinates taken by
> the router for the endpoint are important.
> but is this caused by addresses on buildings vs. on nodes ? no, not always,
> e.g for (apartment) buildings with multiple entrances with only address
> info on the building, it can go wrong. Not for small detached family houses.

Commercial dataset map addresses back to nodes on the road - On specific
points. We as OSM rely on algorithms to do this automatically - And
fail in an astonishing large amount of cases.

If you go to the center of a park by car there is no way the algorithm
can decide on the best spot to go there by _car_. So it uses the centroid
of the park, tries to find the nearest highway usable by your mode of
transportation. If that happens to be by car you might end up multiple
kilometers away from the optimal place to be. And there is nothing
we can do about it with this level of data abstraction.

The only decision is right now "nearest road with matching mode of
transport" and nearest is in a large number of cases not the place to
be.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] addresses on buildings

2020-01-10 Thread Florian Lohoff
On Fri, Jan 10, 2020 at 07:04:20AM +0100, Marc Gemis wrote:
> Perhaps I was not clear, what was pointed out is that it is sufficient
> to have the address on the building, there is no need to repeat it on
> the POI (besides the parts that are different such as unit_nr or
> floor).
> Although I now think that person said that it would be OK to have the
> address on a separate node next to the POI, which does not work if you
> only see a list of nearby Foobar POIs. In that list you want to see
> addresses as well.

I duplicate the address on the POI as then the POI is self contained. So
once the POI disappears the complete object may be deleted and not some
tags sorted.

A huge issue in workflow IMHO is that tags stay behind after some POI
disappears, or better, parts of the address get accidentally deleted
by someone editing the POIs information from an tag aggregating Object.

So i try to seperate out the individual functions of the objects. Makes
it much simpler in maintaining the data.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] POI data and Addresses on areas - Was: addresses on buildings

2020-01-10 Thread Florian Lohoff
On Thu, Jan 09, 2020 at 11:04:21PM +, marc marc wrote:
> Le 06.01.20 à 08:47, Florian Lohoff a écrit :
> > If you have HUGE Buildings i use a node with an address.
> 
> it's amazing the difference in usage.
> I find that addr nodes are very problematic for hudge buildings like
> shopping malls or train stations. the localisation of the node forces
> the routing to go to a specific location when you may be closer to
> another entrance.
> By putting the address on the building, you can not only allow quality
> reverse geocoding for the whole building, but also allow advanced
> routing to select the closest entry instead of going to the preferred
> entry of the contributor who entered the address.

That is a Huge problem putting informations POI, Addresses on Areas. I
addressed this on tagging a while back and was shot down that i should
tag sufficient. But there are tons of problems with non-explicit route
guidance.

My solution/proposal was to have a route/nav-aid relation. If you want
to reach Object A, with transport method B, you need to navigate to node C.

Just to get an impression about the impact i am creating to 2 debug
views (for myself and other interested partys) for parts of Germany.

A problem in the countryside are long driveways, sometimes not mapped,
tagged with random access tags or falsely tagged as tracks:

https://osm.zz.de/dbview/?db=addresses-nrw=routeable#51.63009,7.13605,15z


OTOH in the dense urban areas you have the problem of Address for road A
nearer to Road B. So you get navigated to the wrong spot on the road
network. This view is generated with the OSRM Car profile and mapping
all addr:* objects with the "nearest" function and comparing the highway
name and the addr:street. If both are "filled" and non equal -> fail.

https://osm.zz.de/dbview/?db=addresses-owl=namemismatch#51.98848,8.49342,18z

Just pan around and you'll easily spot horrible problems. The simple
case its just at a corner. But there are a lot of cases where you end up
significantly far away from the real address on a completely unrealated
road.


So yes - there are serious issues with the way OSM maps POIs and
Addresses and their usage for navigation.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] addresses on buildings

2020-01-05 Thread Florian Lohoff
On Sun, Jan 05, 2020 at 11:22:50AM -0700, Rob Savoye wrote:
>   I assume the right place for tags like 'addr:housenumber' &
> 'addr:street' are on the building way, and not a standalone node ?

In Germany we have both. And it depends on what actually makes sense.

These are my thoughts and usage:

If you have HUGE Buildings i use a node with an address. Because
navigation goes to a single location and i want to specifiy the
exact location someone is sent to. And not some random location
calculated by an algorithm broken down from the outline.

Then there are buildings which is a single building with no seperation
inbetween but multiple entrances with individual housenumbers. I
use nodes on those.

All simple buildings e.g. individual residential detached houses
i put it on the outline.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Florian Lohoff
On Wed, Oct 23, 2019 at 12:42:27PM +, Philip Barnes wrote:
> It is not just a British thing, I have encountered many when driving in 
> France.
> The rules and usage are the same as in the UK. 
> The other rule that makes them different to other roundabouts is that you 
> should not use them to turn around, do U turns.

So what is the difference then?

What i know learned:

- You may traverse the center
- No more than 4 exits as left/right/straight on wont work
- You dont expect nav aids to be "2nd exit etc" but a "turn left at" as
  the navaids are like a junction.

Anything else?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Florian Lohoff
On Wed, Oct 23, 2019 at 11:55:04AM +0200, Colin Smale wrote:
> I would suggest it is not necessary to replace the simple node with a
> circular way. I think it is perfectly acceptable if it is considered
> as a simple turn instead of negotiating a roundabout, from a routing
> perspective. An instruction to turn right at the junction would not be
> improved by an instruction to take the third exit. If the navigator
> knows that a junction is a mini roundabout, an instruction to turn
> right at the (mini) roundabout would probably be optimal. 

What happens when you have 7 exits or even more? There is no left/right
...

https://osmcha.mapbox.com/changesets/75857317

And the node can not help you identify the dimensions of the roundabout
which might be nice to show in the map.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Florian Lohoff
On Wed, Oct 23, 2019 at 12:00:13PM +0200, Tom Pfeifer wrote:
> On 23.10.2019 11:35, Florian Lohoff wrote:
> > > These are a very common feature, it does seem odd that routers are not 
> > > supporting them.
> > 
> > The point is that a mini roundabout does need a LOT of preprocessing to
> > put it into some graph for your classical A* or Dijkstra. You need to
> > eliminate the node and replace it with a circular road much like a
> > junction.
> 
> Could you explain what the preprocessing is needed for, and why you need to
> replace it in the routing algorithm.
> 
> From my perspective nothing is needed. The routing engine recognises from
> which way you come and where to leave, and, since the feature is so small
> and clear, it can give instructions like at a normal junction, just using
> the tag to describe the junction:
> "At the mini-roundabout [turn right|go straight|turn left]".

You would expect (as you see a roundabout sign) to get instructions to
take the n.th exit.

The roundabout change which triggered this mail is MUCH larger - And you
physically can go straight but there is a small curb - so cars will use 
the circular road, trailers will possible use the curbed center with the
last axles.

> Basically the mini-roundabout is effectively more about who has priority,
> and here all incoming roads have to 'give way'. Similar a four-side "stop"
> sign in the US. I have used them in Britain and they are often just a bucket
> of white paint poured in the middle of a junction.

A mini_roundabout has the same rules as normal roundabout from what i
look at the definition. The only difference is that its physically
traversable.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Florian Lohoff
On Wed, Oct 23, 2019 at 09:53:33AM +, marc marc wrote:
> Le 23.10.19 à 11:35, Florian Lohoff a écrit :
> > You need to eliminate the node and replace it with a circular road
> 
> a junction=roundabout is also allowed as a node
> https://taginfo.openstreetmap.org/tags/junction=roundabout
> so it's a bad rational to deprecate mini_roundabout

Thats the point - the node construct is IMHO unsupported in all Navi/Routers.

So i'd suggest to deprecate it and replace it with a highway=* +
junction=roundabout and if its a "mini roundebout" physically
you can driver over it (Thats IMHO the only difference) you add
an area=yes to the circular road.

It add:

- Knowledge over the physical dimensions (a node has a dimension of 0)
- Removes a special case everyone processing OSM data for routing chokes at.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Deprecating mini_roundabout

2019-10-23 Thread Florian Lohoff
On Wed, Oct 23, 2019 at 09:24:30AM +, Philip Barnes wrote:
> On Wednesday, 23 October 2019, Jez Nicholson wrote:
> > So, for those who like definitions: In the UK, a "mini roundabout" is
> > simply a small roundabout that is either flush to the road or slightly
> > raised so that large/long vehicles are able drive over it if they need to.
> > If it has anything on it, like a lamp post, it is a "roundabout". It is not
> > the size, it is the being able to drive over it that matters
> > https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/561491/mini-roundabouts-report.pdf
> >
> There is also the rule that you should not do U turns at mini roundabouts, so 
> it is important that mapping retains this important distinction.
> 
> These are a very common feature, it does seem odd that routers are not 
> supporting them.

The point is that a mini roundabout does need a LOT of preprocessing to
put it into some graph for your classical A* or Dijkstra. You need to
eliminate the node and replace it with a circular road much like a
junction.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] Deprecating mini_roundabout

2019-10-23 Thread Florian Lohoff

Hi,

i just saw a changeset of someone makeing a mini_roundabout
from a junction=roundabout. I have never used mini_roundabout
as non of the routing/nav engines i tried actually supported it
when i did.

Instead of making it some special type of roundabout with seperate
tagging i'd vote for deprecating the mini_roundabout and adding
a tag making the area of the junction=roundabout be an area which is 
driveable. e.g. why not area=yes on the junction=roundabout. 

That would add a lot of information - e.g. the size of the roundabout
etc - and it would eliminate another "special" case which is mostly
unsupported.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Divided highways, and not so divided highways, one way or two

2019-10-14 Thread Florian Lohoff
On Fri, Oct 11, 2019 at 01:43:41PM +0200, Mateusz Konieczny wrote:
> > Hi
> > On Thu, Oct 10, 2019 at 10:59:53PM +0200, Mateusz Konieczny wrote:
> >
> >> > I had a quick 10 Minute Look at Mapillary and i have found 10s of
> >> > examples of separate way although no physical barrier. 
> >> >
> >> It can be easily done for any kind of mistake.

But this is speculation. These are not simple small side roads,
these examples are large, primary traffic arteries and noone
is able or willing to fix it for a decade?

I wont fix them because i think they are perfect as they are.

Isnt that an acceptable way of thinking that there are more
mappers happy to map how they see fit? It happens everywhere.
As long as there something which is utterly broken by
the way we map why not be liberal and accept to not do it
exactly by the rules.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Divided highways, and not so divided highways, one way or two

2019-10-11 Thread Florian Lohoff
Hi

On Thu, Oct 10, 2019 at 10:59:53PM +0200, Mateusz Konieczny wrote:
> > I had a quick 10 Minute Look at Mapillary and i have found 10s of
> > examples of separate way although no physical barrier. 
> >
> It can be easily done for any kind of mistake.
> 
> Have you tried comparing it to split way tagging?
> 
> It may be a good argument is that tagging
> is appearing often. Just because it is appearing at 
> all is not very interesting, we know this.

I would call them mistaked. By intuition i would map
these areas exactly as they are right now.

And these stuff is not some ice road at the north pole. These
are streets which have been touched by 1000s of mappers and
you call all of them beeing inexperienced noobs making mistakes?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Divided highways, and not so divided highways, one way or two

2019-10-10 Thread Florian Lohoff
On Thu, Oct 10, 2019 at 07:53:39PM +0200, Markus wrote:
> 
> That's not true. There's another way to tell routers that it is
> illegal to change lanes: by adding that information to the highway=*
> way. There's already a tag for this: change:langes [1] (> 90 000
> uses).
> 
> While mapping separate ways where there is no physical barrier works
> for car routing, it breaks pedestrian routing and there's likely no
> way to fix this. Pedestrians usually are allowed to cross a painted
> line that cars aren't allowed to cross (at least in Europe).
> Therefore, if the road in your example is mapped with two separate
> ways, a routing engine would make pedestrians do a detour (possibly a
> long detour), even though they could just cross the street.
> 
> [1]: https://wiki.openstreetmap.org/wiki/Proposed_features/change

The road in question here (where is originated) is foot=no.
So no pedestrians.

And IMHO change:lanes describes whether changing to a different lane
going the SAME direction is legal.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] Must/Should and Lawyering - Re: Divided highways, and not so divided highways, one way or two

2019-10-10 Thread Florian Lohoff
On Thu, Oct 10, 2019 at 02:28:51PM +0200, Mateusz Konieczny wrote:
> 
> 10 Oct 2019, 10:44 by f...@zz.de:
> > And i see fit in the original "Conventions" document [1] which terms
> > it as "Divided highways should be drawn as separate ways." for divided 
> > highways.
> > First - "should" is a relaxed term which is no MUST and second - 
> > it does not make any statement about
> >
> OSM Wiki is not following RFC 2119.

RFC2119 is just formalising and explaining English for
non native speakers in this respect.
 
> Generally accepted rules are usually
> stated as "should" and similar.

"Generally accepted" is correctly mapped to "should".

But there are others which are really a must:

https://wiki.openstreetmap.org/wiki/Node
"Where ways intersect at the same altitude, the two ways must share a
node (for example, a road junction)"

https://wiki.openstreetmap.org/wiki/Key:maxweight
"You must explicitly specify the unit if it is not in metric tonnes."

So the English language is used appropriate in the Wiki.

> And in case of lawyering - the same page
> is (from what I see) not forbidding
> other mappers to revert to single way 
> version.

It does not even talk about non divided ways beeing mapped as seperated
ways. So if lawyering correctly this whole discussion is moot because i
dont think there is a place in wiki talking about ways without a divide
to be mapped as 2 ways.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Divided highways, and not so divided highways, one way or two

2019-10-10 Thread Florian Lohoff
On Thu, Oct 10, 2019 at 08:38:28AM +0200, Frederik Ramm wrote:
> Hi,
> 
> DWG has been asked to mediate in a user dispute in Germany where a local
> mapper has chosen to represent a busy four-lane primary highway (two
> lanes in each direction, and a double continuous line painted in the
> middle which is physically possible but legally not allowed to cross).
> 
> Other mappers object to this saying that it violates the rule that there
> must be some sort of physical division to allow that form of mapping.

I had a quick 10 Minute Look at Mapillary and i have found 10s of
examples of separate way although no physical barrier. 

I guess this proves that people follow this way of mapping when they
see fit:



Hochstraße - Kamen:
https://www.mapillary.com/map/im/nPGchWcPI-HhCVYM833SlA

Emil-Zimmerman-Allee - Buer
https://www.mapillary.com/map/im/2Y-I_7hwiM3slXyTgqTwoQ

Horster Straße - Gladbeck
https://www.mapillary.com/map/im/_2HTDw3EEs8vKNR8KGKlTA

Kaiser-Wilhelm-Straße - Essen
https://www.mapillary.com/map/im/PAjeQdRW3t6BmQEMsXHZfQ

Friedrich-Ebert-Straße - Essen
https://www.mapillary.com/map/im/a0J5HGAJI1GVVuP5sG7M3Q

Boulevard Pinel - Lyon
https://www.mapillary.com/map/im/71ALZI8c9agMDxtL0z3nuA

Staropolska - Gdansk
https://www.mapillary.com/map/im/p3wF7yrx634ow6fcd6oyPg

Kärtner Straße - Graz
https://www.mapillary.com/map/im/qApIUsfERpNItMIcsspZdA

Heidelberg - Ernst-Walz-Brücke
https://www.mapillary.com/map/im/IffdeSsK58iFdjU-5_QBCA

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Divided highways, and not so divided highways, one way or two

2019-10-10 Thread Florian Lohoff
On Thu, Oct 10, 2019 at 08:38:28AM +0200, Frederik Ramm wrote:
> Hi,
> 
> DWG has been asked to mediate in a user dispute in Germany where a local
> mapper has chosen to represent a busy four-lane primary highway (two
> lanes in each direction, and a double continuous line painted in the
> middle which is physically possible but legally not allowed to cross).

I am one of those mappers - So disclaimer applies - i am tainted.

I am in favour of relaxing this rule. We currently have strips of
road where we currently handle this relaxed e.g. Motorway links or
exits where we (OSM Germany) map ~50% of the exits with completely
seperate ways although there is only a single line in the middle.

I'd like to use it for a 4 lane motorway size like road where is only
a double line in the middle. Double line means, not allowed to cross,
and additionally - no part of a vehicle may leap over the line. So 
in practice left turns are not allowed, u-turn is not allowed. And for
this specific strip foot and bicycle are disallowed and we had no speed
limit for years (Was introduced couple years back).

Rational:

Mapping large, multi-lane roads with a "do not cross line" in the
middle as single line requires 4-5 times the number of turn
restrictions. These are number i am estimating from my own experience
mapping it one or the other way.
At every way junction one has to model every disallowed way/turn.
From my experience this is very error prone.

I am doing a lot of QA concerning routing (100K routes every 2 hours for
the region i am mostly interested in). From the experience doing this
the last 6 years it shows that meanwhile handling of turn restrictions is 
causing 90% of routing problems due to people unintentional breaking,
abusing, misinterpreting or overcomplicating turn restrictions.

So - in other words. I am in favour of the KISS principle. Make
it easy for the average mapper and let them handle as they seem
fit. As a rule of thumb the current handling is okay. But there
is no "one size fits all". And I'd like to relax the rules 
in favour of reduced complexity.

And i see fit in the original "Conventions" document [1] which terms
it as "Divided highways should be drawn as separate ways." for divided highways.
First - "should" is a relaxed term which is no MUST and second - 
it does not make any statement about whether we MUST draw a non physically
divided highway as one line. (I dont oppose the fact that in 99% of the
cases it makes absolute sense to do so).

Flo
[1]: https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] New tag proposal: 'addr=milestone'

2019-10-01 Thread Florian Lohoff
Hi Jorge,

On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote:
> Throughout the entire Latin American region and some other parts of
> the world, it is quite common to find the kilometer (Km.) information,
> as may be found on the “highway:milestone”, as part of the actual
> addresses. Mostly used in suburban and rural areas, which may usually
> not even have any visible references or even house numbers, the use of
> the milestone is widely utilized to find an address in these regions. 

We have such addresses in Germany too. They are pretty rare though.
sometimes really rural mobile masts or copper distribution
street cabinets and stuff carry addresses like this.

As they are rare they are either not at all in public records or
with manipulating the km marker into the Housenumber. Typically
addresses in Germany are only granted for lots and houses and
telecoms infrastructure is often in public space so no addresses.

I have seen addresses in Telecoms records like "An der Bundesstraße,
Km 4,4".
 
> The highway milestone information may also be found in addresses
> within urban areas, even with the existence of house numbers, as these
> numbers frequently repeat themselves and the only difference between
> them is the exact location on a specific highway - based on and easily
> identified with these milestones.
> 
> We want to create a tag to enter this commonly-used data in a logical
> way and therefore propose that it be “addr:milestone=* / (* - Km.
> ##)”, which does seem to meet the criteria and can be easily
> interpreted and used accordingly by any editor.

So you propose to put the address on the Milestone or on the housing
which uses this Address?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Barrier defaults

2019-09-26 Thread Florian Lohoff
On Thu, Sep 26, 2019 at 10:35:45AM +0200, Martin Koppenhoefer wrote:
> explicit access tagging for barriers is generally preferable because
> it reduces the uncertainty.
> 
> Still if there is a barrier and no access tags are set you will have
> to figure out how to deal with it. 
> 
> For bollards I agree it is likely that pedestrians can pass. For other
> barriers like gates or even ropes/chains, it will not be possible
> without access tags to understand when you can pass, even as a
> pedestrian.

I dont like rules with too many exceptions - thats the point. I agree
that bollards are a little obvious as a pedestrian will most likely 
be able to pass.

But for the sake of simplicity i would rather call for only
explicit tagging so people can process barriers whatever they are
called - No if/then/else/otherwise/maybe spaghetti in all data
consumers.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] Barrier defaults

2019-09-26 Thread Florian Lohoff

Hi,
i stumbled upon a statement in

https://wiki.openstreetmap.org/wiki/DE:Key:barrier

that barrier=bollard has implicit foot=yes bicycle=yes on it. I have
been mapping only explicit restrictions for 10 years and the English
page (where the German should be a translation from) does not
mention this specifically.

https://wiki.openstreetmap.org/wiki/Key:barrier

The Page

https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard

mentions this though.

I was under the impression that data consumers may ignore the
value for the barrier key as the access restrictions will alway
be explicit. 

Now i discovery the contrary. Every data consumer has to make
a long list of every barrier possible and the default settings.

Does that make sense?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Mon, Aug 05, 2019 at 12:30:48AM +0100, Paul Allen wrote:
> On Mon, 5 Aug 2019 at 00:12, Martin Koppenhoefer 
> wrote:

> I just reverted it.  And added some clarification (some may disagree and
> think I've murkified it)
> based on why I think those words were removed back in February.  Feel free
> to fix my fixes.

Your statement added:

"but which are not normally used as through routes (which would usually 
be
classified highways or unclassified highways)."

I disagree on this. I dont think we have consensus that residential
are not for through traffic. Our routers/navigators dont treat it like
that. And if we assume so there is a HUGE difference in unclassified and
residential we dont actually yet have.

And its not the claim which has been removed in February.

"but which are not a classified or unclassified highways."

This is a statement which unclassified carries aswell:

In short, when other highway=* tags are more applicable, use those
instead. If a public road is of lesser importance than what's called a
highway=tertiary in your region, and is also not a highway=residential, 
a
highway=service, or a highway=track, then it's probably an unclassified 
road."  

So the statement removed in February  is a "NOOP" statement. Saying

"you cant be A if you are B"

Now you changed it to something completely different with additional claims.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 07:55:16PM +0100, ael wrote:
> On Sun, Aug 04, 2019 at 04:23:03PM +0200, Martin Koppenhoefer wrote:
> > sent from a phone
> > > On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> > > A residential is also an unclassified road.
> > 
> > IMHO it is not, as an unclassified road is part of the interconnection 
> > grid, while a residential road is not 
> 
> My reply was going to be much the same. Unclassified roads are generally
> for "through traffic". Residential raods are primarily for access to
> those buildings, and would not (normally) be used for travel to other
> destinations.

No statement in the Wiki backs up this claim. This is what i say.

No statement about through traffic. Residentials are for through
traffic aswell although their primary purpose may be access to the
residential area.

This is what our algorithmic brothers in routing/navigation do. Treating
unclassified and residential the same.

And we cant distinguish these 2 by hard facts. Its more or less "felt
traffic pattern" or "believe" or "experience" how you tag.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 04:21:14PM +0200, Martin Koppenhoefer wrote:
> I don’t think this is a valid conclusion:
> 
> - we are not restricting our tagging to official denominations but
> give precedence to on the ground usage

Correct - But from my experience its either a service or it has
a name. At least in the part of Germany where i map.

There are of course the 1% of exceptions where Bayer or BASF names roads
on their facility property. But the typical parking aisle or
access to a fuel station should not carry a name.

And naming driveways as the roads they originate from is broken. The
driveway itself does not have a name.

For me this is also a matter of housekeeping the search index in
nominatim. If i search for Bahnhofstraße is typically dont want
to find 100's of Driveways named Bahnhofstraße.
 
> - the service class is further divided into many different classes
> like driveways, alleys, parking aisles, drive through ways, minor
> generic access roads, etc., some may have names, many will usually not
> carry a name.

Which of those do carry names typically? I cant see any? And its just
my mapper experience in the wider area i map that we typically dont have
names. And if they are named its a bug in 97% of the cases.

And in the QA i do i do not flag 100% issues - but objects you might
want to take a look at because they are fishy. And typically its not
just that one object but some blocks which have been mapped with strange
assumptions.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 04:30:54PM +0200, Martin Koppenhoefer wrote:
> sent from a phone
> > On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> > 
> > Their difference is usage. In case of residential its usage is
> > predominantly access to an residential area, whereas the unclassified is
> > for interconnecting residential areas (be it villages).
> 
> for me the access to a residential area is not a residential road, it
> is at least an unclassified road or typically a tertiary road.
> Residential roads are the roads inside the residential area, which are
> not used by through traffic 

Where do you take this assumption from? I have never heard before that
residential may not be used for through traffic?

The opposite is described in highway=residential:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dresidential

This tag is used for roads accessing or around residential areas.

This is a useful guideline if you are not sure whether to use
residential or unclassified for streets in towns:

residential – street or road generally used for local traffic within
settlement.
unclassified – Unclassified roads typically form the lowest form of
the interconnecting grid network (below highway=tertiary 
roads). Roads
serving for interconnection of small settlements. Use 
residential rather
than unclassified on the road section if there are traffic 
restrictions
(such as slower speed limits) or traffic calming features near 
small
settlements. (See also highway=unclassified.)

So in case of residential usage, reduced speed limit (city boundary?) or
traffic calming one should rather use residential than unclassified.

I agree that living_street is not for through traffic - thats even in
German legalese.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 11:20:49AM +0100, ael wrote:
> > For me unclassified is the same as residential. The difference is that
> > unclassified is for interconnecting residential areas, and residential
> > has residential traffic. So for me there cant be an unclassified within
> > city boundaries, and as soon as there is predominent residential it
> > cant be a unclassified.
> 
> How have you come to that conclusion? It flatly contradicts the normal
> meaning. Perhaps your local area uses the term "unclassified" in a way
> different from the OSM convention?

A residential is also an unclassified road. It does not have
a classification as a tertiary or primary. So the difference
between an unclassified and a residential is not by their
classification (or lack thereof).

Their difference is usage. In case of residential its usage is
predominantly access to an residential area, whereas the unclassified is
for interconnecting residential areas (be it villages).

This is the exact terminology from:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified

"The tag highway=unclassified is used for minor public roads
typically at the lowest level of the interconnecting grid network.
Unclassified roads have lower importance in the road network than
tertiary roads, and are not residential streets or agricultural tracks.
highway=unclassified should be used for roads used for local traffic,
and for roads used to connect other towns, villages or hamlets.
Unclassified roads are considered usable by motor cars. Public
roads of low importance within town and cities that are not residential
may also be highway=unclassified."

So the difference is purely on the usage for residential traffic.

My assumption is that within city boundarys ALL roads carry mostly
residential traffic. One could argue that some roads are carrying
more through traffic than others but where do you draw that line and
do you count traffic when mapping? Its something we as OSM can 
not observe on the ground. Its a statistical matter.

Another indicator for me that neither unclassified nor residential
are of higher priority is the handling in for example OSRM. It
treats both equally in the assumption for travel speed etc.

This is why i make the shortcut in using residential within city
boundarys, and unclassified outside of city boundaries where there
is no residential usage - because everything else is highly disputable
and only provable with traffic analysis and statistics.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 01:18:13PM +0300, Tomas Straupis wrote:
> 2019-08-04, sk, 12:59 Florian Lohoff rašė:
> > If B is a public road A cant be private property and thus not be
> > a service. If B is a track A can be a service because both
> > of them share the concept of not beeing for the general public.
> >
> > Or vice versa. If you make A a service B cant be a public road.
> 
>   And therefore *track is higher* in the hierarchy than service. Right?

IMHO no - You have a hierarchy of public roads - from
residential/unclassified to motorway. service and track are not
in this hierarchy - they stand outside and carry various restrictions
depending on local regulation and have different purposes.

So a road which is for the general public like a
residential/unclassified must not be only reachable via a track/service.
This would be a breakage in hierarchy. The public road network is always
interconnected and should not build islands which cant be reached by
only using track or service roads. For most of the routers and modes of
transportation these would be hard islands. Same issue arises of
overbroad usage of access=* tagging.

This is why i have multiple QA tasks under these assumptions and German
legalese ...

- A public road may not carry a access=*
  The German legalese does not have a sign which completely forbids
  usage. The most restrictive sign still allows going by foot. 
  So the most restrictive access restriction could be vehicle=no
  (Except for construction - so i exclude highway=construction here)
- A public road may not carry any *=private
  If a public road is restricted to private its not a public road.
  Most likely this is a mistagging of the highway type
- A service road may not carry a name (Because in Germany only public
  roads get denominated a name). So either it has a name or its  
  a service.
- The nearest road to an address should not be a track.
  If the address is for living, the nearest road can not be a track
  as usage for living outweights agricultural usage by orders of
  magnitude. Or better - i search for the nearest legally usable
  road and have a cutoff for errors at arbitrarily chosen ~75meters. 
  Most of the errors i find are long driveways which carry arbitrary
  access tags, or farmyards which are only reachable via tracks.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 12:25:49PM +0200, Colin Smale wrote:
> On 2019-08-04 11:57, Florian Lohoff wrote:
> 
> > This is why i get to the point "is it a public road" and "a public
> > road cant be service". If we agree on this you can as some zoom scale
> > drop service and track.
> 
> What definition of "public" and "private" are you using here? This is
> another can of worms. 

There is an official road hierarchy where all our roads fit in. These
are for public usage and typically carry an implicit access=yes.

service and track do not belong into this hierarchy. They carry
implicit restrictions which vary from country to country or even
county to county.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 12:46:05PM +0300, Tomas Straupis wrote:
> Now I would like to skip road C at small scale, but leave A, because I
> want to leave B.
> 
> Can we agree on some scheme to tag this (do data augmentation), so
> that less people doing cartography stuff have to resort to heavy
> generalisation operation such as road pruning?

When you honestly look at roads something like a correct hierarchy
always ressembles.

This is why i get to the point "is it a public road" and "a public
road cant be service". If we agree on this you can as some zoom scale
drop service and track.

Because a public road does not branch of a private road. There is
your hierarchy.

So getting back to your example:

R
R
RAAA
R  A
R
R
R
R

If B is a public road A cant be private property and thus not be
a service. If B is a track A can be a service because both
of them share the concept of not beeing for the general public.

Or vice versa. If you make A a service B cant be a public road.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 12:19:52PM +0300, Tomas Straupis wrote:
> Let's say we have a residential road R. Going out of this residential road
> there is a way A into the neighbouring residential area (say 50m length).
> Out of that way A there is anower way B leading into the fields/forest
> which lies outside of the residential area. B way is long enough and
> significant, say leading to some locally significant object (ruins, tree,
> lake).
> 
> R
> R
> RAAA
> R  A
> R

> What could be correct:
> a) A - service (service=???), B - track (tracktype=???)
> b) A - track grade1 B - track grade>1
> c) others

Is A a public named road? Make is residential. Is it a driveway
just for a single home? Make it service.

Is B predominantly for agricultural purposes? Make it track. Are
there more visitors to the ruins and its a public road? Make
it unclassified. Otherwise people cant navigate their POI.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 11:55:08AM +0300, Erkin Alp Güney wrote:
> Paved: service unpaved:track

So half of the highways in African countries are tracks?

IIRC osm does tag highway class by usage not by construction or
physical attributes.

So there is a perfect possibility that large stretches of primary roads
in Madagascar should carry a surface=dirt - So yes - highway=primary
surface=dirt is a pretty likely combination.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
Hi,

On Sun, Aug 04, 2019 at 11:46:26AM +0300, Tomas Straupis wrote:
> 2019-08-04, sk, 11:32 Florian Lohoff rašė:
> > For me unclassified is the same as residential. <...>
> 
>   Ok, so unclassified vs residential is regionally defined, as I wrote.
> 
>   But what about service/track?

Same dispute. I am one of the track opponents for years. I live in
the outback myself and i try to stop people tagging every road beyond
city limits as track.

A track is predominently for agricultural use. As soon as there
are people living there are predominently other uses than agricultural.

So the driveway to a farmyard can not be a track. 

I once made the claim its not a track if:

- The postal service uses it or
- The garbage truck uses it or
- The school bus uses it

And all of that is true if people are living there. The problem is
that tracks are not even considered in most routing/navigational
software so a lot of my neighbours would not be reachable if tagging
outback roads as track would hold up. 

So track is when there are no buildings or only a field barn.


Service is for me another complicated beast. For me a public road
can not be a service. unclassified is defined as the lowest
class of public roads. Service is defined as roads on industrial areas
etc.

So for Germany it cant be a service if:

- its of public use or
- it has a name (Only public roads get demoniated a name)

So i only tag roads on parking, driveway or industrial complexes
etc as service. I consider service roads beeing treated as
"access" destination and not for public use.

This is the reason why i dont think tagging every driveway as
access=private is a good thing to do. That causes all navigational
software to exclude these road snippets completely from their index. Now
you have private driveways up to multiple kilometers. When you now
navigate to an address you get told "You have reached your destination"
while beeing on the main road some multiple kilometers away not even
in visible contact to the building or the driveway. You might
even be on the wrong main road as mapping of addresses to the point
on the road network to navigate to is a minimum distance decision.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Road hierarchy

2019-08-04 Thread Florian Lohoff
On Sun, Aug 04, 2019 at 09:35:41AM +0300, Tomas Straupis wrote:
> Hello
> 
>   Road hierarchy is needed for a number of things:
>   * deciding which classes of roads to display on different scales in a map
>   * performing road network validation
>   * other tasks (f.e. typification of buildings - orientation)
> 
>   Hierarchy would be different in different context: motorcar, bicycle,
> pedestrian etc. For the time being I'm only asking about motorcars.
> 
>   There is non written (or I could not find in wiki) or "de facto"
> hierarchy:
>   * motorway
>   * trunk
>   * primary
>   * secondary
>   * tertiary
>   * unclassified
>   * residential
>   * living_street
>   In some regions unclassified has a higher position in hierarchy, in other
> regions unclassified, residential and living_street have the same position.
> This is fine for the time being.
>   I'm also intentionally skipping _link classes.

For me unclassified is the same as residential. The difference is that
unclassified is for interconnecting residential areas, and residential
has residential traffic. So for me there cant be an unclassified within
city boundaries, and as soon as there is predominent residential it
cant be a unclassified.

So my guideline was:

Unclassified
- Public road
- Not classified
- Outside of city Boundary
- No predominant housing

Residential
- Public road
- Not classified
- Housing


This has been a constant argument on different mailinglist for multiple
years. Defacto handle routing engines those two identical so retagging
a residential to unclassified does not make them "quicker" in terms
of routability.

So - YMMV - And its easy to start another argument here ;)

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] leisure=garden for private front/back gardens

2019-07-13 Thread Florian Lohoff
On Sat, Jul 13, 2019 at 10:17:18AM +1000, Warin wrote:
> Some private gardens that front the street are publicly visible, I see
> no reason not to map them.
> 
> The 'usability' in this instance is visible and, sometimes,scents.

The same reason i do not map my kitchen sink as a
natural=water/water=pond

Its not for the public leisure.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] leisure=garden for private front/back gardens

2019-07-12 Thread Florian Lohoff
On Fri, Jul 12, 2019 at 07:23:01AM +0200, Pee Wee wrote:
> Hi all

> I would like your opinion on the next issue.

> meaning on may 3, 2010 when someone added a description of “Garden” from
> the Wikipedia garden description that refers to private gardens. In order
> to differentiate from the publicly accessible gardens (with or without fee)
> sometime additional tags like “access=private”  and
> “garden:type=residential” are added. To me this seems better then no
> additional tags at all but in fact I think private gardens (not accessible)
> should not be tagged with the leisure key. On the talk page I saw that
> there are more objections

For me a leisure=* in OSM has some public usability assumption. Mapping
every little green strip as a leisure=garden i would consider a tagging
abuse.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

2019-06-25 Thread Florian Lohoff

Hi Ulrich,

On Tue, Jun 25, 2019 at 10:16:18AM +0200, Ulrich Lamm wrote:
> This way, my mapping of courses of water including the culvert
> sections does not violate the principles of OSM.  And the ban is
> totally injust. 

It violates the rights of the origin copyright holder. CC-BY-SA and
others are not compatible with ODbL and thus we CAN NOT and MUST NOT
take data from other sources which are not explicitly allowed. If we
would allow this, and republishing data under ODbL (as OSM does with
planet dumps) Openstreetmap commits a breach of Copyright. Thus it is
absolutely vital for OSM to prevent people from adding incompatible, non
ODbL Data to the Database.

You have been told to not take data from other sources which are not
ODbL multiple times and you havent stopped.

Now Frederik (with my full support) stopped this repeated copyright
violation by blocking/banning you.

BTW - You signed these obligations with creating an OSM Account
and opting in the Contributor Terms.

https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms

1. We respect the intellectual property rights of others and we need to
be able to respond to any objections by intellectual property owners. 
This
means that:

(a) Your contribution of data should not infringe the intellectual 
property
rights of anyone else. If you contribute Contents, You are indicating 
that, as
far as You know, You have the right to authorize OSMF to use and 
distribute
those Contents under our current licence terms. If You do not have that 
right,
You risk having Your contribution deleted (see below). 

You have multiple times been told that you do NOT have the right to redistribute
this data under the current license (ODbL).

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

2019-06-03 Thread Florian Lohoff
On Mon, Jun 03, 2019 at 11:11:50AM +0200, Peter Elderson wrote:
> LS
> I agree that email is not the best tool for discussions. The main thing for
> me is that the world of email is no longer limited to one mailer. It is not
> possible to make them all thread and separate and quote exactly as I would
> like. Basically, it's just a list of mails without any logical order.

That is definitly a client problem. I am reading mails by thread and
can ignore threads, mark complete threads as read and i exactly see
who is responding to whom.

With the tree i see i can even detect the most controversal or
responded messages without opening them.

> The OSM forum is not the best forum you could imagine, but it works much
> better for keeping track of discussions and outcomes, including threading,
> limited quoting, searching, back-reading, and starting spin-off subjects.
> And it works on all devices, without having to tame all of them separately
> (which I am not even allowed to do on many of them). Moderating a forum is
> also much easier.
> 
> So I would be very much in favour of moving to the forum.

I will definitly not follow to the forum. Its a pull media so i need to
explicitly point and click to follow issues.

Mail communication can be much more complex and may fade to different
subthreads. Large threads form into a tree and not some linear easy
thing. Thats a problem of a newer generation not having read
stuff like the Netiquette RFC1855 - Change the subject if your dicussion
fades.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Constructive communication medium (was:Filter bubbles in OSM)

2019-05-25 Thread Florian Lohoff
On Sat, May 25, 2019 at 02:28:45AM +0200, Tobias Zwick wrote:
> 
> 1. Thesis: Mailing lists (and to a lesser degree, classical forums) promote a 
> culture of dissent.

I strongly disagree here. How can a technical form of communication
make a "culture of dissent"?

Can you elaborate why you think Mail as a form of communication
is different in making a compromise possible than IRC, Slack
or a Forum?

From a sociological point i would assume that people on the mailinglist
are by average 10 Years older than people on Slack or the Forum. Thats
just a matter of history of technology.

So in the end its not "Mailing lists" but age which make you believe
you have a culture of dissent? 

Flo

PS: I will not participate in a Forum. It turns the responsibilities
for around. You suddenly have the obligation to POLL on threads.
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Filter bubbles in OSM

2019-05-24 Thread Florian Lohoff
On Fri, May 24, 2019 at 11:42:18AM -0700, Nick Bolten wrote:
> I'd like that to be the case. What is the plan for making this an inclusive
> community that doesn't devolve into negative, personal accusations so
> easily? It hasn't happened on its own.

I havent seen personal harassment so far and other projects i am
involved in got much less attractive when given a "code of conduct".

Often the CoC this is abused turning people away beeing loud or
direct in their tone. CoC by itself is neither a guarantee nor
a method to create an inclusive community. Its just a matter of
defining whom to exclude not if.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] solving iD conflict (was: pointlessly inflamatory title)

2019-05-24 Thread Florian Lohoff

Hola Nick,

On Thu, May 23, 2019 at 03:59:17PM -0700, Nick Bolten wrote:
> So far as I can tell, the topic on this mailing list (as it often is) is to
> gripe about how the iD editor isn't listening to this mailing list (and

You can broaden that up - All tools around OSM. Same applies hier to all
editors and at least QA tools. As soon as you point your finger to
something "This is broken - please fix" you interpret OSM data which
is likely just a personal or partial view.

I am running a lot of QA stuff and a lot of that is only my personal
opinion and i am getting beaten with a stick about those things aswell.

The more people use your tools the broader your consensus must be in
interpreting data.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff
On Wed, May 22, 2019 at 01:01:20PM +0200, Mateusz Konieczny wrote:
> 
> 22 May 2019, 12:49 by f...@zz.de:
> 
> > On Wed, May 22, 2019 at 12:37:21PM +0200, Mateusz Konieczny wrote:
> >
> >> > Again a footway between the house and a road will NOT help for
> >> > car navigation because for cars a footway is NOT a routable 
> >> > part of the graph.
> >> >
> >> Car navigation may use footway data to select best dropoff point.
> >>
> >> In exactly the same way as you proposed with navaid relation,
> >> but without adding subjective data.
> >>
> >
> > Look at my school example - would still be broken. Yes - there is a
> > footway - but not the original parking lot for the school.
> >
> > Different street. ~1km detour. No parking at the selected spot - Private
> > property.
> >
> > You are trying to fix an algorithm with new assumptions which break in
> > other aspects. You need to have a way to EXPLICITLY define a location
> > where to navigate to. 
> >
> I noticed no link to that case, but here routers should direct car to mapped
> parking within school area (it is a public parking, right?).

Search for it - When i add a link i add a specific location - I did this
intentionally - Because with the search you map object -> specific
location and then you can query OSRM again for routing.

It is the official parking lot for the school. Its vis a vis to the 
entrance.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff
On Wed, May 22, 2019 at 12:55:44PM +0200, Mateusz Konieczny wrote:
> > - Baumstraße 43a, Gütersloh, Germany
> >  It does not have a connection to Baumstraße but to
> >  Hermann-Vogelsang-Straße.
> >
> >  It still will be routed through Baumstraße and the driveway to
> >  Baumstraße 45a
> >
> >  IMHO unfixable without bending geometry 
> >
> https://www.openstreetmap.org/way/273023376 
> <https://www.openstreetmap.org/way/273023376> has no mapped entrance, 
> footway access, driveway. Fences are also unmapped.

Footway -> not for car 
fences -> not in graph for navigation - not connected to graph-> purely
cosmetic object.

43a has no footway/driveway. The carport is directly at the side of the
road.

> I am not sure whatever we have smart routers, but here even human would fail
> due to lack of data.
> 
> I added driveway based on aerial image but it is unlikely to be enough.

Where is it ? 43a does not have a driveway.

> > - Dalbker Straße 40a, Oerlinghausen, Germany 
> >  Dalbker Straße 44a, Oerlinghausen, Germany 
> >
> Fences/hedges/whatever barrier is there is missing though
> really smart router (that is using footway at start and the end)
> would work correctly here.
> 
> Have you checked whatever this improvement is suggested for routers with 
> public
> bug trackers?

Okay - first you tell me - its solvable - then you tell me data is
missing, now you tell me the software is broken.

And there is a footway - its directly in front of the door. Still - you
will get routed to a differen street. The footway is NOT in the graph
for cars. 

All objects you put into this argument do not have any influence on any
routing app/software mentioned in this thread before.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff

Hi

On Wed, May 22, 2019 at 12:42:45PM +0200, Mateusz Konieczny wrote:
> 22 May 2019, 09:53 by f...@zz.de:
> > Hi Marc,
> > On Tue, May 21, 2019 at 10:38:23PM +, marc marc wrote:
> >> > What is the expectation to get navigated to when selecting a park?
> >> there is no such thing as "a single point that makes everyone agree"
> > Yes there is - there has to be an explicit location you will ne navigated
> > to for a certain feature. 
> >
> This is blatantly untrue. Depending on location you will prefer to be routed
> to different entrances and it is not considering different modes of transport.

How can i select the entrance on OSRM/openstreetmap website, MAPS.ME,
OsmAND the entrance? You cant. 

And where is an entrance to a Golf Course? And when navigating by car to
a mall i dont want the entrance - i want the Car park. Can i select
that from a drop down when selecting a Mall to navigate to?

Mapping OSM Objects to navigational locations is implicit right now and
depends on the algorithm used to find the nearest location on the
routable network for the specified mode of transportation. So i bet
i can generate a situation where OSMAnd, OSRM and MAPS.ME will bring
you to different spots more than 5km apart. Its just a matter of
constructing the right geometries with the tags one or the other
navigational preprocessing takes into account. You cant specify
the right location explicitly - so you need to rely on implicit geometry
processing by algorithms. And then you still have 2-3% of broken
destinations.

> > Nope - there isnt enough information. Its all just implicit and works
> > for 95% of the cases. It breaks horrible in others and we fake
> > geometries to fix it, blame the application, invent tags to guide the
> > nav/routing which only fit half of the object and only half of the
> > apps support. In all cases the user is in trouble.
> >
> Please give a specific example.

See my School example. Its a pretty nice fuck up. You get "near" the
School but in a oneway maze 1km away from the parking lot. And yes -
there is a footway. Everything is mapped as it is. Still - breaks.

https://lists.openstreetmap.org/pipermail/tagging/2019-May/045416.html
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045423.html

And dont troll me with "add a footway" - A footway is not in the
routable graph for cars and will not even be in the database when
looking for the nearest point.

> If navigation is simply doing nearest road point on matching then it requires 
> change to both
> - properly use footway data
> - use your proposed relation

footway != car

And it wont solve the issue. See the school example. There is a footway
and it will prefer the location it does not most likely. Still broken.

nearest road point will only be on roads for THAT mode of
transportation.

> I see no reason for preferring second solution.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff
On Wed, May 22, 2019 at 12:37:21PM +0200, Mateusz Konieczny wrote:
> > Again a footway between the house and a road will NOT help for
> > car navigation because for cars a footway is NOT a routable 
> > part of the graph.
> >
> Car navigation may use footway data to select best dropoff point.
> 
> In exactly the same way as you proposed with navaid relation,
> but without adding subjective data.

Look at my school example - would still be broken. Yes - there is a
footway - but not the original parking lot for the school.

Different street. ~1km detour. No parking at the selected spot - Private
property.

You are trying to fix an algorithm with new assumptions which break in
other aspects. You need to have a way to EXPLICITLY define a location
where to navigate to. 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff
On Wed, May 22, 2019 at 09:13:14AM +, marc marc wrote:
> Le 22.05.19 à 09:43, Florian Lohoff a écrit :
> >> Can you give example of residential building with fully mapped roads, 
> >> footways and obstacles where well written router will fail?
> > 
> > - Baumstraße 43a, Gütersloh, Germany
> 
> you mean https://www.openstreetmap.org/way/273023376 ?
> it's a good example of missing datas.
> no entrance, no way between the entrance and the public network.
> please, there should be an example of a target where the current schema 
> are not enough, and not an example where the lack of data produce
> a bad routing
> 
> right now I feel that the relation type=navaids should be called 
> type=missingway

Again a footway between the house and a road will NOT help for
car navigation because for cars a footway is NOT a routable 
part of the graph.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff
Hi Peter,

On Wed, May 22, 2019 at 10:15:57AM +0200, Peter Elderson wrote:
> >  Id imaging a relation which says
> > object A -> car -> Node B (on routable graph)
> > So whenever i tell my nav software to bring me to object A the node
> > selected on the routable graph as a destination will be Node B.
> 
> One relation per mode of transport then? So a complex obejct a could have
> many navaid relations? Or one relation containing all nodes, with roles for
> transport mode?

type navaid
name Foobar (Optional if object does not carry a name or you map
 multiple different location)
source  (Multiple ones sharing the same transport destination)
car
bicyle 
foot   

Just as the rough first version. You want to keep this to a minimum for
cases where an algorithm cant choose the right solution or is making
wrong decisions based on correct geometries.

A mall with parking south and north would get 2 navaid relations

name "Mall foo - North"
name "Mall foo - South"

With their parking lot entries as the nodes to go to by car
and their entrance for foot. Currently you might be lucky
that your Nav Software does a full text search and somebody
named the parking lots with the complete name although
they should only carry a ref=North/South.

So a navigation preprocessor would not try to find a node on the
routable network by algorithm but by hinting in case it finds
this relation.

It currently works by accident and because people tweak
the data to get their result. Either geometries, additional tags
or additional name tags on unrelated objects. 

People start mapping for the router/nav software. A relation like this
could help solve the need of hinting the software without abusing
other tags, tag move, geometry tweaking.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff
On Wed, May 22, 2019 at 09:43:31AM +0200, Florian Lohoff wrote:
> > Can you give example of residential building with fully mapped roads, 
> > footways
> > and obstacles where well written router will fail?
> 
> - Baumstraße 43a, Gütersloh, Germany
>   It does not have a connection to Baumstraße but to
>   Hermann-Vogelsang-Straße.
> 
>   It still will be routed through Baumstraße and the driveway to
>   Baumstraße 45a
> 
>   IMHO unfixable without bending geometry 
> 
> - Dalbker Straße 40a, Oerlinghausen, Germany 
>   Dalbker Straße 44a, Oerlinghausen, Germany 
>   Both fixed by moving the Address to a node, moving it further to
>   Dalkbker Straße within the outline of the Building.
> 
>   Otherwise you'd be routed to Buchweizenweg without access to
>   the Building. This is what multiple of my collegues complained
> about.
> 
>   Here i bend geometry until it halfway worked.
> 
> Just 2 examples for the last 10 days or so. And footways wont help
> you in a car profile. You could bring a footway directly connecting
> the entrance to the Street.

And most likely - Try and schools in your area. If its correctly
mapped with the school ground as an amenity=school and buildings
etc.

Try to reach it by car:

Elly-Heuss-Knapp Realschule, Gütersloh

You'll end on the wrong street without parking and a gate although
the school has a parking lot. And you even end up in a oneway hell.

Whenever you try to reach "large" osm objects on the routable network
you are in deep trouble. camp sites, airports, golf courses, schools.
People move the attributes from the polygons to nodes to make it
explicit where to navigate. With polygons its up to the algorithm
to guess the right point.

And i had tons of stuff like this the last decade. 2 Years ago
i ended up on a road at a river (by bike) the campsite on the opposite
side of the river. 5km to next bridge to cross the river because the
road 20m on the other river side was the nearest point on the routable
network. Roads on the campsite were access=private. 

I ended here:
https://www.openstreetmap.org/?mlat=53.92106=12.10538#map=17/53.92106/12.10538

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff
On Wed, May 22, 2019 at 08:31:03AM +1000, Graeme Fitzpatrick wrote:
> On Wed, 22 May 2019 at 07:47, Florian Lohoff  wrote:
> > - Houses which are routeable by road a but are near road b or vice
> >   versa.
> 
> That could be a "problem" due to GPS (?) system being so accurate?

And map data beeing very accurate. With commercial data sets you'll map
addresses to street segments. Done. 

We aim much higher. We want exact locations of buildings and we expect
some clever algorithms to match these addresses to roads. Works for 
90% of the cases. And fails in others.

And then we aim even higher. We want all the corner cases to work.
Issues as the above - Address on road A - Reachable only via road B but
near road A. Without hinting there is no way an algorithm will be able
to determine this.

> For instance, where I am sitting now at the back of my house, various GPS /
> location / navigation systems tell me that I am actually at the address
> behind us, of That Road, rather than My Street, because I'm about 1m closer
> to that street!
> 
> If I turn OSMand on & ask it to take me from my present location to my
> Home, it will tell me to walk or drive around the block!

Its not an GPS issue - Navigation works different - You tell where you
want to go and it selects a precise and explicit point on the routing
graph where to take you to. And it'll follow on the graph to that
location. The mapping of an address to a location on the routeable
graph is the Problem - not the routing/gps. This is why i called
it "navaid" not "routingaid".

Id imaging a relation which says

object A -> car -> Node B (on routable graph)

So whenever i tell my nav software to bring me to object A the node
selected on the routable graph as a destination will be Node B.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff

Hi Marc,

On Tue, May 21, 2019 at 10:38:23PM +, marc marc wrote:
> > What is the expectation to get navigated to when selecting a park?
> 
> there is no such thing as "a single point that makes everyone agree"

Yes there is - there has to be an explicit location you will ne navigated
to for a certain feature. 

It might be that there are multiple - then you might want to choose.
Currently you'll be guided to a random location which fits whatever
nearest point algorithm your router/navigation uses. Non deterministic
from a users perspective.

> take the case of a square park fenced by a fence, surrounded by 4 
> streets each with a pedestrian entrance to the park.
> those arriving from the north will probably want to stop at the street 
> to the north, while those arriving from the south will probably want to 
> stop at the street at the south entrance.

Tell me ONE application that does this. None. All of them map a feature
you select (Address, POI, whatever) - map it to a single precise point
and bring you there.

> > Doesnt work - You are navigating by car but you only have a footway up
> > to hour house - Still the house is near road b - thus you get navigated
> > to the wrong street.
> 
> that's a bug/a feature needed in the routing, all info exist in osm
> to find the path to reatch to the house, instead of leaving you at
> a closer location but whose routing to the house is unknown

Nope - there isnt enough information. Its all just implicit and works
for 95% of the cases. It breaks horrible in others and we fake
geometries to fix it, blame the application, invent tags to guide the
nav/routing which only fit half of the object and only half of the
apps support. In all cases the user is in trouble.

> > Detaching addresses from house geometries putting it near the road 
> > i expect people to be navigated to.
> 
> so UGLY ! You decide, for the example of the park, that everyone
> must use YOUR favorite entrance.

No - i expect to select a feature and when there are multiple entrances
i expect the Nav to ask me. Currently it doesnt - no application does.
They simply guide me to some arbitrarily choosen point calculated
from some geomtry which fits some nearest point matching algorithm. And
there is NO way to fix this.

> it is tagging for your-routing, instead of allowing routing to have 
> personalized options (shortest route, least walking, close to a parking, 
> disabled accessible up to the poi)

No - as i said - its about hinting. We have a low percentage of
nav targets which are not or suboptimally reached with current
alhorithms. Its about a navaid hint to help algorithms choose
the right and optimal destination point for a certain object and mode
of transportation.

If its foot and you have a footway to the entrance - Its the entrance.
If there is an explicit car park than its that for the car. If its
by bus you can select the bus stop (in which case you switch mode of
transportation and have your next destination from the navaid relation)

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-22 Thread Florian Lohoff

Hola Mateusz,

On Wed, May 22, 2019 at 12:26:01AM +0200, Mateusz Konieczny wrote:
> 21 May 2019, 23:46 by f...@zz.de:
> 
> > - Houses which are routeable by road a but are near road b or vice
> >  versa.
> >
> > Adding more roads aka service/driveway does not necessary make it more
> > deterministic.
> >
> Can you give example of residential building with fully mapped roads, footways
> and obstacles where well written router will fail?

- Baumstraße 43a, Gütersloh, Germany
It does not have a connection to Baumstraße but to
Hermann-Vogelsang-Straße.

It still will be routed through Baumstraße and the driveway to
Baumstraße 45a

IMHO unfixable without bending geometry 

- Dalbker Straße 40a, Oerlinghausen, Germany 
  Dalbker Straße 44a, Oerlinghausen, Germany 
Both fixed by moving the Address to a node, moving it further to
Dalkbker Straße within the outline of the Building.

Otherwise you'd be routed to Buchweizenweg without access to
the Building. This is what multiple of my collegues complained
about.

Here i bend geometry until it halfway worked.

Just 2 examples for the last 10 days or so. And footways wont help
you in a car profile. You could bring a footway directly connecting
the entrance to the Street.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Navaid relation?

2019-05-21 Thread Florian Lohoff

Hi marc,

On Tue, May 21, 2019 at 10:02:53PM +, marc marc wrote:
> Hello,
> 
> Le 21.05.19 à 23:46, Florian Lohoff a écrit :
> > Currently all Routing/Navigation application try hard to find
> > the nearest or best point on the routeable network for a given
> > destination lat/lon or object.
> 
> with best, you mean : only one ? that look like wrong
> a destination can have several points depending on the type
> of locomotion.
> the same type of locomotion can have several points, e.g. several ways 
> that desert a station by foot, several other for car, ...

What is the expectation to get navigated to when selecting a park? When 
there are several for a car? Currently its random where you get
navigated to - There is no deteministic type to describe the nav point.
It depends on geometries of roads which might not describe the real
point you want to be guided to.

Geometries of the Park and Road follow strict "map what you see" or 
"ground truth" - With this principle there is no way to map the nav
point without bending ground truth.

> > - Large OSM objects like airports, campsites, parks, malls etc are not 
> > really
> >identified by a node/point in OSM but an area. Currently it is mostly
> >luck if this is correctly routable.
> 
> put one or more node on the outer with entrance=yes/main :)
> I use foot/vehicle/bicycle=designed to describe the type
> of locomotion for this entrance

This does not work for all cases and all objects.
 
> > - Houses which are routeable by road a but are near road b
> 
> add door/entrance but also add missing ways to connect to the road A

Doesnt work - You are navigating by car but you only have a footway up
to hour house - Still the house is near road b - thus you get navigated
to the wrong street.

> > work in application A but not B.
> 
> open an issue for B ?

So for every kind of object we open bugs for Applications a-z except
$RANDOMAPP ?

Wouldnt it make sense to have a generic description for this problem?

Currently i fake geometries to fix these kind of issues. Detaching
addresses from house geometries putting it near the road i expect
people to be navigated to.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] Navaid relation?

2019-05-21 Thread Florian Lohoff
Hi,
is there any Navaid relation to map an object to a point on 
the routeable network?

Currently all Routing/Navigation application try hard to find the
nearest or best point on the routeable network for a given 
destination lat/lon or object.

I have seen this fail for multiple occurences over the last
decade and i was pointed to one again from a collegue of mine.

Some examples:

- Large OSM objects like airports, campsites, parks, malls etc are not really
  identified by a node/point in OSM but an area. Currently it is mostly
  luck if this is correctly routable. 
- Houses which are routeable by road a but are near road b or vice
  versa.

Adding more roads aka service/driveway does not necessary make it more
deterministic.

People try to work around by adding entrance=yes/main whatever tagging
to objects which work in application A but not B.

In my head i have a relation which has the source object, destination
node on the routeable network and the vehicle/mode of transportation 
to use this for (car, bicycle and foot may have different destinations)

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] tracktype=*;*;*

2019-05-09 Thread Florian Lohoff
On Thu, May 09, 2019 at 01:37:09PM -0600, brad wrote:
> I'm seeing some tracks with multiple tracktype's like this:
> 
> Way 364707088 [highway=track,  name=FR 514, tracktype=grade2;grade1;grade3]
> 
> Is this generally accepted practice?
> If so, why?

IMHO does not make sense at all. Most likely somebody joined track
segments without noticing the different grades and the editor
joined it.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Whispering asphalt

2019-05-02 Thread Florian Lohoff
On Thu, May 02, 2019 at 07:55:40PM +, amilopow...@u-cloud.ch wrote:
> Hello
> 
> I used to live in Fribourg, Switzerland where they put "whispering
> asphalt" on one of the main roads in order to prevent noise. You can
> barely hear an EV now, but that is another story.
> 
> Since we have quite a lot of discussions about noise pollution I
> thought it might be a good idea to implement a tag for that.
> 
> surface=whispering_asphalt or surface=silent_asphalt came to my mind
> but I don't know what the official term for that aspahlt in English
> is. In German we call it "Flüsterbelag" or "Flüsterasphalt".
> 
> Then I found on Overpass-Turbo someone that tagged
> "asphalt:type=porous". [1] Since I don't work in that area I don't
> know for sure if this is the same thing as I imagine and I found only
> one Wikipedia article in German [2] about that asphalt I mean.
> 
> I personally prefer one of my first ideas, since I hate to add another
> key/value if I can say it in one.
> 
> I look forward to hear your thoughts and comments.

The point is that when you invent a new value for surface a lot of
consumers will assume it to be some kind of bad/worse surface and
reduce the average speed to expect.

I'd rather propose surface=asphalt asphalt=whisper or the like.

asphalt:type would also be okay with me. There are more likely 100s of types
of asphalt.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Waterway tributary role

2019-04-13 Thread Florian Lohoff
On Sat, Apr 13, 2019 at 11:48:28AM +, marc marc wrote:
> It's a little more than a personal note.
> 
> I feel like I remember several discussions about this on talk-fr,
> but I didn't look for any other links that had been posted.
> I also don't remember if the page as updated after a thread
> or not. it's a several years old :)
> 
> destination is the opposite, no ?
> if river A go into river B  :
> in relation A : destination=B
> in relation B : A with rôle tributary

I dont think this is necessary to make it that complicated. Processing
geometries with some simple hints where to start enables to produce maps
like this:

https://www.kompf.de/gps/rivermap.html

The page is German but also describes common problems in Waterway
connectivity.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Tagging shared campuses: landuse=school?

2019-04-04 Thread Florian Lohoff

Hi Jeroen,

On Thu, Apr 04, 2019 at 04:11:19PM +0200, Jeroen Hoek wrote:
> On 04-04-19 15:41, Florian Lohoff wrote:
> > Schools have forever been landuse=residential as schools belong to 
> > residential areas.
> 
> This is not always the case, especially in cases where schools share a
> common campus.

No - Amenity and landuse intermix - Basically for me an amenity is
always within a landuse. A landuse is a more general distinction
of rough land usage whereas amenity is a concrete thing.

Shifting an amenity into landuses confuses these two object classes, a rough
classification of land usage, and a very distinct thing.

> This proposal also co-opts existing tags rather than creating new one.
> Does that assuage your concern for landuse=confusion?

I still stand by my opposition.

And while looking through the wiki history of
landuse/landuse=residential and amenity=school i found this:

https://wiki.openstreetmap.org/wiki/Tag:residential%3Duniversity

Which is another issue like this.

I'd like to have a very clear hierarchy in which objects exist which
makes validation a lot easier.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Tagging shared campuses: landuse=school?

2019-04-04 Thread Florian Lohoff
On Thu, Apr 04, 2019 at 09:55:36AM +0200, Jeroen Hoek wrote:
> # Background
> 
> When tagging a school, as per the current documentation, ideally the
> amenity=school tag is applied to the school grounds, implying its
> landuse. This works fine for single schools that have their own
> building, on their own grounds.

I oppose this proposal.

Schools have forever been landuse=residential as schools belong to 
residential areas.

Introducing yet another special landuse is just more confusing and it
does not fix a single issue.

When schools share campus make it a large amenity=school area
without any name and amenity=school + name nodes for the schools.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] leisure=common replacement for public areas with some trees

2019-03-05 Thread Florian Lohoff
On Tue, Mar 05, 2019 at 09:00:09AM +0100, Marián Kyral wrote:
> 
> Hi,
> 
> recently was dropped [1] the leisure=common rendering from openstreetmap-
> carto as it is "misused" by mappers. A suggested replacements are: *leisure=
> park, landuse=grass and/or landuse=farmland*. But there are many places
> around, that are not official park and not grass as there are some trees as
> well. Typically a small areas in the city between apartment buildings. These
> areas are not official parks, gardens or grass. It is just a green
> accessible for everoyne. So we can say it is a *public* or *common* green.

For me these green areas between residential buildings is still
landuse=residential. Gardens are part of living. So IMHO using
the landuse= tagging is wrong. landcover or leisure might be a better approach.

But who am i to judge. I more or less feel disturbed by this kind
of micromapping.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Clarification unclassified vs residential

2019-02-22 Thread Florian Lohoff
On Fri, Feb 22, 2019 at 05:23:36PM +0100, Jan S wrote:
> I understand the documentation of the highway tag as indicating that
> "unclassified" indeed designates a more important road than
> "residential". Under "usage" it reads: "See the table below for an
> ordered list from most important (motorway) to least important
> (service)." And as "unclassified" is above "residential", I would
> consider it as being more important (although this may not be
> respected by routing engines).
> 
> Also, there is nothing to support that residential roads were to be
> used within city limits only. Residential roads are described as an
> "access to housing" or "accessing or around residential areas".
> Residential areas may also well be unincorporated groups of houses
> (thinking e.g. of task description for HOT OSM tasks in Africa).

I have never said that residential may only be used in city limits.
I have said that as soon as there is usage for residential purposes
its not unclassified - Thats exactly the terminology from the wiki:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
"Public roads of low importance within town and cities that are not
residential may also be highway=unclassified."

Residential roads are by definition:

https://wiki.openstreetmap.org/wiki/Tag:highway=residential
"This tag is used for roads accessing or around residential areas."

So - bringing this together - as soon as there is residential usage
it cant be unclassified? Am i so wrong?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Clarification unclassified vs residential

2019-02-22 Thread Florian Lohoff
On Thu, Feb 21, 2019 at 04:54:09AM -0700, Richard Fairhurst wrote:
> Florian Lohoff wrote:
> > From the original meaning unclassified was the lowest class road 
> > in rural or off city limits. residential was the lowest class road 
> > within city limits. (Assuming that city limits mean residential 
> > usage)
> 
> That's reasonable but not _quite_ true. highway=unclassified is often used
> in urban areas to denote a minor distributor road. 

But the above is the documentation we had for like 10 Years - This is 
why i asked for clarification. It seems everybody has different
assumptions about usage and priority of unclassified vs residential
and those are not reflected in the unclassified tag page. The German
page has much more stuff but IMHO wrongfully added by a small group.

> https://www.openstreetmap.org/way/145016745 is a good example
> (https://goo.gl/maps/YUc6XfuA5wQ2 if you'll excuse the Google Street View
> link). It's the distributor road for that estate, and of greater importance
> than the largely cul-de-sac residential roads going off it; but doesn't have
> a significant through-traffic purpose nor the engineering standards that
> would imply highway=tertiary.
> 
> > [...]
> > From OSRM profiles it isnt - So it doesnt make a difference for at 
> > least OSRM.
> 
> OSRM's default profiles don't measure importance, only speed, and are fairly
> blunt instruments which aren't used unmodified by anyone who's serious about
> quality routing results. (Mapbox, OSRM's sponsors, override them with
> traffic speed data, for example.) I wouldn't count them as a useful
> indicator.

But users try to retag residentials to unclassifieds to gain importance
in routing which would not work at least for OSRM because they are
treated identical in the default OSRM setup.

OSRM is just an example i had at hand quickly as i use it for
QA/Monitoring of routing changes.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Florian Lohoff
On Wed, Feb 20, 2019 at 09:39:00AM -0300, Fernando Trebien wrote:
> Applications expect each level of the street mesh to be as complete
> and connected as possible. Some routing engines (especially older
> engines and software running on embedded devices with low CPU/memory,
> not the case of OSRM and GraphHopper) employ heuristics that
> prioritize following streets of higher classification first. In that
> sense, highway=unclassified would work like a level between
> residential and tertiary, that is, this kind of routing engine would
> avoid computing routes through residential streets unless it cannot
> find a route using higher road classes. So if an highway=unclassified
> route is interrupted by a string of highway=residential in an urban
> area, the engine will avoid considering the through route, it will do
> so only after exploring all other alternatives of higher class, and
> that may result in a much larger route around that area in the highway
> mesh.

This is only under the assumption that unclassified is indeed something
"better" than residential which from the original tagging it isnt.

From the original meaning unclassified was the lowest class road in
rural or off city limits. residential was the lowest class road within
city limits. (Assuming that city limits mean residential usage)

Now the German Wiki pages states otherwise - not explicitly that
unclassified is something better but by assuming rules on where to
use it which are contrary to the original meaning of unclassified which
makes users THINK thats its something better.

From OSRM profiles it isnt - So it doesnt make a difference for at least
OSRM.

I dont think that language tagging pages which ought to be translations
start their own agenda and push assumptions which are far off the
original - at least without stating so.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Florian Lohoff

Hi Georg,

On Wed, Feb 20, 2019 at 11:03:15AM +0100, Georg Feddern wrote:
> Even the english wiki says:
> "The tag highway
> <https://wiki.openstreetmap.org/wiki/Key:highway>=unclassified is used for
> minor public roads typically at the lowest level of the interconnecting grid
> network."

Yes - An unclassified road is a road which does not have any
classification. As does a residential not have a classification.

"Unclassified roads have lower importance in the road network
than tertiary roads, and are not residential streets or
agricultural tracks."

Lower importance than tertiary - NOT residential. No word about
beeing of higher importance than residential. 

When you continue reading the distinction is that you MAY use an
unclassified in city limits when there is no residential usage.

"Public roads of low importance within town and cities that are not
residential may also be highway=unclassified."

For me this means that 99% of the roads within city boundarys cant
be unclassified because there is residential usage.

> As part of the interconnecting grid network it should connect to at least
> unclassified or higher roads - unless it is a dead end settlement.
> Tagging a through connecting road only because it is inside a city limit as
> residential makes no sense.

Why not? This enables a routing engine to assume different
characteristics of roads.

> And usually a connecting road from outside a city limit has at least a bit
> more traffic as an inner-city-only residential.

Have you had a look at the original example images for an unclassified?

https://wiki.openstreetmap.org/wiki/File:Highway_unclassified-photo.jpg

I would not expect more traffic here - I'd expect less.

> So the conclusion an unclassified has a bit higher priority than a
> residential is not far from reality.

Not in my reality and not in the original OSMs reality. Yes - through
misleading statements in the German article this might have influenced
at least the German community to assume otherwise - This is why
i request clarification.

> Otherwise there is often the problem to tag the main access roads inside a
> bigger residential area.

The region where i map mostly we agreed that we may tag roads with clear
interconnecting character and wider lanes with one class higher than
they would have by assuming the strict classification. We agreed
that the causes by which we tag higher be placed in a note= tag on
the road.

So a large wide interconnecting road within city limits might be
a tertiary. 

> The practice to tag those as unclassified for a bit higher priority may not
> be optimal - but suitable.
> 
> This discussion - and usage - is some years old now - and I thought you had
> at least knowledge of it from the german forum.

My knowledge and usage predates the German Forum by years - I was astonished
finding statements in the German article for unclassified which do not match
(but oppose) the English versions which i typically use and prefer.

Its not the first time i find the German articles to contain a hidden
agenda bei a minority or single mappers trying to steer the community.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] Clarification unclassified vs residential

2019-02-20 Thread Florian Lohoff

Hi,
i found some changesets downgrading streets to unclassified. After some
discussions the mapper were under the impression that unclassified is
something higher priority than residential.

From my long tagging practice in OSM unclassified and residential are
identical in respect to priority. (And e.g. OSRM treats them equal) 
The first is used as a connecting road off city limits. The latter is
used for the lowest class roads within city boundarys (Where there is
residential usage)

So for me retagging residential to unclassified is broken under the
assumption that unclassified is something "better" than residential.

It is even more broken when there is residential usage in which case
unclassified is inappropriate.

While discussing i found that there was some modification to the German
version of unclassified not saying that unclassified is something
"better" but suggesting that an unclassified should be dragged into
city limits until the next higher class street. This lets user
assume that unclassified is some higher priority than residential.


I was treating those streets identical for the last 10+ years and only
the city limits gave the indication whether to use unclassified or
residential.

Am i wrong with that usage?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] StreetComplete 10 / foot=yes on residential

2019-02-14 Thread Florian Lohoff
On Thu, Feb 14, 2019 at 04:00:24PM +0100, Tobias Zwick wrote:
> Wrong thread?
> 
> Anyway, the quest in StreetComplete only asks for foot=yes/no if the
> road is tagged with sidewalk=no.

Sidewalk is a physical issue - foot=* is a legal issue. 

It is perfectly normal for streets in Germany to have no sidewalk
(Probably around 80% of road distances dont have sidewalks)

Still 99% of roads (Except motorway) are legal to be walked.

And we have that as defaults - motorway/trunk -> foot=no - others
are by default foot=yes

A sidewalk=no does not change any of these assumptions.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] StreetComplete 10 / foot=yes on residential

2019-02-14 Thread Florian Lohoff

Hi,
i am seeing a growing number of changesets setting foot=yes
on all kinds of roads e.g. residential

https://www.openstreetmap.org/way/403719315

Commit message is:

"Add whether roads are accessible for pedestrians"

All residentials are accessible to pedestrians so i a bit puzzled
what this challenge is good for. It just adds redundant tags to
all roads.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Ignore roundabout flare in counting

2018-10-06 Thread Florian Lohoff
On Fri, Oct 05, 2018 at 11:26:01PM +0200, André Pirard wrote:
> On 2018-10-05 20:35, Florian Lohoff wrote:
> > Hi,
> > is there a tag to ignore a roundabout flare in counting the exits?
> Is it a good idea for a navigator to ignore an exit and risk confusion?
> What number should it say if that's the way to go?

Ignore flares if not used in counting.

The roundabout i have in mind has 4 normal exits and one "exit" which is
basically i private driveway. Its that small that noone not known to the
location would notice it.

https://www.openstreetmap.org/#map=18/51.90770/8.26519

Mapillary has some images but the website is broken right now. 
In the josm plugin you can view the images.

Typical exists have islands and 2 oneway flares. But there is one very
small driveway exit nobody really notices but it will be counted.

People are confused as they need to look at the navi screen to see the
direction to follow.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Ignore roundabout flare in counting

2018-10-06 Thread Florian Lohoff
On Fri, Oct 05, 2018 at 10:46:08PM +0200, SelfishSeahorse wrote:
> On Friday, October 5, 2018, Florian Lohoff  wrote:
> > Is there tagging to let announcements ignore that flare?
> 
> I think that if the driveway is tagged highway=service, this should be
> enough information for the routeing engine to ignore it. Besides there
> might be people that don't want the driveway to be ignored.

What about roundabouts only with services? Private property, military,
industrial complexes? No voice guidance there?

I rather go for an explicit tagging to exclude flares in counting as
long as you dont enter or leave the roundabout at that road.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] Ignore roundabout flare in counting

2018-10-05 Thread Florian Lohoff

Hi,
is there a tag to ignore a roundabout flare in counting the exits?

We have a roundabout with a private driveway connecting to the
roundabout. Visually you wont actually count that service road
as a valid roundabout flare but still its a connection.

A mapper now changed to a faked topology to fix the announcements
of the navigation which i reverted. 

Is there tagging to let announcements ignore that flare?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-25 Thread Florian Lohoff
On Wed, Sep 19, 2018 at 11:24:00AM -0700, Mark Wagner wrote:
> My point is that no such guarantee exists for roads without speed limit
> signs.  Yes, the numeric limit for something like Glenwood Road might
> be 50 mph, but the road was designed around farm trucks going no more
> than 20 mph, and has the tight curves, short sight lines, and poor
> surface quality you'd expect for that speed.

This is true for every country in the world. I live in Germany and we
are allowed to go as fast as we like on the Autobahn - no speed limit
involved at all. 

I and all Germans dont assume 1000mph would be safe to drive. Most
German car manufacturers limit their cars to 250km/h or 150mph so thats
a speed you can observe every day.

Sign posted speeds dont are not telling you "this is the speed which is
safe for 100% of the vehicles" but this is the maximum allowed. 
You are still required to drive safely.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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


[Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-17 Thread Florian Lohoff

Hi,
is it intentional that StreetComplete tags the maxspeed source/type in
maxspeed:type instead of the much more used source:maxspeed?

1.2 Mio
https://taginfo.openstreetmap.org/search?q=source%3Amaxspeed

230K
https://taginfo.openstreetmap.org/search?q=maxspeed%3Atype

Wiki menttions maxspeed:type mostly in use in the UK.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] Golf wiki page

2018-07-16 Thread Florian Lohoff
On Sat, Jul 14, 2018 at 01:43:55PM +1000, Warin wrote:
> Hi
> 
> I have just come across a new mapper trying to map a golf course.
> Fine, but they can do with some guidance.
> Looking around for such guidance I came across this wiki page,
> https://wiki.openstreetmap.org/wiki/HOWTO_map_a_golf_course_2013

And it contradicts Best mapping practices by encouraging name tag abuse.

I have seen some Golf courses and all of them have heavy name tag abuse
for descriptions. 

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] highway=service // public road?

2018-05-25 Thread Florian Lohoff
On Fri, May 25, 2018 at 11:54:13AM +0900, John Willis wrote:
> > On May 25, 2018, at 2:29 AM, Florian Lohoff <f...@zz.de> wrote:
> > 
> > Interestingly the key:highway wiki page lists unclassified as
> > the lowest classification of a road:
> 
> That’s weird - since service=alley seems to be the lowest class, being 
> service and all - yet "alley” is a public road. 
> 
> I personally think that the idea of “alley” (urban or rural) is a great 
> concept. 

But the original wording for service made it something completely
different. Usage in parts of the world seem to contradict this (maybe)
and there might be need for "something even smaller" than unclassified.

IMHO the usage of service for some "official small public road" breaks
the concept of a special way not in the public road network, but on
private property. IMHO service=alley way a bad concept - something
like highway=alley would probably be much better.

> So I map them as such, and will continue to do so, under the idea of “alley”.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Tagging] highway=service // public road?

2018-05-24 Thread Florian Lohoff
On Thu, May 24, 2018 at 08:14:34PM +1000, Andrew Harvey wrote:
> On 23 May 2018 at 23:09, Florian Lohoff <f...@zz.de> wrote:
> >
> > https://taginfo.openstreetmap.org/keys/service#values
> >
> > Looking at the values only 10% of the service=* are alley.
> >
> > What about highway=service without service=* ?
> 
> A lot of these are simply a lower classification than residential but don't
> meet the qualification for alley, or any of the other service tags. In my
> region these are commonly named as streets with the suffix "... Lane"
> instead of "... Street" or "... Road".

Interestingly the key:highway wiki page lists unclassified as
the lowest classification of a road:

"The least most important through roads in a country's system"

So using service as an even lower class road contradicts what has
been in the Wiki for ages.

IMHO service is a special road like a track. Its not part of 
a classification of the public road system but used on mostly
private property - Thats what the wiki says for like 10 years?

https://wiki.openstreetmap.org/wiki/Key:highway

"For access roads to, or within an industrial estate, camp site,
business park, car park etc. Can be used in conjunction with service=*
to indicate the type of usage and with access=* to indicate who can use
it and in what circumstances."

So using service as a replacement for a narrow residential or
a small unclassified is mapping for the renderer isnt it?

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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


  1   2   >