Re: [Tagging] Call for verification (Was: Re: [OSM-talk] VANDALISM !)

2020-08-22 Thread Jarek Piórkowski
On Sat, 22 Aug 2020 at 18:12, Clifford Snow  wrote:
> On Sat, Aug 22, 2020 at 3:06 PM Graeme Fitzpatrick  
> wrote:
>> Reading through it though, I noticed though that he used iD, & ticked the 
>> box "I would like someone to review my edits", which apparently didn't 
>> happen at the time?
>>
>> Question though - if an iD mapper asks for someone to review their edits, 
>> where does that appear?
>>
>> Does it just sit on the map like a Note or a Fix Me, or is there a report of 
>> some sort sitting somewhere to be processed?
>
> osmcha.org picks up the review request. Their interface makes it easy to view 
> and post a comment back to the user.

Having said that, it is my impression that realistically a big
majority of review_requested=yes changesets never get a review. I
remember checking it on several of my changesets and never heard
anything.

This might depend on the location of the edit too, similarly to how
OSM.org Notes have different resolution rates worldwide.

(Not picking on anyone, I've also never done a review)

--Jarek

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


Re: [Tagging] Feature Proposal - RFC -Funeral hall

2020-08-19 Thread Jarek Piórkowski
On Wed, 19 Aug 2020 at 11:58, Joseph Eisenberg
 wrote:
>> >>> On 19. Aug 2020, at 15:33, woll...@posteo.de wrote:
>> >> I could imagine rare cases of a privately run cemetery not linked to
>> >> any religion or belief/life stance and where there is such a building.
>> >> But typically, they would be public.
>> >
>> > let me rephrase my question: how important is it that the facility is
>> > “public”?
>> > IMHO this feature should have a functional definition only, everything
>> > else depends on the context and is not really relevant.
>
> In the US, there are privately owned cemeteries, often with a private funeral 
> home / mortuary building on the site. You can buy a plot and also pay for the 
> funeral services, including the use of a hall for a viewing, reception or 
> funeral service (religious or otherwise).

Just to clarify, where "public" and "private" are being discussed
here, is the important consideration private/public ownership, or
private/public right to burial (possibly at a fee?). As I understand
it, most American cemeteries would be privately owned but open to
everyone, but there might perhaps be some religious groups operating
their own burial locations. That assumption of public access might not
traditionally be the case for e.g. European Catholic cemeteries, which
are distinguished from "public" or "communal" cemeteries which accept
burials of non-Catholics.

--Jarek

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


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-18 Thread Jarek Piórkowski
On Mon, 17 Aug 2020 at 23:32, Paul White  wrote:
> I wanted to raise a concern about tagging house numbers on a building using a 
> hyphen to denote the address range (e.g 33-55 Main Street).

Let's keep in mind there are also buildings in London and possibly
elsewhere which have a _single_ entrance and nevertheless a
"hyphenated " address, e.g. 4-5 Bonhill Street
https://www.openstreetmap.org/way/157901333 and buildings nearby.

> This is a bad idea because some areas in the United States and possibly 
> elsewhere use hyphenated street numbers for individual dwellings.[1]

Which are properly entered as addr:unit anyhow

--Jarek

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


Re: [Tagging] new page for tree_lined=*

2020-08-14 Thread Jarek Piórkowski
On Fri, 14 Aug 2020 at 08:34, Paul Allen  wrote:
> I still do not see a purpose for the attribute

That's not what the discussion is about though. The attribute has
already been used 1000 times so the wiki page is documenting the fact
that others saw a purpose for it.

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


Re: [Tagging] Feature Proposal - RFC - Takeaway drinks shops

2020-08-10 Thread Jarek Piórkowski
On Mon, 10 Aug 2020 at 09:09, Paul Allen  wrote:
> On Mon, 10 Aug 2020 at 13:50, Martin Koppenhoefer  
> wrote:
>> > On 10. Aug 2020, at 14:11, Paul Allen  wrote:
>> > Not exactly.  Shop fits where consumption is not allowed on the premises.
>>
>> while it could be an indication, there isn’t such a strong rule that you 
>> could tell from seeing a shop=* tag that consumption is never allowed at 
>> all. At least in Germany for some kind of shop, e.g. shop=bakery or 
>> shop=butcher, there could be a few tables where you can stand (or sit, but 
>> if it’s for sitting it would be called a cafe) and eat things that you 
>> bought without it necessarily becoming a „cafe“ or fast food, nor an 
>> amenity=bakery
>
> We're into cultural edge cases here.

Not surprising since your "shop fits where consumption is not allowed
on the premises" is a very your-culture-centric view on things.

> There are places with lots of seats for consumption on the premises.  And 
> places
> with no seats at all for consumption off the premises.  Calling both of those
> amenities is not helpful.  Calling both of those shops is not helpful.  We 
> clearly
> need both amenity and shop IF both of those types of establishment exist for
> bubble tea.

I disagree with the premise that consumption on premises is to be a
divider. Making two tags for the same kind of shop/service depending
if there's a bench or not seems bad to me. There's supermarkets around
here with a lunch bar where you can order some hot food and sit and
eat it - would you make them an amenity too?

I think we should not use "consumption on premises" as a criterion for
shop/amenity split. If you disagree, please explain how the existing
tags shop=hairdresser and amenity=pharmacy fit into your proposed
tagging scheme.

--Jarek

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


Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

2020-08-09 Thread Jarek Piórkowski
On Sun, 9 Aug 2020 at 10:51, Philip Barnes  wrote:
> One local station has different stop positions for different classes of 
> train. Basically it has a low platform to which a raised section has been 
> added so the stop position ensures one door is at this postition.

This could be one of the cases where stop_position is legitimately
useful. (Or arguably you could instead map two platforms, one for the
low-level one and one for the raised one, connected by a ramp or
steps.)

--Jarek

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


Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

2020-08-07 Thread Jarek Piórkowski
On Fri, 7 Aug 2020 at 20:54, Andy Townsend  wrote:
> https://www.openstreetmap.org/node/12004813 is a
> "public_transport=stop_position" for a local station and is part of
> https://www.openstreetmap.org/relation/6396491 among other relations.
> The problem is that train lengths vary, and there are a number of stop
> positions, each of which are actually signed on the platform for the
> benefit of the drivers.  From memory I think that there's at least a
> 2-car stop, a 4 car stop and 6/8 and 10/12 car stops.  The problem is
> that the current node doesn't correspond to any of them.
>
> As I asked on the changeset that added the one above
> https://www.openstreetmap.org/changeset/40603523 , how should these be
> mapped and how should the PTv2 relations be set up for the different
> services that use them, given that different train services will use
> different stop locations here depending on train length?  Should each
> stop position be mapped and should there therefore be different copies
> of each relation for all the possible train lengths?  Should a "pretend"
> average stop position be added which is actually never correct but will
> at least look nice to data consumers that use PTv2 data?  Given that we
> don't know the actual stop position perhaps the railway=station object
> (in this case https://www.openstreetmap.org/node/7154300845 ) should be
> used instead?

Neither of these seem like great options. Personally: if the stopping
positions for trains of different lengths have actually been surveyed,
I don't have a problem with adding several stop_position nodes with a
note=* or description=* or even an invented
stop_position:train:cars=10;12. Don't put any other tags on them and
they won't render, and it's hardly the most cluttersome of our various
micromappings.

There is however a problem if the Midland Main Line trains come in
different lengths. I suppose you could create a separate route
relation for each set service (from, to, calling at, and train length)
and add the stop_positions to the appropriate relation, but that's
pretty extreme relationing.

(As a bit of background, I believe this is a German influence in the
original PTv2 proposal: a given train ref (e.g. "ICE 13") refers to a
single train that will have the same amount of carriages
(extraordinary circumstances excepted). That's more specific than a
"Midland Main Line: Sheffield => London St Pancras" relation.)

> Maybe the public_transport=stop position should be omitted entirely?
> This last option seems extreme, but one reading of
> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
> where it says "However, marking the stop position adds no information
> whatsoever when it is placed on the road at the point closest to
> highway=bus_stop or on the tram tracks closest to railway=tram_stop. In
> that case it can be abandoned. " might actually support that (and that
> seems to be the view of one side of the argument in the USA).

Note that this sentence was added in various edits in 2020, well after
the initial proposal was approved. "adds no information" might well be
true (given enough computing power), but "it can be abandoned" is
someone's opinion.

I'm personally fine with not having stop_position unless the actual
stopping position is ambiguous due to some very unusual geometry, but
to be clear, this is against the initially approved proposal.

> Maybe the "correct" answer is none of the above?  With a "local mapper"
> hat on I've managed to avoid PTv2 since it basically isn't relevant
> anywhere I normally map things, largely because I don't tend to do that
> near any actual public transport infrastructure, but with a DWG hat on I
> haven't been able to avoid the question, hence me asking here.

I hope the DWG hat is fireproof :) ptv2 is a topic that arouses passions.


--Jarek

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


Re: [Tagging] Feature Proposal - RFC - Takeaway drinks shops

2020-08-07 Thread Jarek Piórkowski
On Fri, 7 Aug 2020 at 14:59, 德泉 談 via Tagging  wrote:
> Sorry for pause the bubble tea proposal for a month due to my personal reason.
>
> In the discussion in June and July some people think the tag for bubble tea 
> is too specific but there is a flaw in existing tags, so I made a new draft 
> for containing more type of takeaway beverages shops, and it's still unsure 
> whether use amenity=* or shop=*.
>
> Please comment and help me to complete the proposal, thanks.

I'm guessing the intended page is
https://wiki.openstreetmap.org/wiki/Proposed_features/Takeaway_drink_shops
?

I find the naming of the page kind of confusing if it suggests to add
the tag shop=bubble_tea. Under "takeway drink shops" I'd expect to
also see smoothie places, cold-pressed juice stands, and the like. I
realize Proposed_features/shop=bubble_tea is taken by the previous
proposal, so how about shop=bubble_tea_(2) or something for the new
proposal's wiki page?

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Jarek Piórkowski
On Fri, 7 Aug 2020 at 10:09, Jez Nicholson  wrote:
> I saw parking_space=takeaway riding on the coattails of the original 
> postis this not a waiting time restriction? Does it merit its own value? 
> Perhaps I'm against it because we don't AFAIK have these in the UK?

How else would you tag it though? The places often don't have an
explicit time limit posted. maxstay=takeway?

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


Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-05 Thread Jarek Piórkowski
On Wed, 5 Aug 2020 at 17:20, Mike Thompson  wrote:
> On Wed, Aug 5, 2020 at 2:59 PM Tod Fitch  wrote:
>> My reading of the wiki [1] indicates that the more specific tag overrides 
>> the less specific tag.
>
> So,
> access=yes
> foot=yes
>
> would then be redundant.  I don't have an example, but I have seen that too.

Technically yes, but there are some cases when tagging redundancy is
worth it or even useful for clarity.

For example, if it's in an area where you might expect access=* or
foot=* to be no, access=yes can be used to confirm that the way _is_
in fact open to the public (signed public route through a private
area, perhaps? like a golf course or a quarry?) and foot=yes can be
used to confirm that pedestrians do have access there as well (perhaps
it's on a motorway but pedestrians are allowed for some reason?).

You can also use this to communicate the actual value of the access=*
tag to your fellow mappers. In an area where access is unclear, if you
tag access=yes, you are saving other mappers from wondering if the way
is actually public, or if it has not yet been surveyed/edited to add
access=private. (In programming terms, access=yes is true, access=no
is false, and lack of an access=* tag is null)

> However, access=yes is a pretty broad statement.  There may be modes of 
> transport not yet contemplated (or which the mapper, and even the land 
> manager is not aware of) which in the future will be prohibited.

If the land manager is not aware of a mode of transport, are they
really in position to prohibit it right now? And in the future,
pedestrians could be prohibited too, and tagging would have to change
as well.

--Jarek

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


Re: [Tagging] what is the "temp" tag?

2020-08-05 Thread Jarek Piórkowski
On Wed, 5 Aug 2020 at 04:41, Frederik Ramm  wrote:
> https://taginfo.openstreetmap.org/keys/temp#values
>
> any guesses as to what this might mean?
>
> I stumbled across it when reverting some vandalism on
> https://www.openstreetmap.org/way/784166844 but that street has been
> split so many times by people adding turn restrictions that the "person
> creating v1 of something" is just the person who split something and if
> I asked them what they meant by temp=tag they'll probably just shrug.

Going back in edit history, the earliest I found was
https://www.openstreetmap.org/way/213444942/history v1 from
https://www.openstreetmap.org/changeset/15525007 in 2013. Doubt you'll
get answers for that, especially considering the edit seemed wonky
anyway with overlapping highways. I agree it's probably some
"temporary tag".

Some of the other values _could_ be temperatures, but doubt it's
anything widely useful.

--Jarek

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


Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

2020-08-03 Thread Jarek Piórkowski
On Mon, 3 Aug 2020 at 19:56, Graeme Fitzpatrick  wrote:
> No, driveway/-through is good for a fuel station, as well as anywhere else 
> that you don't get out of your car to be served eg take-away, car wash, 
> bottle shop (liquor store)

In some parts of the world you have to get out of your car to get
fuel. https://en.wikipedia.org/wiki/Filling_station#Types_of_service

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


Re: [Tagging] Should admin_level=1 tag be applied to EU?

2020-08-02 Thread Jarek Piórkowski
On Sun, 2 Aug 2020 at 07:56, Alan Mackie  wrote:
> On Sat, 1 Aug 2020 at 20:21, Martin Koppenhoefer  
> wrote:
>> > On 1. Aug 2020, at 17:20, Alan Mackie  wrote:
>> > I don't know how I'd map this. Do you have to pass through border 
>> > checkpoints when you enter or leave the area?
>>
>> around here, no, but neither are there border checkpoints at the border of 
>> the main territory, you just walk there without noticing you are changing 
>> country (referring to the Vatican City)
>>
> In this instance I meant the Ahkwesáhsne / US / Canadian situation.

Yeah but per the precedents of the Vatican, Monaco, the Schengen area,
etc, a border checkpoint is not necessarily needed for a country
border to exist and be acknowledged.

Or for another European analogy, consider the Sápmi region inhabited
by Sámi people and their relation to Nordic country borders.

--Jarek

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


Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

2020-08-01 Thread Jarek Piórkowski
On Sat, 1 Aug 2020 at 14:24, Clifford Snow  wrote:
> What I find interesting is that the Canadian Border Crossing is located on 
> the North side of the Saint Lawrence River while the US crossing station is 
> located on the South side of the river. It seems to imply that the Akwesasne 
> Nation is not in either country.

Prosaically, many border control points are built a little away from
the actual border, where it's convenient to build them.

Per Wikipedia, the Canadian border control point was moved from the
island in 2009 after a protest against CBSA agents beginning to carry
firearms.

My personal interpretation reading between the lines is that the
current location is a compromise. You won't find the federal
government saying they don't control the land, but neither was there
an appetite to push for an all-out confrontation. That being said, the
notion of being "in a country" like Canada is of course colonial and
seems to increasingly be fraying for some Indigenous areas here.

--Jarek

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


Re: [Tagging] kerb=regular vs. raised

2020-07-29 Thread Jarek Piórkowski
On Wed, 29 Jul 2020 at 19:46, Martin Koppenhoefer
 wrote:
>> On 30. Jul 2020, at 00:03, Clifford Snow  wrote:
>> The wiki has a raised kerb as any kerb greater than 3cm in height. Your 
>> definition of a regular kerb is one greater than or equal to 10cm
>
> when reading the term raised kerb I’d rather think about something like 
> 25-40cm, while 4 cm surely wouldn’t be considered “raised”

You have to consider the purpose of the tag. To a wheelchair user,
there might not be a lot of practical difference between 25 and 10 cm,
because both are impassable.

> I agree that introducing regular kerbs would only make sense if the raised 
> kerb would change its definition (or be deprecated).
>
> eg this is pretty raised
> http://i.dailymail.co.uk/i/pix/2013/07/29/article-2380778-1B0CC26E05DC-458_634x386.jpg

I would suggest that's a low retaining wall

--Jarek

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


Re: [Tagging] How to map "piers" on land?

2020-07-29 Thread Jarek Piórkowski
On Wed, 29 Jul 2020 at 09:47, Matthew Woehlke  wrote:
> So... back to my *other* question: how should a raised wooden platform
> on land be tagged? For example:
>
> https://www.pitztal.com/sites/default/files/styles/adaptive/public/thumb_5101_lightbox.jpeg
> https://upload.wikimedia.org/wikipedia/commons/e/e2/Laguna_Mountains%2C_California%2C_observation_area_2015.jpg

There is bridge=boardwalk
https://wiki.openstreetmap.org/wiki/Tag:bridge%3Dboardwalk which would
seem to match at least the second image to me.

The first is a bit of a stretch since it's not exactly a far walk, but
seems to be related closely enough? I'd probably mark it as a short
bridge way with a viewpoint at end node, or a bridge area with the
viewpoint tag on the entire area (highway=pedestrian + area=yes +
bridge=boardwalk + tourism=viewpoint?) and a bench node in the middle.

--Jarek

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


Re: [Tagging] How to map "piers" on land?

2020-07-28 Thread Jarek Piórkowski
On Tue, 28 Jul 2020 at 16:10, Paul Allen  wrote:
> There is no part of a pier on land.  Not according to the wiki: "A pier is a 
> raised
> walkway over water..." and "Lastly, connect the pier with other ways on land,
> otherwise it will result in a "island" that can't be used for routing."  The 
> wiki
> then goes on to give a misleading or contradictory mention to connecting
> to the last node of the pier on land.
>
> Since your pier connects to a footpath, replace the bit of the pier on land
> with a closed way tagged area=yes + highway=pedestrian, or similar
> (I don't know if area=yes + highway=footway works).  Just because
> the surface the person walks on is continuous doesn't make the bit
> that's on land a pier.

This is not in line with current usage in OSM, e.g.
https://www.openstreetmap.org/way/172671466 or
https://www.openstreetmap.org/way/30726754 or
https://www.openstreetmap.org/way/626640755

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - UPRN & USRN

2020-07-26 Thread Jarek Piórkowski
On Sun, 26 Jul 2020 at 15:58, Rob Nickerson  wrote:
> Mappers in the United Kingdom are looking to agree two tags for mapping 
> 'Unique Property Reference Numbers' and 'Unique Street Reference Numbers'. To 
> support this effort I volunteered to create the relevant proposal pages on 
> the wiki.
>
> To view and comment on these please see:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn
> https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn
>
> These pages have already been posted to talk-gb and talk-ie (for Northern 
> Ireland) a few days ago. As long as there are no major blockers here, we will 
> move to the voting stage shortly.

Are these reference numbers verifiable in the field? If not, is there
anything to distinguish this initiative from an import?

--Jarek

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


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-25 Thread Jarek Piórkowski
On Sat, 25 Jul 2020 at 16:42, Allroads  wrote:
> bicycle=leave
> This is for me, leave the bicycle behind at the sign.
> More native English speakers can give a comment on that?

I would not have understood it without the explanation given by Peter
below. ("If you are with bike, you will have to leave it there before
passing the sign.")

I'm not convinced it's the best word. Also it would seem to be a
property of a gate-like node, not of a way.

--Jarek

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


Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-24 Thread Jarek Piórkowski
On Fri, 24 Jul 2020 at 21:28, Jmapb  wrote:
> On 7/24/2020 7:12 PM, Cj Malone wrote:
> >> OSM does not store edit timestamps for individual tags, only for the
> >> object as a whole. Finding out when a tag was changed requires a
> >> review of the entire history. I had to do this once when I saw a
> >> clear highway=motorway_link tagged as highway=motorway, with me as
> >> the last user to edit that road segment. Turns out the original
> >> mapper was the one to make the tagging mistake, not yours truly, but
> >> I only found this once reviewing the history.
> >
> > Yeah, that option would require a new API and work done on the OSM
> > server to both calculate the last time a tag was edited, serve it and
> > store the timestamp when "touched" or updated. But once that's done
> > it's done for multiple clients, not just StreetComplete.
> >
> > Otherwise StreetComplete would need to use the History API one each
> > individual nwr and try to calculate the age of a tag.
>
> It sounds to me like what you're describing would require not just a new
> API but a change to the database schema to add a datetime field to each
> tag. Otherwise there would be no way to encode the timestamp of the
> confirmation of an existing tag that does not need changing.

That would be essentially the same thing as what's being proposed with
check_date-like tags, except at a lower level of abstraction. Might be
faster and available to more apps/for more purposes. But on the flip
side, of course new API versions and database fields are a much more
major change than a new tag scheme.

> The history API will only tell you when tags change.

Well, a new API endpoint _could_ automatically read through the entire
history of a node and note which tags changed when. It would
essentially be doing what I do when I open the node history in JOSM
and look when tags changed - only automated. That might well be faster
in the API, where database accesses and data processing is faster. It
would be slower than a dedicated database field, but would not require
the database migration.

--Jarek

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


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Jarek Piórkowski
On Wed, 22 Jul 2020 at 19:33, Jarek Piórkowski  wrote:
> I think the problem is that bicycle=*, foot=*, motor_vehicle=*, etc
> are access mode tags, not possession tags.
>
> When you dismount from a bicycle, you are now a pedestrian who is in
> possession of a certain object. The access tag that applies to you is
> foot=*. You could be on foot carrying a large box, a wide hikers'
> backpack, carrying a bottle of alcohol, pushing a wheelbarrow, or
> pushing a bicycle.

To give some more relevant examples of wheeled possessions: as a
pedestrian, you could also be pushing a baby carriage/stroller, be in
a wheelchair or be pushing a wheelchair, or be in a motorized
wheelchair.

Wheelchair could arguably be an access mode, but the baby stroller
seems to fall rather firmly into "possession" category - and so, to
me, would a pushed bicycle.

--Jarek

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


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Jarek Piórkowski
On Wed, 22 Jul 2020 at 11:35, Tod Fitch  wrote:
>> On Jul 22, 2020, at 8:09 AM, Jmapb  wrote:
>> If this unfortunate tagging practice really needs to be preserved (the idea 
>> of retagging so many bicycle=no ways is certainly daunting) then I'd suggest 
>> a new key, dismounted_bicycle=*, which will function as a regulation key 
>> (like smoking=*) rather than a vehicle access key. Total bicycle prohibition 
>> would be encoded with both bicycle=no and dismounted_bicycle=no, and other 
>> dismounted_bicycle=* values can be developed for whatever the regulations 
>> are in particular situations.
>
> Why? The suggestion that all the places that properly tagged bicycles=no now 
> need to be revisited and have a new dismounted_bicycles=no tag added implies 
> that the people who took “no” to mean something other than “no” prevail and 
> the rest of us have to go back and re-tag things.
>
> Since many miles/kilometers of ways will need to be retagged either way, why 
> not go with the straight forward “no means no” and “dismount means dismount”? 
> Makes a lot more sense to me that “no only really means no if there is an 
> additional dismounted_bicycle=no” tag too.

There are also many ways tagged bicycle=no which should actually have
been bicycle=dismount, because in very many cases traffic signs "no
bicycles" only apply to bicycles ridden (rather than pushed), but
editors will enter a "no bicycles" sign as bicycle=no. Either way we'd
have to do a lot of retagging.

I think the problem is that bicycle=*, foot=*, motor_vehicle=*, etc
are access mode tags, not possession tags.

When you dismount from a bicycle, you are now a pedestrian who is in
possession of a certain object. The access tag that applies to you is
foot=*. You could be on foot carrying a large box, a wide hikers'
backpack, carrying a bottle of alcohol, pushing a wheelbarrow, or
pushing a bicycle.

We do have a dog=no tag for "dogs are not allowed" which really means
"humans are not allowed to allow their dogs to enter here" (dogs can't
read the "no dogs" signs). Similarly in Mike Thompson's example, "no
alcohol" signs mean "humans are not allowed to enter here with
alcohol". Bicycles can't read signs either, but bicycle=* is already
an access mode tag. It would be strange for it to be both an access
mode tag (when ridden, applying to all bicycle=* tags except
bicycle=no) and a possession tag (when pushed or carried, applying
only to bicycle=no).

I do like Mike Thompson's suggestion of something like
bicycle_possession=no along with alcohol_posession=no - exact tag
format could be discussed, but I think logically it's the right idea.

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - (Ground)

2020-07-12 Thread Jarek Piórkowski
On Sun, 12 Jul 2020 at 13:36, mbranco2  wrote:
> ...
> And I think that we could map such characteristic even with only imagery 
> (without direct survey), because it's a "macro" feature, as is a wood or a 
> scrub.
> ...
> Surely it could be useful if botanists and/or geologists could better specify 
> (with more specific tags) the cause: no rain? pollution? specific 
> ground-conditions such as presence of salt or sulfur?
> ...
> Some references:
> - "Barren vegetation" [1]  (..."Regions on the earth’s surface where soils 
> are dominating the ecosystems with little to no plant cover are often 
> referred to as “Barren”. )
> [1] https://en.wikipedia.org/wiki/Barren_vegetation

This Wikipedia article seems to me to use "barren vegetation" to refer
to large areas covered in grasses and/or shrubs. That does not really
seem to match images in
https://wiki.openstreetmap.org/wiki/Proposed_features/Ground#Examples
nor in 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground#Examples
. I would suggest the proposal needs more images to define what would
be included and what wouldn't.

--Jarek

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


Re: [Tagging] Distinguishing closed office spaces and client service locations?

2020-07-10 Thread Jarek Piórkowski
On Fri, 10 Jul 2020 at 18:35, Graeme Fitzpatrick  wrote:
>> (I would probably use access=permissive for e.g. a mall parking lot,
>> where it's not strictly public, but where you wouldn't be expected to be
>> visiting a particular building or organization such that it's much less
>> clear whether or not you are a "customer".)
>
> I've usually left them as =public, but =permissive does seem a better option 
> - thanks!

Just a note that access=public is not a valid value according to some
strict OSM schemas. In particular, you will see carto rendering these
greyed out just as it does access=private or access=customers
(particularly visible on parking lot symbols). access=yes is the
prescribed value for "public access".

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - junction=intersection

2020-07-10 Thread Jarek Piórkowski
On Fri, 10 Jul 2020 at 15:53, Matthew Woehlke  wrote:
> On 10/07/2020 15.01, Martin Koppenhoefer wrote:
> >> On 10. Jul 2020, at 16:17, Matthew Woehlke  
> >> wrote:
> >> My use case isn't the only one that has issues with this sort of
> >> thing; routers can "see" more traffic lights than actually exist
> >> and can (so I hear, anyway) give directions that are potentially
> >> confusing.
> >
> > this is a different issue though, it depends how the traffic lights
> > are mapped (the way the junction is represented does have influence
> > how the traffic lights are mapped, but neither way leads necessarily
> > to a wrong number of traffic lights).
>
> I have to strongly disagree. Consider an intersection of dual
> carriageways (so, four intersection nodes) where signals are tagged on
> the intersection nodes. Please explain how a tool is supposed to
> determine whether a vehicle passing "straight through" the intersection
> will encounter one or two signals.
>
> Now take that same intersection and plop it into a dense urban area
> where there really *are* four separate intersections and explain how the
> same tool is supposed to know when that's the case.

Yeah that's a problem. But since OSM would have to be changed to add
junction=intersection tags anyway, isn't it better to use the
established method of tagging with one traffic signal per direction at
the stop line, as suggested in the wiki
https://wiki.openstreetmap.org/wiki/Tag:highway=traffic_signals#Tag_all_incoming_ways
?

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


Re: [Tagging] How to map terrace buildings with names

2020-07-07 Thread Jarek Piórkowski
On Tue, 7 Jul 2020 at 15:47, Matthew Woehlke  wrote:
> On 07/07/2020 15.24, Skyler Hawthorne wrote:
> > Sure thing, it's here:
> > https://www.openstreetmap.org/#map=19/42.69323/-73.69023
> > ...
> > I did not take photos, as I am not comfortable taking pictures of
> > peoples' homes,
> Google doesn't share your scruples:
> https://www.google.com/maps/@42.6927405,-73.6883336,3a,24y,315.41h,90.23t/data=!3m6!1e1!3m4!1sGkedvwtT8168p_D1SYKF6Q!2e0!7i13312!8i6656

The thing that gives me most pause about this photo is that the units
seem to share a somewhat complex roof structure. It's difficult to
imagine a third-floor addition to one of the units, for example - much
of the roof structure would have to be rebuilt. By contrast, in a
semi-detached house you can usually add an extra floor on only one
side, because even if the roof structure is shared, at least it's
symmetrical between units. To me, that suggests these particular units
aren't fully independent buildings, and speaks in favour of the
tagging with building=terrace for the big outline and
building:part=house for individual parts if you want (but I think
address tagging with addr:* tags on entrance nodes would be just as
valid).

(IMHO)

--Jarek

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


Re: [Tagging] How can I tag which lane has tram tracks?

2020-07-06 Thread Jarek Piórkowski
On Mon, 6 Jul 2020 at 20:15, Jarek Piórkowski  wrote:
> On Mon, 6 Jul 2020 at 15:56, Mateusz Konieczny via Tagging
>  wrote:
> > ...
> > tram:lanes:forward=designated|none
> > tram:lanes:backward=designated|none
> ...
> Looks like tram:lanes variations have around 1100 uses right now,
> embedded_rails variations around 5700 uses. I'm actually not sure if
> they mean something different?

I'm sorry, I realized I got the use count comparison wrong because I
included the non-lane-specific embedded_rails tags.

* embedded_rails:lanes plus embedded_rails:lanes:both_ways plus
embedded_rails:lanes:backward plus embedded_rails:lanes:forward is
used 610 times

* tram:lanes plus tram:lanes:forward plus tram:lanes:backward is used
1035 times - so more

I've not really seen tram:lanes tagging before, how is it used?

Looks like a substantial amount of the uses is tram:lanes:forward=yes
(364 uses) and tram:lanes:backward=yes (317) - mostly on two-lane
streets in Helsinki? tram:lanes:forward=designated|none would indeed
fit that schema.

--Jarek

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


Re: [Tagging] How can I tag which lane has tram tracks?

2020-07-06 Thread Jarek Piórkowski
On Mon, 6 Jul 2020 at 15:56, Mateusz Konieczny via Tagging
 wrote:
> I guess that something similar to
> https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
> would fit.
>
> For example for road that has:
>
> - tram-free lane
> - lane with tram tracks
> - lane with tram tracks in an opposite direction
> - tram-free lane in an opposite direction
>
> could be tagged
>
> tram:lanes:forward=designated|none
> tram:lanes:backward=designated|none

I'm not sure - does this add something that embedded_rails:lanes=*
does not specify?

If you have the tram tracks already mapped as their own ways, I'd just
do embedded_rails:lanes=|tram|tram| on the street way.

Looks like tram:lanes variations have around 1100 uses right now,
embedded_rails variations around 5700 uses. I'm actually not sure if
they mean something different?

Actually I guess they might since there's some abandoned tracks here
(e.g. https://osm.org/way/553562816 + https://osm.org/way/553562815 )
where embedded rails still exist but trams don't have a legal access
(or physical access), so strictly speaking the street way would be
embedded_rails:lanes=|tram|tram + tram:lanes:forward=|no|no... but I'm
not sure if that's what you meant?

--Jarek

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


Re: [Tagging] Is it bicycle_parking=stands?

2020-07-05 Thread Jarek Piórkowski
On Sun, 5 Jul 2020 at 06:52, Mateusz Konieczny via Tagging
 wrote:
> In use it is a bicycle parking stand, you
> can attach a bicycle by frame,
> frame is supported.
>
> But it is not in a traditional reversed U
> shape, but rather in O shape
>
> https://commons.m.wikimedia.org/wiki/File%3ABicycle_parking_-_stand_in_ring_form.jpg

Hello,

In Toronto we've mapped a similar thing but with a smaller ring as
bicycle_parking=bollard, but I am a bit dissatisfied with that since
it's called "post and ring" locally which seems a bit more specific.
https://www.openstreetmap.org/node/6034796623 for example. They look
like 
https://wiki.openstreetmap.org/wiki/File:Bike_path_on_College_in_Toronto.jpeg,
either perpendicular or parallel to street.

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-07-03 Thread Jarek Piórkowski
On Fri, 3 Jul 2020 at 10:19, Paul Allen  wrote:
> On Fri, 3 Jul 2020 at 14:22, Jarek Piórkowski  wrote:
>> On Fri, 3 Jul 2020 at 05:47, Paul Allen  wrote:
>> > I think that coffee_shop and teahouse are not cuisines.   I'm not convinced
>> > inventing drinks=* to show what they focus on is a good idea and that
>> > description=* might be a better way of dealing with it (if the name of the
>> > place doesn't give it away).
>>
>> I strongly disagree and would much prefer a newly specified drinks=*
>> tag, or an "abused" cuisine tag, over a free-text description field.
>> This is because the former is much more reliable for sake of machine
>> readability (and also leaves description for anything else a mapper
>> might like to note). This would be doubly the case if we also adopt
>> this for espresso takeaway bars (as shown in Tan's instagram first
>> link) with no seating or very limited seating.
>
> That's what happens when I try to avoid upsetting people by
> suggesting a compromise. :)
>
> I think there is only one good way of handling a drink that is the
> primary focus: make it the only drink that has drink:*=yes.  As far
> as the user can tell from the map, that's all the shop sells.

No, that's not the intended purpose of this use of drink=*/cuisine=*.
It's to specify the general type of the shop=drinks.

We don't map a shop=greengrocer with extra tags if they happen to
stock a shelf of canned food in the back too, it's the general
category that's important.

> ...
> I think common sense has to play a part here. We don't
> list the entire inventory of every shop we map because
> it's impossible.  Somewhere with a coffee machine that's
> a hybrid of a church organ and a steam train may also sell
> tea and juice, but probably not in anywhere near as many
> varieties/sizes/combinations, so they can be omitted or
> relegated to the description.  Or we go the other way and
> list every drink sold by a pub, and all the flavours of all
> the snacks it sells, and the flavours and textures of the
> condoms sold by the vending machine in the toilets
> (and we then need a way of specifying which flavour of
> condom the vending machine focuses on).

I think common sense has to play a part here. Focus on the main
category of the shop. A bubble tea shop is not at all like other kinds
of tea shops, and fairly substantially different from other kinds of
drink takeaway shops, and that's why there's a need to tag it
separately.

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-07-03 Thread Jarek Piórkowski
On Fri, 3 Jul 2020 at 10:36, 德泉 談 via Tagging  wrote:
> I think I may redraft a feature proposal for the shop focusing providing 
> takeout beverages or only have very limit seats and merge the bubble tea shop 
> proposal into it. Right now we have amenity=cafe and shop=beverages for those 
> sell drinks. Actually I'm not sure that if the feature of a amenity=cafe is 
> providing a cozy social/rest space or not. But it seems like both of the two 
> tags are not suitable for shops I want to map.
>
> The proposal would introduce a new tag (maybe amenity=drinks or 
> amenity=takeout_drinks or what). This kind of places sell beverages mostly 
> with takeaway paper or plastic cup, people can drink in their home or office 
> after buying.
>
> But after this proposal we can merged the bubble tea proposal and the juice 
> bar proposal 
> (https://wiki.openstreetmap.org/wiki/Proposed_features/Juice_bar) to clarify 
> the tagging scheme of these shops.

This sounds good to me. Thank you for sticking with this!

On Fri, 3 Jul 2020 at 05:47, Paul Allen  wrote:
>> This kind of places may focus on different drinks: coffee/iced 
>> tea/juice/bubble tea/etc... We can use the existing cuisine=* tag or a new 
>> tag for example drinks=juice to distinguish what they focus on, and 
>> drink:*=yes to show if a shop provides a kind of drink. (BTW do anyone 
>> thinks cuisine=coffee_shop or cuisine=teahouse are weird as me?)
>
> I think that coffee_shop and teahouse are not cuisines.   I'm not convinced
> inventing drinks=* to show what they focus on is a good idea and that
> description=* might be a better way of dealing with it (if the name of the
> place doesn't give it away).

I strongly disagree and would much prefer a newly specified drinks=*
tag, or an "abused" cuisine tag, over a free-text description field.
This is because the former is much more reliable for sake of machine
readability (and also leaves description for anything else a mapper
might like to note). This would be doubly the case if we also adopt
this for espresso takeaway bars (as shown in Tan's instagram first
link) with no seating or very limited seating.

--Jarek

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


Re: [Tagging] How to tag a graffiti?

2020-07-02 Thread Jarek Piórkowski
On Thu, 2 Jul 2020 at 09:26, Paul Allen  wrote:
> On Thu, 2 Jul 2020 at 14:05, Martin Koppenhoefer  
> wrote:
>> a monument is an object that you can go into, you cannot enter a graffiti so 
>> in any case this is not a monument for OpenStreetMap.
>
> From the wiki: "A memorial object, which is especially large (one can go 
> inside,
> walk on or through it) or high enough..."  Those are alternative criteria, not
> components of a single criterion.  Although it might (just) be high enough,
> that wall was not constructed as part of the memorial.  But if it had been
> constructed as part of the memorial, it might (just) qualify as a monument.
>
> Now that I think about it, is 
> https://commons.wikimedia.org/wiki/File:First_World_war_memorial_-_geograph.org.uk_-_535659.jpg
> a monument or a memorial?  To give an idea of scale, that grey rectangle
> to its right, near a tree, is a phone box.  It's tagged as a memorial,
> but maybe it's high enough to be a monument.

If we are making a distinction, to me, that's definitely a memorial.
It's not monumental in scale. Even the plain two-story buildings
around it are taller.

If this was a monument, what would we consider a much taller sculpture
like 
https://commons.wikimedia.org/wiki/File:Gdynia_Pomnik_Ofiar_Grudnia_1970_w_Gdyni_przy_al._Pi%C5%82sudskiego1.jpg
(https://osm.org/node/4353704772)? Of course we can tag the height
instead, but if we _are_ making a distinction, then the former is much
less monumental.

In retrospect, the monument/memorial distinction was probably a bad
idea - I see a lot of small memorials (like life-size statues) around
Toronto tagged as monuments, because editors think of them as
"monuments to history" or "historical monuments". Just an unclear
distinction that apparently only serves rendering at different zoom
levels.

--Jarek

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


Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

2020-07-01 Thread Jarek Piórkowski
On Wed, 1 Jul 2020 at 16:55, Martin Koppenhoefer  wrote:
> On 1. Jul 2020, at 02:51, Jarek Piórkowski  wrote:
>> Do we want to introduce new tags for gastronomical service places? If
>> yes, so far takeaway has one of the clearer definitions I've seen, so
>> we could start there.
>
> we already have the quite established tag takeaway=yes/no/only
> no need to reinvent the wheel: 
> https://taginfo.openstreetmap.org/keys/takeaway#values

Yeah, but we're being told that British takeaways are very different
from other casual food places that have seating and the provision of
seating is of key interest to Paul.

So, are they different enough to have a new root tag? Or do we accept
ambiguity of cafe/fast_food root tags and specify with subtags?

In my reading, that's what the entire discussion has been about.

--Jarek

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


Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

2020-06-30 Thread Jarek Piórkowski
On Tue, 30 Jun 2020 at 20:28, Paul Allen  wrote:
> On Wed, 1 Jul 2020 at 01:02, Jarek Piórkowski  wrote:
>> Maybe tag them amenity=takeaway
>
> Good idea.  Except that value is not officially agreed and isn't
> rendered.  Are you suggesting somebody propose it?

It doesn't look like being officially agreed has helped us much with cafe, so...

Do we want to introduce new tags for gastronomical service places? If
yes, so far takeaway has one of the clearer definitions I've seen, so
we could start there.

>> and leave amenity=fast_food for the other kinds of
>> places?
>
> So you're saying that amenity=fast_food should only be used where
> there are seats?

Nah. If it's a place that an editor would consider a takeaway, tag it
as takeaway. Otherwise tag it as something else. amenity=fast_food
could become a less-specific fallback, like highway=road.

> That goes contrary to many people's
> expectations.  And sort of implies that takeaways don't
> serve fast food.

Not anymore than using highway=primary implies it isn't a road.

> In any case, given the number of places already
> mapped, retagging of that sort isn't feasible.

Eh, as opposed to retagging coffee shops or McDonald's being feasible?

--Jarek

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


Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

2020-06-30 Thread Jarek Piórkowski
On Tue, 30 Jun 2020 at 13:15, Paul Allen  wrote:
> On Mon, 29 Jun 2020 at 12:35, bkil  wrote:
>> Note that illustrations depict Burger King, McDonald's and a fish and
>> chip shop in England, and that the icon generally depicts a fast food
>> item like a burger. It is true that there exist such small fast_food
>> restaurants that they operate from a vehicle and they may only have
>> tables, but no seats (takeaway=only and/or capacity=0), but this is a
>> minority.
>
> That may be the situation where you are but not where I am.  More than
> half of the fast food outlets in my town have no seats and are takeaway only.
> Many chip shops I've encountered in the UK are takeaway only.

You've repeatedly referred to them as takeaways. Maybe tag them
amenity=takeaway and leave amenity=fast_food for the other kinds of
places?

--Jarek

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


Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

2020-06-29 Thread Jarek Piórkowski
On Mon, 29 Jun 2020 at 07:53, Paul Allen  wrote:
> On Mon, 29 Jun 2020 at 12:02, Jake Edmonds via Tagging 
>  wrote:
>> While it might be used in Paul’s area, McDonalds is not a cafe where I am 
>> from, and would put money on most British people calling it a fast food 
>> restaurant
>
> I am surprised that there is anywhere in the world that would glorify a
> McDonalds sit-down area with the term "restaurant."  Candle-lit quarter
> pounders for two?  Would sir like wine with that?
>
> However, taking another look at the wiki for fast food, I see it covers
> sit down as well as takeaway only.  Which surprised me (never having
> had to map a McD).  For me there is a very, very big distinction between
> a takeaway-only place and somewhere you can sit down to eat.  Counter-only
> service is not a biggie.  Speed of the food is somewhat important but speed
> is a continuous variable, even at a single establishment: I can go to a
> chip shop and, if there's no queue, have my order filled in under a minute;
> or I can go in and they've run out of chips and I have to wait 10 minutes
> while they fry more.  Whether or not I can sit down out of the rain
> matters far more to me.
>
> But we have what we have: a tag that seems specially crafted for McD,
> whether it has seating or not, as opposed to a tag for somewhere with
> no seats at all.

(Sorry for bringing this thread about cukiernias further off-topic.
This is also related to the parallel discussion that started off being
about bubble tea places.)

This is getting faintly ridiculous. It is all good and well to use
British English in OSM, but let's not extend it to mean that we have
to limit ourselves to definitions of places as they exist in parts of
the UK.  Per guidelines set out by you, a lot of establishments mapped
as cafes in OSM aren't cafes (Starbuckses, Costas, and anything even
remotely similar), and a lot of establishments mapped as fast_food are
actually cafes (McDonald's and anything similar). I'm half-expecting
to hear that a Starbucks is actually a bar with drink:coffee=only.

At some point we have to draw a line and say that OSM tagging of
almost a million objects is unlikely to be changed, regardless of what
the words strictly mean in British English.

McDonald's is an extremely common type of gastronomic service in
American-like-culture world: you place an order from a fixed menu,
food is prepared from pre-made supplies, possibly being warmed or
grilled but not a meal fully cooked to order, there is normally no
table service, there is usually casual seating in the establishment,
and takeaway trade is also quite high. There is no way
amenity=fast_food is "special crafted for McD".

Here's a local shawarma place near me, serving wraps or plates with
assorted vegetables, sauces, and meats, assembled in front of the
customer from prepared ingredients (links lead to images hosted on
Google servers):
- there is some non-fancy seating and there is also a lot of takeaway
trade: https://goo.gl/maps/ve2YXgi29z8jstdH6
- ingredients are pre-chopped, meat is cooking on a vertical
rotisserie, nothing is fried in a back kitchen:
https://goo.gl/maps/PxUAyt4UXXT4wmW27

Here is an American import in Manchester that operates on the same
principles: https://goo.gl/maps/HKxevHp8rpceQw8RA ,
https://goo.gl/maps/xZv2cH5LZZJ3QNaQA

How should my shawarma place be tagged per British English? Is it a
cafe even though it doesn't have a back kitchen and doesn't serve
cooked meals? A fast_food? But it has seating. Surely not a candle-lit
restaurant. shop=food perhaps? amenity=fast_food_with_seating?

--Jarek

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


Re: [Tagging] Central European insight needed: cukrászda, cukrárna, cukiernia, ciastkarnia, cukráreň, pasticceria, konditorei, patisserie, ...

2020-06-28 Thread Jarek Piórkowski
On Sun, Jun 28, 2020, 15:54 Paul Allen,  wrote:

> Cafes are more about fast food with seating (again,
> a generalization).  To over-generalize even further, a cafe is fast food
> with
> seats.  My local chip shop (fast food) has a seated area (making it a
> cafe).
>

Does this mean that in British English, a McDonald's that has seating is
not a fast food place but a cafe?

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


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-06-27 Thread Jarek Piórkowski
On Sat, Jun 27, 2020, 17:52 Paul Allen,  wrote:

> On Sat, 27 Jun 2020 at 22:16, Jarek Piórkowski 
> wrote:
>
>>
>> I wish you much luck convincing iD not to apply its presets ("upgrade
>> tags") for those Starbucks locations that don't have seating. I tried
>> insisting on tagging a local location's actual posted name ("Starbucks
>> Coffee") and lost badly.
>>
>
> I've not tried over-riding a name=* derived from the brand, but I've
> over-ridden
> names of hamlets and villages where name=* derived from Wikidata.  iD even
> helpfully tells you how to do it if you try to alter the locked name in
> the preset -
> change it in the raw tags.
>

And then someone comes round and "upgrades tags" to match iD brand presets
:)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-06-27 Thread Jarek Piórkowski
On Sat, Jun 27, 2020, 11:10 Martin Koppenhoefer, 
wrote:

>
> > On 27. Jun 2020, at 16:59, Shawn K. Quinn  wrote:
> >
> > Even if it [a Starbucks location]
> > was just a kiosk I would still tag amenity=cafe for consistency.
>
>
> if it were just a kiosk you should not tag it as amenity=cafe, exactly for
> this reason: consistency.
>

I wish you much luck convincing iD not to apply its presets ("upgrade
tags") for those Starbucks locations that don't have seating. I tried
insisting on tagging a local location's actual posted name ("Starbucks
Coffee") and lost badly.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-06-26 Thread Jarek Piórkowski
On Fri, 26 Jun 2020 at 12:42, Paul Allen  wrote:
>> It's basically a cafe. It prepares drinks to order. Best tagging I've
>> seen around me is amenity=cafe + cuisine=bubble_tea
>
> As described in the proposal, most lack seating.  Which makes those
> without seating shops rather than cafes.

This is the first time I'm hearing about an OSM distinction between
shop and cafe based on seating or not.

If there's an espresso counter that does takeaway only does that
become no longer an amenity=cafe + cuisine=coffee_shop? I can think of
several coffee shops in Toronto that only do takeaway - e.g. in office
areas, or near parks.

Would it not be better to tag dine_in=no or something?

>> I would suggest using an amenity tag rather than a shop tag since it's
>> much more like a cafe or a fast food place than a store.
>
> I can see that it's more like fast food since the stuff has to be prepared.
> But then I think "Starbucks."  Have we already standardized on a way
> of tagging somewhere without seats that sells takeaway coffee?

I'd use amenity=cafe + cuisine=coffee_shop, I guess could add
takeaway=only ¯\_(ツ)_/¯

> If we don't have a way of mapping
> coffee takeaways then we probably need one that can,deal with coffee,
> bubble tea and whatever else with appropriate drink:*=*.

Still not sure why we can't just use cafe. Is "cafe" exclusively for
sit-down, dine-in places in British English?

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - shop=bubble_tea

2020-06-26 Thread Jarek Piórkowski
On Fri, 26 Jun 2020 at 11:50, Paul Allen  wrote:
> On Fri, 26 Jun 2020 at 16:31, 德泉 談 via Tagging  
> wrote:
>>
>> I've drafted a new proposal about the bubble tea shops which are very common 
>> in Taiwan which are usually mismapped as shop=beverages
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/shop%3Dbubble_tea
>
>
> Looking at your proposal, I fail to see how these are not shop=beverages.

Have you seen a bubble tea shop?

It's basically a cafe. It prepares drinks to order. Best tagging I've
seen around me is amenity=cafe + cuisine=bubble_tea

See https://wiki.openstreetmap.org/wiki/Tag%3Acuisine%3Dbubble_tea -
per https://taginfo.openstreetmap.org/tags/cuisine=bubble_tea it's not
very common but for example iD presets have amenity=cafe +
cuisine=bubble_tea for Chatime
https://github.com/osmlab/name-suggestion-index/blob/c0b65aacf04be6753f6e7e82007399bee1e65fdc/brands/amenity/cafe.json#L314-L329
as well as Gong Cha, Sharetea, and a few others.

I would suggest using an amenity tag rather than a shop tag since it's
much more like a cafe or a fast food place than a store.

> Your proposal mentions several features that I do not see as being
> unique to bubble tea shops or excluding beverage shops.  Beverage
> shops may supply fresh tea and juice.

But usually they do not. Example picture on
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbeverages looks exactly
what I would consider a German "beverage shop" (Getränkemarkt) - it
sells already prepared and packaged drinks in bottles, cans, or jugs,
in a supermarket style where customers pick up their selection and
bring it to a cashier.

In a bubble tea place you place an order and it is prepared and served to you.

If a pharmacy is not a shop in OSM, neither should a bubble tea place.

--Jarek

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


Re: [Tagging] Automated edit of image tags suggestion

2020-06-25 Thread Jarek Piórkowski
On Thu, Jun 25, 2020, 15:19 Martin Koppenhoefer, 
wrote:

>
> there might be an issue with multiple images separated by ; because the
> semicolon does not have to be escaped in URLs. If the protocol is given
> every time it might still be ok? e.g.
> http://111.com/example1.jpg;http://111.com/example2.jpg would be
> unambiguous because you cannot have // in the middle of a filename, or can
> you?
>

You can have just about any character sequence in a url, particularly in
the query part - including two slashes in a row.
http://111.com/image_service?id=bla-$3_http://bla.com can be a valid image
url (if a confusing and unusual one)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-10 Thread Jarek Piórkowski
On Wed, 10 Jun 2020 at 13:40, Tod Fitch  wrote:
> My hope would be that addition of more highway=* values that better match 
> what people are trying to map would be a short term pain (data consumers need 
> to add one more check) but long term benefit.
>
> For example, as mappers discover they can map a voie verte in France or a 
> “Rails to Trails” in the USA as highway=greenway and not as arbitrary choice 
> of track, path, cycleway or bridle path differentiated by a bunch of 
> foot=designated, bicycle=designated, etc. tags they are likely to migrate to 
> the simpler tagging. At some time in the future data consumers could begin to 
> be more restrictive on their logic.

I'd support more highway=* values, but a "greenway" doesn't seem like
the best start to me.

A "rail trail" as I'm familiar with it in Ontario seems an actually
fairly good use of highway=path - a multi-purpose, multi-user way that
usually doesn't allow two-tracked vehicles that need road
registration. (ATVs might be okay but their legal status is often
unclear and enforcement is uneven.)
https://commons.wikimedia.org/wiki/File:Rail_trail_(17207255008).jpg
is probably a typical look, it seems to be
https://osm.org/way/56156607

Or am I misunderstanding? What in your mind would be the difference
between highway=greenway and highway=path?

I can accept that a "greenway" would be different from a "dangerous
path a non-advanced hiker can die on", but I would suggest to start by
splitting out the latter. (As done for example with via ferrata.)

And regarding other path types: what highway= tag would you suggest
for https://osm.org/way/236153221 (photo in linked Wikipedia article)?
To me, a "hiking trail" would be the closest description, but I'm not
experienced with scene lingo nor do I know what it would be in British
English.

--Jarek

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


Re: [Tagging] Do we map pedestrian crossings twice?

2020-06-10 Thread Jarek Piórkowski
On Wed, 10 Jun 2020 at 14:27, Clifford Snow  wrote:
> To help me understand, below are three schemes for crossings. Which one(s) 
> best describe your suggested way of mapping.
>
> ...
> 2. With no crossing ways, just a node on the highway to mark the type of 
> crossing https://mycloud.snowandsnow.us/index.php/s/4ad5wLzMNcE3sNo

Mateusz has already pointed this out, but just to reinforce, this
scheme would break pedestrian routing and require a wholesale rewrite
of all routers to be able to jump between nearby ways.

An analogy would be having a break in a minor road where it intersects
the roadway of a major road.

--Jarek

___
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-06-09 Thread Jarek Piórkowski
On Tue, 9 Jun 2020 at 07:56, Paul Allen  wrote:
> On Tue, 9 Jun 2020 at 04:08, Jarek Piórkowski  wrote:
>> Yet we wouldn't map Watling Street in OSM with a way tagged as
>> roman_road=demolished nor roman_road=razed nor roman_road=abandoned
>
> Nope.  We'd map the portions that are existing ways like this:
> https://www.openstreetmap.org/relation/7063236

Could we do similar with torn-up railways?

Then the parts where rails or railbed are actually remaining could be
railway=abandoned or whatever, and parts with nothing remaining could
be plain ways in a relation like https://osm.org/way/498608783

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


Re: [Tagging] Features underwater (inside reservoirs)

2020-06-08 Thread Jarek Piórkowski
On Mon, 8 Jun 2020 at 22:13, Warin <61sundow...@gmail.com> wrote:
> On 8/6/20 10:14 pm, Paul Allen wrote:
>> access=no
>> access:conditional=yes @ (above water)
>
> Conditional key does not look to have text base entry ... might be better to 
> use opening hours?
> opening_hours= "above water" ???

:conditional is widely used for mapping:
https://taginfo.openstreetmap.org/search?q=conditional

___
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-06-08 Thread Jarek Piórkowski
On Mon, 8 Jun 2020 at 13:51, Paul Allen  wrote:
> On Mon, 8 Jun 2020 at 15:40, Mateusz Konieczny via Tagging 
>  wrote:
>>   cycleway route is verifiable, but route took by army is not)
>
> Quite a few motor roads in the UK follow those "unverifiable" routes.  Some
> are even named after those routes.  
> https://en.wikipedia.org/wiki/Watling_Street

Yet we wouldn't map Watling Street in OSM with a way tagged as
roman_road=demolished nor roman_road=razed nor roman_road=abandoned

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


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-06-07 Thread Jarek Piórkowski
On Sun, 7 Jun 2020 at 19:17, Warin <61sundow...@gmail.com> wrote:
> As for tagging 'dangerous areas' .. areas that pose danger such as some 
> favelas cannot be tagged in OSM. I see the same logic applied to dangerous 
> areas caused by wildlife.

Big difficulty in defining where to place cut-off for dangerous and
when an area is dangerous... Ultimately most of the world has some
dangerous wildlife. If very unlucky you could be gored by a boar
within city limits of Berlin. Bears are semi-regularly found in some
suburbs of Vancouver. Where would you draw the line?

--Jarek

___
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-06-07 Thread Jarek Piórkowski
On Sun, 7 Jun 2020 at 17:36, Martin Koppenhoefer  wrote:
> > On 6. Jun 2020, at 00:04, Volker Schmidt  wrote:
> > I do object strongly to the invitation to remove the 
> > razed/dismantled-railway tag in the case of railway tracks have been 
> > replaced by roads with the same geometry.
>
> +1

Do you also object when the geometry of the railway and the road is a
straight line? Do you think we should keep
https://www.openstreetmap.org/way/676191068 ?

___
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-06-06 Thread Jarek Piórkowski
On Sat, 6 Jun 2020 at 11:23, Andy Townsend  wrote:
> On 06/06/2020 16:18, Phake Nick wrote:
> 在 2020年6月6日週六 11:03,Warin <61sundow...@gmail.com> 寫道:
>>> As a general tourist I would have no interest in traveling along a
>>> railway route here nothing remains of the railway.
>>
>> OSM is not *only* for general tourist.
>
> I bet even a general tourist would be interested if they could be assured 
> that a route was flat :)

And didn't have buildings or factories built on it ;)

If it's a recognized route that's signposted as something like
"Historical Railway Trail" then it can be a relation. If it's not
signposted and there's no trace of it left on the ground, what exactly
is being mapped?

--Jarek

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


Re: [Tagging] Adding man_made=spoil_heap to the Map Features page?

2020-06-03 Thread Jarek Piórkowski
On Wed, 3 Jun 2020 at 20:40, Mateusz Konieczny via Tagging
 wrote:
(about Map Features wiki page)
> In its current state it is still barely usable.

Personally I've given up on the current Map Features page and would
rather use the wiki search or taginfo search than wait for it to load
and probably still not find what I'm actually looking for.

--Jarek

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


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-06-02 Thread Jarek Piórkowski
On Tue, 2 Jun 2020 at 10:52, Tod Fitch  wrote:
> On Jun 2, 2020, at 5:48 AM, Volker Schmidt  wrote:
>> On Tue, 2 Jun 2020 at 09:04, Daniel Westergren  wrote:
>>> Right. But is there another way? Can we tag dirt paths/wilderness 
>>> paths/forest paths/mountain paths with another main tag?

Certainly you can use highway=not_an_easy_walk (or a better
alternative). There's a post upthread (or in a similar thread
somewhere?) about an editor in a mountainous area explicitly changing
tagging away from highway=path to try to avoid casual hikers getting
in situations where they need rescue. You can use any tags you like in
OSM. The hard part is if you want to get consensus on what tags to
recommend.

>> No you cannot inroduce another main tag, because of the existing stock of 
>> "path" 8.7 million and "track".(18.7 million). This would only add 
>> additional confusion with mappers and an enormous burden on renderers and 
>> routers
>>
>>> Can we somehow "enforce" additional tags for physical characteristics that 
>>> will tell what this path|footway|cycleway actually looks like?
>
>> We have no way to "enforce" anything in OSM. But, as we do have the 
>> necessary tags (maybe to many different ones, but they all are in use.and we 
>> need to reamin backaward compatible in view of the enourmous numbers). What 
>> we can do and need to do is to improve the description of the various 
>> existing tagging options in the wiki (without touching their definition)
>
> My translation of these two statements combined is roughy: “We can’t change 
> any tagging”. I don’t find that helpful.

I find that realistic. Consider two big "let's fix up tagging for
this" initiatives in OSM: public_transport=* and healthcare=*.
Healthcare is only recently getting accepted and there is no consensus
to expand its use (see healthcare=pharmacy getting explicitly
_deprecated_), and public_transport=* is still not rendered on
osm-carto after almost a decade.

You can change tagging. But you can't force the rest of the OSM
ecosystem to start using your new tags.


--Jarek

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


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-05-31 Thread Jarek Piórkowski
On Sun, 31 May 2020 at 03:16, Daniel Westergren  wrote:
> Ok, two things.
>
> Function vs physical characteristics
> First, I've increasingly realized what's probably at the heart of this 12+ 
> years discussion, the enormous problem of interpreting 
> highway=path|footway|cycleway (just like is currently being discussed about 
> highway=track) in two entirely conflicting ways, as someone has mentioned, 
> function VS physical characteristics.

As I recall, a long time ago this thread started off with the concern
"people from the city might die on this hiking trail". Is that a
function or a physical characteristic?

>2. the default OSM rendering not considering physical characteristics 
>(particularly for non-urban ways) ...

I am not clear on the definition of "urban" you use. I notice you also
used this word in the doc you've written up (thank you!). Are my
examples "urban"? They're well within city borders, near to urban
areas, but they're not like a sidewalk. At what point do we cross from
a city park pathway to a non-urban way?

--Jarek

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


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-05-30 Thread Jarek Piórkowski
On Sat, 30 May 2020 at 20:13, Tod Fitch  wrote:
> I’ve spent too much time recently trying to figure out how to better 
> determine whether the ways I am rendering should be shown as an 
> urban/suburban walkway versus a non-urban hiking trail (intentionally not 
> using “footway” and “path” as words for this).

I realize this might not apply to your map, but just to give people
discussing path/trail semantics another data point:
urban ravine/hillside areas like
https://www.mapillary.com/map/im/pcIl9nspFIi38uEDY5q_OA (this one is
300 m from a normal low-density neighbourhood) or
https://www.mapillary.com/map/im/hHkS__YTVtqWYcg-l4kMGQ (this is up to
1 km walk in any direction from a "normal" urban street with a
sidewalk) or https://www.mapillary.com/map/im/rjjuiRG0giyX_kufNrX_mA
(300 m from a normal mid-density neighbourhood)

--Jarek

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


[Tagging] taxi included in psv? (was: Access tag abuse examples)

2020-05-25 Thread Jarek Piórkowski
On Mon, 25 May 2020 at 09:29, Mateusz Konieczny via Tagging
 wrote:
>> Is meaning of psv=* territory dependent? I don't get that impression
>> from the wiki, and was under the impression it was to include taxis
>> worldwide. Please tell me if I had that wrong.
>
> I though that the point of that tag was that it follows local legislation.
>
> So if I have signs "public services vehicles are allowed" or
> "pojazdy transportu bublicznego" and government will change
> what counts as "public service vehicle"
>  (fox example - minimum number of seats / includes excludes horse-drawn
> carriages, excludes taxi vehicles that are not passing pollution 
> requirements...)
> there is no need to retweak bizarrely complicated conditional restrictions.

Could we change the wiki then? Because that's now how I interpret the
indented list on https://wiki.openstreetmap.org/wiki/Key:access, where
taxi is under psv, and while bus has a disclaimer "acting as a public
service vehicle", taxi has no such disclaimer.

https://wiki.openstreetmap.org/wiki/Key:psv is also IMO unclear
whether or not it includes taxi - up top it says "vehicles used in a
passenger service (no matter how many seating positions they might
have)" and taxi below - with no mention of local laws. Only in the
"See also" section it includes taxi again saying "taxi, which may or
may not be considered public service vehicles depending on location"

I ask because in my local jurisdiction, unlike in the UK, public
transit bus exceptions do not usually apply to taxis, and based on my
understanding of the wiki pages I've been changing psv to bus in those
cases when I see it. Which is correct?

--Jarek

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


Re: [Tagging] Access tag abuse examples

2020-05-25 Thread Jarek Piórkowski
On Mon, 25 May 2020 at 07:22, Mateusz Konieczny via Tagging
 wrote:
> May 25, 2020, 11:06 by colin.sm...@xs4all.nl:
>> Is there a uniform definition of "motor_vehicle" in terms of its constituent 
>> vehicle classes? Do the constituent classes also have a uniform definition? 
>> A problematic example is "psv" where its status is not simply a function of 
>> the vehicle's construction or taxation class, but also of the use to which 
>> it is being put. If a taxi driver takes his taxi on holiday? A bus running 
>> empty back to the depot?
>
> And that is why psv is useful. Lets say that in given territory it applies to 
> bus on route with public
> and scheduled traffic and it does not apply to bus running service that is 
> not accessible to public.

Is meaning of psv=* territory dependent? I don't get that impression
from the wiki, and was under the impression it was to include taxis
worldwide. Please tell me if I had that wrong.

--Jarek

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


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

2020-05-24 Thread Jarek Piórkowski
On Sun, 24 May 2020 at 17:42, Volker Schmidt  wrote:
> 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

How are these ways tagged currently - highway=path? footway?
pedestrian? What is the default bicycle access if no tag is present?

> - plenty of service roads which show the "no transit for any vehicle" sign, 
> 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.

This gets tricky. To give an obvious example, if vast majority of
drivers exceeds a posted speed limit and a driver would never get
pulled over for going anything less than 15 km/h above posted speed
limit, what if anything should we tag for maxspeed=*?

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


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-22 Thread Jarek Piórkowski
On Fri, 22 May 2020 at 11:25, Andy Townsend  wrote:
> ... it's hugely biased towards urban centres.
> Looking at https://www.openstreetmap.org/#map=13/53.9023/-0.8856 you
> can't see any paths at all at that zoom level due to the "Central
> European Graveyard problem" - compare with
> https://map.atownsend.org.uk/maps/map/map.html#zoom=13=53.9006=-0.8795
> to see what you're missing.

See also: not rendering roads or hamlets in very sparsely populated
areas because we have one map style which needs to accommodate central
European densities.

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


Re: [Tagging] Adding values healthcare=dispensary and healthcare=community_care?

2020-05-19 Thread Jarek Piórkowski
On Tue, 19 May 2020 at 21:18, Graeme Fitzpatrick  wrote:
> How about =nurse / nurses / nursing_station, & =community_health_service?

Nursing station to my Canadian ears sounds like where you breastfeed
your child. https://en.wiktionary.org/wiki/nursing seems to agree.
Just 2 cents

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-11 Thread Jarek Piórkowski
On Mon, 11 May 2020 at 11:25, Joseph Eisenberg
 wrote:
> If you arrive at the airport in Bali with your in-laws, and look on Maps.me 
> for the closest taxi stand and walk over to it, you will be quite 
> disappointed to find a line of motorcycles, and have to walk back to the 
> other side of the airport to get a cab at the real taxi stand.
>
> This is not a problem in your country, because you only have taxicab stands. 
> It will not affect you personally, unless you travel to Asia or Africa etc.

In short, is this tag "tagging for the tourist"? Those in the know
will know to check if it's a motorcycle taxi or a car taxi stand.

Or is it "tagging for Maps.me", which might not be adapted to
differently render amenity=taxi + taxi=motorcycle_taxi on short
notice? Luckily they do change rendering for some subtags:
amenity=parking + access=private; or railway=station + wheelchair=*.

(And what about water taxis at Malé airport?)

--Jarek

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-10 Thread Jarek Piórkowski
On Sun, 10 May 2020 at 21:04, Phake Nick  wrote:
> I am more thinking about analysis of geographical data of cities or districts 
> where taxi and motorcycle taxi would be two very different things to be 
> managed.

If you are managing taxis and motorcycle taxis then surely you know
you have to check which is which. Which tag is used to check for them
is immaterial.

Similarly if you were doing an analysis of surface area devoted to
public parking then you also need to know to check for
access!=private. If you're doing an analysis of mobility options then
you need to know to check for wheelchair tag, etc.

The only advantage of a separate top-level amenity=motorcycle_taxi tag
is that it won't show up for people who don't know the difference. But
if they don't know the difference, they're likely in an area where
motorcycle taxis don't exist.

This is going around in circles. I hope whoever wanted more discussion
before voting is satisfied ;)

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-10 Thread Jarek Piórkowski
On Sun, 10 May 2020 at 18:35, Phake Nick  wrote:
> At the end of the day we are not taking motorcycle taxi and taxi themselves. 
> What's being tagged are waiting area for taxi or motorcycle taxis. What 
> matters is that, if one is created as an optional subtag of another, would 
> not using such subtag result in incorrect analysis of data when someone use 
> those data, and the answer seems to me as yes.

Depends what question you're asking in the analysis, surely.

If your question is "where can get a ride" then the results won't be wrong.

If your question is "where can get a ride in an enclosed two-track
vehicle" then the results would be wrong in Indonesia. But if you're
asking that in Indonesia, you're probably also aware of the variety of
local modes of transportation and realize that you should ask a more
specific question.

You could make a similar argument for other amenities.
For example, if you're looking for a parking spot, and if your region
some parking lots are private, you need to take that into account when
doing the analysis.
If you are looking for a rapid transit station and you're in a
wheelchair, and in your area not all stations are accessible, you need
to take that into account when doing the search. This might not occur
to someone from an area where all stations are accessible, so should
we have a railway=inaccessible_station rather than wheelchair=no to
prevent incorrect analysis?

To me, this argument goes back to the same question of whether an
amenity=taxi is where you hire a ride, or where you hire a ride in an
enclosed vehicle that can fit 2+ passengers and probably a bit of
luggage.

--Jarek

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-09 Thread Jarek Piórkowski
On Sat, 9 May 2020 at 19:33, Paul Allen  wrote:
> On Sun, 10 May 2020 at 00:25, Martin Koppenhoefer  
> wrote:
>> imagine you are ordering a taxi for yourself and 2 colleagues to the airport 
>> and instead of a taxi (cab) they send you 3 taxi moto. Would that be equally 
>> ok, wouldn’t it matter, taxi is taxi?
>
> It would matter a hell of a lot if one or more of use were carrying an item of
> heavy luggage.

In that case you should probably order a taxi for 3 people and heavy
luggage. What if they sent a Matiz as a taxi?
https://www.flickr.com/photos/takeshicollection/4329846559

For that matter, many sedans won't fit 3 guests with 3
airplane-checked-luggage size suitcases.

There's always amenity=baggage_taxi ;)

--Jarek

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-08 Thread Jarek Piórkowski
On Fri, 8 May 2020 at 09:05, Phake Nick  wrote:
> On 2020-05-08 Fri 20:45, Jarek Piórkowski  wrote:
>> How much discussion do you think should be necessary before voting "I
>> oppose, because I think using sub-tags is better"? If someone thinks
>> that, they think that. A discussion would just print the arguments
>> back and forth.
>
> Given the proportion of opposing comment being raised, I would say "more than 
> what have been discussed", as barely anyone raised the point during the 
> discussion. The only two remotely relevant mentions about it during the 
> discussion process was 1. one user who think there should be a new parents 
> tag that cover both regular taxi and motorcycle taxi, and 2. another who 
> incorrectly assuned "motorcycle taxi" is a combination of two different 
> features just because the term come with a space. That clearly indicate 
> discussion was not sufficient and that the proposal should restart the 
> discussion process.

I'm assuming you mean the following messages in the February thread?
1. https://lists.openstreetmap.org/pipermail/tagging/2020-February/051244.html
2. https://lists.openstreetmap.org/pipermail/tagging/2020-February/051250.html

Do you expect others who agree with already-stated positions to write
in with a copy?

More widely, it is my impression that "refining with sub-tags vs
creating new tags" has been a culture conflict in OSM since long
before I became active. (I'm just waiting for the fireworks when
someone suggests public_transport=platform + motorcycle=yes)

These objections are not new. You might not agree with them, but their
existence should not surprise you. ¯\_(ツ)_/¯

--Jarek

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-08 Thread Jarek Piórkowski
On Fri, 8 May 2020 at 18:30, Joseph Eisenberg
 wrote:
> > (especially those approved after, say, 2012)
>
> The proposal process became more difficult after March 2015, when the 
> standard for approval was changed from >50% to >74%:
>
> https://wiki.openstreetmap.org/w/index.php?title=Proposal_process=revision=1150734=1143140
>
> This has been helpful in preventing bad ideas from being approved without 
> consensus.
>
> But it has made it more likely that a proposal will not be approved, even 
> though the majority accepts it.

Ah yes, that sounds about right. I added the classifier because I
recall some early proposals, 2008 or 2009 or so, being pretty
barebone, and wanted to separate those from the current status.

--Jarek

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-08 Thread Jarek Piórkowski
On Fri, 8 May 2020 at 09:05, s8evq  wrote:
> On Fri, 8 May 2020 08:43:27 -0400, Jarek Piórkowski  
> wrote:
> > How much discussion do you think should be necessary before voting "I
> > oppose, because I think using sub-tags is better"? If someone thinks
> > that, they think that. A discussion would just print the arguments
> > back and forth.
>
> If these arguments were given beforehand, perhaps the proposal could have 
> changed, or opinions could have been changed?

Honestly - I remember following the discussion on this mailing list
for a while and my impression was that the arguments _were_ given.
These arguments are not a surprise. Here's a version of this exact
argument in February:
https://lists.openstreetmap.org/pipermail/tagging/2020-February/051250.html

Subsequent discussion here is an example of what happened. Some
people, _after having read the rationale offered_, think that a
separate tag is not warranted. Some people think that it is. You won't
win an argument by telling others they're wrong.

> I hardly have any experience in proposals and the voting system. But I've 
> seen 3 proposal so far, where I know the author doesn't want to bring it to 
> vote, fearing the proposal would be rejected. The rationale behind it: status 
> Rejected is worse than having the proposal in the "Draft" state forever.
>
> And then some people in this very thread suggest to just ignore a rejection 
> and start using it anyway. What's the use of the whole voting system then? 
> Why even bother writing a proposal in the first place? I'll just do whatever.

Yeah I understand. I myself rejected Joseph's suggestion to make a tag
I used locally and documented on wiki into a "proposal", because I
don't want the hassle.

My interpretation is that "approved" is a _lot_ higher status than "in
use", precisely because how harsh the proposal process is. That's just
I see it being in OSM - you can have in-use tags, locally-accepted
tags, and then the "approved" tags are really really accepted
(especially those approved after, say, 2012).

Failing a proposal isn't a bad thing. Tag what you like. (With some
exceptions, like straight-up vandalism or trolltags)

--Jarek

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


Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

2020-05-08 Thread Jarek Piórkowski
On Fri, 8 May 2020 at 02:27, s8evq  wrote:
>
> Of the 8 opposing votes, only 1 has made the effort to comment beforehand on 
> the talk page. The 7 others just came in and voted no, without any discussion 
> beforehand. That doesn't seem correct. It should not be possible to be 
> suddenly faced with this fait accompli.

Hm, I'm not seeing that requirement on
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting

In fact all the opposing votes made comments as to why they oppose it.
You may disagree with their reasons but that doesn't make them
invalid.

How much discussion do you think should be necessary before voting "I
oppose, because I think using sub-tags is better"? If someone thinks
that, they think that. A discussion would just print the arguments
back and forth.

--Jarek

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


Re: [Tagging] RFC ele:regional

2020-05-03 Thread Jarek Piórkowski
On Sun, 3 May 2020 at 08:16, Martin Koppenhoefer  wrote:
> > On 3. May 2020, at 13:06, Volker Schmidt  wrote:
> > When I see an elevation value on the ground I do not see any reference to 
> > the reference system, so I cannot know, as a mapper, what reference system 
> > is at the base of the informaton that I find on the ground. In that respect 
> > the proposal is not at all  from a practical perspective
>
> the idea is you do not even have to know, simply copy the value from the sign.

What happens when the sign is replaced or removed?

You might want to change the wiki description to be much more explicit
that this is only what is given on a sign and not a "regionally common
reference system".

--Jarek

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


Re: [Tagging] How to tag way with two traffic signs affecting different directions?

2020-05-02 Thread Jarek Piórkowski
On Sat, 2 May 2020 at 16:21, António Madeira  wrote:
> I'm not very knowledgable about relations, and I'm sorry if I'm a bit 
> confused here, but doesn't a restriction relation means the exact opposite of 
> what's intended here?
> I mean, I want to apply a STOP sign to a given lane (in a way with two lanes, 
> for example) and force its action to a given direction on the new road ahead.

IMO, a relation helps here because you can define the route which the
rule applies to - it only applies going "from" a certain way and "to"
a certain way, and specifically applies at a given "position".

Then it is just a matter of choosing what type of relation works best,
or creating a new type.

> If neither relation scheme (enforcement or restriction) can be applied here 
> (for complexity or incompatibility reasons), why not use the existing lanes 
> scheme?
> Like this:
>
> highway=stop
> stop:lanes=yes|no
> stop:turn:lanes=left

Personally I've always seen highway=stop on a node, and I'm not sure
:lanes tagging makes sense on a node (a point doesn't have lanes).
You'd definitely need to add at least direction=forward/backward if
tagging a node. But I wouldn't be opposed to that scheme in general.

--Jarek

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


Re: [Tagging] How to tag way with two traffic signs affecting different directions?

2020-05-02 Thread Jarek Piórkowski
Phil, the question appears to be for different signs/rules for
different lanes/turns but in the same direction.

António, interesting question. In my interpretation, relation
type=enforcement seems to be intended for recording or punishing
violations of rules (wiki "devices that measure and document traffic
violations") - not for the restrictive rules themselves.

Instead, maybe type=restriction + restriction=stop, with
from-to-via-position? It's not widely used, but it does have a couple
of mappers: https://taginfo.openstreetmap.org/tags/restriction=stop

Possible examples:
https://www.openstreetmap.org/relation/3884744 except with "to" as a
way rather than node
https://www.openstreetmap.org/relation/2966044 except probably with
the to-way split at the intersection

traffic_sign:lanes looks like it would also work, and the existing
examples seem a bit more fleshed out than for restriction=stop -
depends if you prefer :lanes tags or relations, I suppose.

--Jarek


On Sat, 2 May 2020 at 14:36, Philip Barnes  wrote:
>
> Hi António
> Normally I would add direction:forward or direction:backward to a stop or 
> give_way to indicate which direction it applies in.
>
> Where speed limits are different you can use maxspeed:backward and 
> maxspeed:forward.
>
> Phil (trigpoint)
>
>
> On Sat, 2020-05-02 at 15:16 -0300, António Madeira wrote:
>
> Hi there.
> Following this topic, I would like to extend the discussion to the mail list, 
> because I think this is an important issue that should have a broad solution.
> https://forum.openstreetmap.org/viewtopic.php?id=69011
>
>
> Several months ago, I stumbled upon a problem which I found no solution to. 
> At the time, I searched for help in the Telegram channel and someone gave me 
> a solution that I've been using since then.
> Meanwhile, another mapper contacted me in private and told me about another 
> kind of solution to this problem.
> I would like to know if these are both valid and/or which one is more useful 
> for routing.
>
> I'm showing here illustrations of the problem and the two solutions given.
>
>
> Problem #1:
> https://i.imgur.com/8MiiKFH.png
>
> The selected way has a STOP at the end for those who turn left and a give way 
> sign for those who turn right.
> The "problem" is: how to map those two signs correctly and make them useful 
> for routing software?
>
> Problem #2:
> https://i.imgur.com/cLFRtLG.png
>
> There are no painted islands and no physical divisions. The middle lane as a 
> STOP sign to turn left.
>
> If you have
> lanes=3;
> lanes:forward=1;
> lanes:backward=2;
> turn:lanes:backward=left|through
>
> how do you indicate that there's a STOP on one of them?
>
>
>
>
> Solution #1:
> https://i.imgur.com/HDmvZiB.png
>
> Use both traffic signs on the way and create one enforcement relation for 
> each of them. A "from" enforcement on the STOP and a "to" on the left segment 
> of "Rua Paulo VI" and a "from" enforcement on the give way and a "to" on the 
> right segment of "Rua Paulo VI".
>
>
> Solution #2:
> Just use the following tags:
> highway=secondary
> lanes=2
> oneway=yes
> name=Rua da Quinta
> ref=EN 350
> surface=asphalt
> traffic_sign:lanes=stop|give_way
> turn:lanes:forward=left|right
>
> I never used traffic_sign:lanes tag, but it seems legit, although Taginfo 
> only shows 20 uses for this:
> https://taginfo.openstreetmap.org/search?q=traffic_sign%3Alanes
>
>
> Any considerations would be much appreciated.
>
> Regards.
>
> ___
>
> Tagging mailing list
>
> Tagging@openstreetmap.org
>
>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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


Re: [Tagging] Footways where pedestrians may only walk in one direction: oneway:foot=yes or foot:backward=no?

2020-04-16 Thread Jarek Piórkowski

On 15/04/2020 23:03, Joseph Eisenberg wrote:

Some paths and footways have oneway=yes. Sometimes this means that
bicycles may only access these features in one direction, but other
times it has been used for one-way features for pedestrians (for
example, queues in theme parks or at border control stations).


Just to refresh people's memory, this was previously discussed in January

https://lists.openstreetmap.org/pipermail/tagging/2020-January/050115.html

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


Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

2020-04-15 Thread Jarek Piórkowski

On 15/04/2020 09:27, John Willis via Tagging wrote:

On Apr 15, 2020, at 8:34 PM, Paul Allen wrote:
The traffic lights control the junction


We have a lot of traffic light controlled crossings in Japan that are 
just for a crosswalk, while the smaller intersecting road is stop-sign 
controlled for cars. Only the crosswalk is controlled by a signal that 
stops traffic on the larger road - only when pressed. There are many of 
these.


https://www.openstreetmap.org/way/790227211
https://www.openstreetmap.org/way/729071392


Oh! Those also exist (or at least existed a couple of years ago) in
British Columbia, they had a special flashing-green indication on the
main street.

Example https://www.mapillary.com/map/im/naoPubCHkocvtwgoZ2VcAA (note
the lack of lights controlling the minor cross street - the cross 
streets have only a stop sign - and the lights look out in that photo 
because it's on the off-phase of its flashing).


I don't know if there is a set tagging standard for them, I'm not
finding anything specific in quick checks of Vancouver east side
intersections right now.

To my eyes they would be:

- if a single node on the main street: highway=traffic_signals +
crossing=traffic_signals + button_operated=yes, but this doesn't
indicate that the minor cross street traffic is not controlled by the
light
- if the crossing is only on one side of the intersection, as shown in
the Japanese examples: highway=traffic_signals +
crossing=traffic_signals + button_operated=yes at the crossing node(s)
- if the car stop lines are on either side of the minor street
intersection, using more nodes: on the main street, at car stop lines,
highway=traffic_signals + direction=*; on the main car way, at
crosswalk locations highway=crossing + crossing=traffic_signals; on
the minor cross street, at the stop line, highway=stop + direction=*;
and no highway=traffic_signals on the intersection node between the
two streets

- crosswalks for traffic signal controlled intersections where the light 
is _only_ sensor triggered - magnet loop in the road and a push-button 
for pedestrians. there are very few of these. a little sign says “push 
button” - and if you don’t press it, you will wait until a car comes.

Isn't that simply button_operated=yes ?

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

2020-04-15 Thread Jarek Piórkowski

On 15/04/2020 05:33, lukas-...@web.de wrote:
Okay, so this is what I think, too and maybe I would clarify this in the 
wiki then.
But I think in some cases it still wouldn't be clear, because what would 
be about mapping this then:

https://www.google.co.uk/maps/@52.0898304,-4.6450624,3a,75y,122.71h,87.75t/data=!3m6!1e1!3m4!1s18sOSZsN3ir-fxX3UU5JLg!2e0!7i13312!8i6656
Which was mentioned a few posts before? The traffic lights control the 
junction, but people might say that the same one single traffic light is 
controlling the pedestrian crossing and the junction...


To be honest this looks like a normal intersection to my Canadian
eyes. I guess the difference is that there is no pedestrian crossing
of the main road? But that can indicated with lack of footway=crossing
ways if pedestrian ways are mapped, and crossing=no on main
intersection nodes if not.

To me it is not super relevant to the main tag whether the light is
activated by a timer, a waiting car, or a pedestrian pressing the
button. And in any case, for the pedestrian button we have
button_operated=yes

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

2020-04-14 Thread Jarek Piórkowski
On Tue, 14 Apr 2020 at 10:00,  wrote:
> So in which cases "highway=traffic_signals + crossing=traffic_signals on the 
> same node" should be used? Only for the "crossing only-traffic lights" I 
> mentioned?

Yeah, personally I would agree with that. Only on
pedestrian/cycle-crossing-only traffic lights.
https://www.openstreetmap.org/node/2771622922 as an example.

I think that if you're going to the extent of mapping separate stop
lines on all ways leading into the intersection, you can also separate
the car stop line node from the pedestrian crossing node. (And if
you're not, highway=traffic_signals on the main intersection node
still works.) So don't use highway=traffic_signals +
crossing=traffic_signals, except for a pedestrian-crossing-only light.

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

2020-04-14 Thread Jarek Piórkowski
On Tue, 14 Apr 2020 at 06:23,  wrote:
>
> To response on the mentioning:
> "Currently the wiki page says "traffic_signals=crossing_on_demand makes
> it easy to mark all traffic lights which do only control a crossing",
> again I personally find highway=traffic_signals +
> crossing=traffic_signals sufficient for that"
>
> Yes, that's true. I agree with that, but my point is, that not only those 
> traffic lights, which do control only a crossing, a mapped like this. Mappers 
> use it just as a shortcut for traffic light and crossing, no matter in which 
> relation between each other they are. That is not wrong, but it does not 
> really show for what the lane traffic lights are "resposible". Please have a 
> look at https://www.openstreetmap.org/node/1339612951 and many many others in 
> this city. The traffic lights of course control the crossing, yes, but they 
> control the junction nearby, too.
> So looking at highway=traffic_signals + crossing=traffic_signals on the same 
> node also makes it not possible to see only those crossings where n junction 
> or something else is, as I see it at the moment.

Hm, that's tagging I haven't seen before. My suggestion would be to
not tag like that (the proposed new tag would suggest retagging of
this anyway). My understanding of the detailed-intersection-tagging
norms was that this should have highway=traffic_signals on the stop
line for cars, and highway=crossing+crossing=traffic_signals on the
middle of the pedestrian crossing - e.g.
https://www.openstreetmap.org/node/1822620449 or
https://www.openstreetmap.org/node/393547028

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

2020-04-13 Thread Jarek Piórkowski
On Mon, 13 Apr 2020 at 12:56, Paul Allen  wrote:
> On Mon, 13 Apr 2020 at 17:43,  wrote:
>> The second goal my proposal wants to message is to deprecate tagging 
>> "crossing=traffic_signals" together with "highway=traffic_signals" on the 
>> same node. Especially if you're saying this is a full crossing mapped. It 
>> breaks the highway=crossing - tagging scheme we use for all other types of 
>> crossing (except crossing=no). Some mappers use "crossing=traffic_signals" 
>> together with "highway=traffic_signals" on the same node als a shortcut for 
>> "lane traffic signal" and "foot traffic signal" because it is rendered as 
>> two traffic signals in JOSM. Or for mapping traffic signals for crossing 
>> cyclists. But I think in every case it is better to use two different 
>> (nearby) nodes for that.
>
> Am I misunderstanding you?  You propose using two nearby nodes for
> https://goo.gl/maps/3Sg5ndQ2ZCMBN9uy9  You can just see the yellow
> pedestrian-control box at the left.  It controls the crossing (marked with 
> studs)
> going from left to right across the picture.  The same lights that tell 
> motorists
> to stop for pedestrians also control traffic flow at the T junction ahead.  
> The
> same set of lights is both a highway traffic signal and a crossing traffic 
> signal.
> This sort of thing is not uncommon in the UK, with the same set of lights
> being used for both purposes.

My understanding was that traffic signals=crossing on demand is meant
for things like https://www.openstreetmap.org/node/2771622922 (
https://www.mapillary.com/map/im/2oyFQXVHvy2r-XypCZTECg ) however I
might be wrong? Or https://www.openstreetmap.org/node/1416834957 (
https://www.mapillary.com/map/im/DkuEFqSbOuQPGMtABsFFCA ) including
cyclists? (Esri is good for satellite imagery of these)

Personally I find highway=traffic_signals + crossing=traffic_signals
on one node sufficient for these crossings.

Currently the wiki page says "traffic_signals=crossing_on_demand makes
it easy to mark all traffic lights which do only control a crossing",
again I personally find highway=traffic_signals +
crossing=traffic_signals sufficient for that - maybe I'm missing
something. Of course any new tags can be proposed. But I would suggest
adding some real-world photos of crossings that would be tagged with
crossing_on_demand to the wiki page.

--Jarek

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


Re: [Tagging] Can highway=cycleway be limited to MTB?

2020-04-02 Thread Jarek Piórkowski
On Thu, 2 Apr 2020 at 07:40, Snusmumriken
 wrote:
> On Thu, 2020-04-02 at 22:24 +1100, Andrew Harvey wrote:
> > just usually only a certain kind of bicycle.
>
> Well, that's the problem, if one can't travel on a certain way with a
> general purpose bicycle, then it shouldn't be tagged highway=cycleway

Isn't this a similar situation as highway=unclassified + 4wd_only=yes?
That's voted-and-approved, although from 2009.

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-11 Thread Jarek Piórkowski
On Wed, 11 Mar 2020 at 23:09, Joseph Eisenberg
 wrote:
> >  In inclement weather, passengers may well be found waiting in
> the transit shelter 8 metres to west, and the tram will stop for them
> if they are waiting in the shelter. It might also stop if you are
> waiting a little bit beyond the shelter
>
> In this case it sounds like the tram operators are allowed to stop in
> several different places.
>
> I would pick the place where the tram normally stops: either at the
> sign or the location of the shelter, depending on the standard
> practice in the local area. Either way, tram riders will be directed
> to the correct location by routing apps: an 8 meter difference is not
> significant.

But why pick one and not the other? Only for the sake of having one
point rather than two in a database? Especially in this case where
they can be fairly reasonably described as "stop position" (the sign)
and "waiting area" (the shelter).

> >  Berlin mapping of streetside tram stops like 
> > https://www.openstreetmap.org/way/389400777
>
> I have not visited that location in person, and the aerial imagery is
> not high enough resolution to see if there is a separate platform, so
> it is hard for me to say.
>
> The "gold standard" is survey: visiting the stop in location (and
> riding the tram perhaps)
>
> Do you know if the "platform" here is separate from the sidewalk in
> some way? It should either be a different height, or a different
> surface, or at least marked with a painted / thermoplastic line.
> Otherwise the length of this "platform" way would be arbitrary: why
> not include the whole block?

In this particular case, there is not a platform that can be
distinguished - it's a curbside stop. The length of the "platform" way
appears to roughly match the length of the vehicles and thus the area
where the vehicles can be boarded (all-door boarding is in effect).
Berlin doesn't have many curbside stops but where they do exist, this
seems to be the prevailing local tagging.

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-11 Thread Jarek Piórkowski
On Wed, 11 Mar 2020 at 22:22, Joseph Eisenberg
 wrote:
> > I am thinking of cases like streetside stops for 30 m or 45 m long
> trams. There might be a shelter, which is the most prominent physical
> feature of the tram stop. There is no explicit platform. The tram stop
> sign might be 10 metres away from the shelter, and the farthest
> possible boarding point at the back doors of the tram another 10 m
> away. If only a single node could be used, where is it placed and why?
>
> How are you currently mapping such tram stops?
>
> I would indicate the point where passengers wait for the tram, near
> the front door, which is usually where the sign is located.
>
> But it needs to be verifiable: if another mapper rides the tram, they
> should be able to understand why the stop is at that location.

To give a real-world example:
https://www.openstreetmap.org/node/362413 (Esri has the best
aerial imagery in this area) is placed where the sign for the stop is
located. In inclement weather, passengers may well be found waiting in
the transit shelter 8 metres to west, and the tram will stop for them
if they are waiting in the shelter. It might also stop if you are
waiting a little bit beyond the shelter. Exact stopping location can
vary a couple of metres from operator to operator. Where would you
place the one true node?

> If you map anything as an area, there needs to be a real-world feature
> that matches that area.

What do you think about the Berlin mapping of streetside tram stops
like https://www.openstreetmap.org/way/389400777 - as a linear way
matching the stretch of the sidewalk where passengers might wait?

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-11 Thread Jarek Piórkowski
On Wed, 11 Mar 2020 at 08:12, Jo  wrote:
> That stop_position nodes became optional is probably because of my influence. 
> In the beginning they were definitely part of how PTv2. I disliked this very 
> much because all of a sudden we were using 2 objects to define a single stop, 
> duplicating details, which seemed like a very bad idea. And it was.
>
> About the stops, I would have all the details on a single node, 
> highway=bus_stop, railway=tram_stop next to the road where the passengers 
> wait. If there is a physical platform, I would add a way highway=platform, 
> railway=platform. This way would only have tags describing the attributes of 
> the platform like wheelchair and tactile_paving.

Would this be mandatory?

I am thinking of cases like streetside stops for 30 m or 45 m long
trams. There might be a shelter, which is the most prominent physical
feature of the tram stop. There is no explicit platform. The tram stop
sign might be 10 metres away from the shelter, and the farthest
possible boarding point at the back doors of the tram another 10 m
away. If only a single node could be used, where is it placed and why?

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread Jarek Piórkowski
On Mon, 9 Mar 2020 at 13:07, Dave F via Tagging
 wrote:
> On 09/03/2020 13:21, Jarek Piórkowski wrote:
> > PTv2 is fine for people who want to handle routes that have variants
> > and branches and who want computer validators to be able to spot
> > potential errors in these branches.
>
> I'm intrigued: What Ptv2 tags enable those?

Separate relations per each route variant - verifying that the highway
ways are continuous in the relation.

Or are you suggesting to adopt the PTv2 one-relation-per-trip-variant
scheme without using public_transport=* tags? Feel free, as far as I
can tell JOSM PT plugin doesn't even complain about that. Just don't
be surprised if iD "upgrades" your tags after.

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - Public Transport v3

2020-03-09 Thread Jarek Piórkowski
On Mon, 9 Mar 2020 at 07:29, John Doe  wrote:
> This is quite off-topic, but I can't bear to read more completely unfounded 
> criticism of PTv2.

highway=bus_stop ("PTv1") is fine for people who survey bus stops and
who want to approximately map a route of a simple bus.

PTv2 is fine for people who want to handle routes that have variants
and branches and who want computer validators to be able to spot
potential errors in these branches.

Some people on both sides don't want to see advantages of the other
scheme, and resort to flatly declaring them bad.

--Jarek (credentials: about 20 non-basic tram, bus, and train routes,
but in an area where stop locations are mostly already surveyed/known)

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


Re: [Tagging] How to map an OpenStreetMap map?

2020-02-29 Thread Jarek Piórkowski
On Sat, 29 Feb 2020 at 16:41, Warin <61sundow...@gmail.com> wrote:
> On 1/3/20 8:31 am, Martin Koppenhoefer wrote:
> On 29. Feb 2020, at 22:25, Warin <61sundow...@gmail.com> wrote:
>>> I think source_map=* or source:map=* would be better as that can also be 
>>> used for other specific 'sources'.
>
>> I would prefer map:source, the tag is information=map so it seems more 
>> consistent to further describe the map with map:*=* tags
>
> Yet the source key is still relevant.
> ...
> source:name  ~ 120,000 uses
> source:ref ~182,000 uses
> source:addr  ~7,880,000 uses

In my understanding, source:name refers to the source of the *value*
being entered in OSM, not the source of the name itself. That is, for
name="Wood Road" and source:name=survey, I went there and saw that the
name is posted as Wood Road. We wouldn't add source:name="there is a
wood nearby". Same for source:ref, source:addr.

By the same scheme, source:map=* would specify the source of the value
of the map tag is OSM, but that isn't what we're looking to specify -
we're looking to specify a property of the object itself (the source
of the information of the map object being entered into OSM database).
The object is a map, thus potential tags include for example
map:size=*, map:braille=*, map:coverage=*, map:resolution=*, or in
this case map:source=*.

Compare etymology:name=* vs name:etymology=*.

--Jarek

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


Re: [Tagging] Annual Shows

2020-02-25 Thread Jarek Piórkowski
On Tue, 25 Feb 2020 at 05:01, Warin <61sundow...@gmail.com> wrote:
> These shows do take place at a permanent site.
>
> They take place annually, floods, fire, droughts and wars excepted.
>
> The dates may vary depending on various things, but usually around the same 
> time each year.
>
> They are part of Australian culture, and it would seem British culture.

I also wish for a settled tag for a regular, locally important event
that is repeatedly or always held at a given site.

I have tagged location of one such in Canada with landuse=fairground
but this doesn't seem perfect and landuse key doesn't logically lend
itself well to specifying details about the events that might be
taking place there. A lot of fairgrounds in Canada end up being tagged
as a park for lack of a better description.

See also related discussion in
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/leisure%3Devents

--Jarek

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


Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

2020-02-20 Thread Jarek Piórkowski
On Thu, 20 Feb 2020 at 02:49, Joseph Eisenberg
 wrote:
>
> I would like to formally request comments on the proposal for
> amenity=motorcycle_taxi:
>
> "A place where motorcycle taxis wait for passengers"
> ...
> While some have proposed using amenity=taxi plus additional tags for
> motorcycle taxi stands, this is quite confusing for travelers who
> generally expect a "taxi" to be 4-wheeled motorcar capable of carrying
> 4 people and luggage. So a different tag is proposed to avoid
> confusion and more precisely tag these features.

We could credit travellers with some knowledge of local norms, and use
secondary tags to clarify when necessary.

As a Canadian, a restaurant will always give free tap water if I am a
dining there. When I travel in Europe, that's not necessarily the
case. Should I suggest a tag amenity=restaurant_with_paid_water?

Similarly I would not expect people to suggest a
highway=secondary_but_extremely_bicycle_unfriendly tag for when they
visit Canada and are used to western European norms of what
highway=secondary looks like. Some of the differences can be tagged
with secondary tags, like cycleway=no, maxspeed, width, lanes...

Ideas of what constitutes a bus station, a train halt, a doctor's
office, toilets, supermarkets, etc will similarly also differ
worldwide.

--Jarek

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


Re: [Tagging] Unremovable bollards

2020-02-16 Thread Jarek Piórkowski
On Sun, 16 Feb 2020 at 17:10, Warin <61sundow...@gmail.com> wrote:
> If you want, then another key so the above does not get polluted?
>
> bollard_structure=block/post/*

bollard_structure=block would surely be better off as a barrier=block?
That's already well established.

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


Re: [Tagging] Unremovable bollards

2020-02-16 Thread Jarek Piórkowski
On Sun, 16 Feb 2020 at 16:51, Warin <61sundow...@gmail.com> wrote:
> Umm...
>
> Bollards are there to protect people. With the present threats I would think 
> identifying which bollards could be easily driven through on a public 
> map/data base would be a bad idea.
>
>
> So I would be firmly against the idea of the subtag value '=breakable'.

I'm not really sure
https://wiki.openstreetmap.org/wiki/File:Bollard_in_residential_area.jpg
does much protecting against any determined actor.

That kind of bollard is there as guidance where to drive (more or less
effective depending on how much attention the driver is paying). Shall
we not map these at all?

IMO the more serious pedestrian protection is more likely to be
barrier=block (some heavy-duty bollards notwithstanding)

--Jarek

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


Re: [Tagging] Unremovable bollards

2020-02-16 Thread Jarek Piórkowski
On Sun, 16 Feb 2020 at 15:53, ET Commands  wrote:
> > bollard=unremovable for fixed bollards sounds good to me.
>
> My spelling check does not like "unremovable" but instead suggests
> "irremovable."  However, if I want to be nit-picky, all bollards are
> ultimately removable, so maybe more appropriate values would be
> "retractable" and "non-retractable."

Around here, many removable bollards are removed by unlocking a lock
near the ground and lifting them out manually - I'm not sure if I
would describe that as "retractable".

Others are unlocked and then can be put flat against the ground,
that's covered by "hinged" I guess but only 3 uses worldwide...
perhaps covered by "foldable" with 62 uses.

"Fixed" does sound to me more straightforward than "unremovable" though.

--Jarek

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


Re: [Tagging] Unremovable bollards

2020-02-15 Thread Jarek Piórkowski
On Sat, 15 Feb 2020 at 15:16, John Sturdy  wrote:
> On Sat, Feb 15, 2020 at 6:54 PM Hauke Stieler  wrote:
>> there's the "bollard" key with documented value "rising" and "removable"
>> [0] but I often encounter also bollards which cannot be removed easily.
>> I would love to see the "unremovable" value in the documentation. Should
>> I open a proposal page for this one value? That sounds a bit of an
>> overkill to me.
>
> I think that by default bollards are not removable, and that if a bollard is 
> not tagged as removable, it is reasonable to assume it's not removable.

A problem with this "null tag" interpretation is that with its
absence, it's not really possible to tell whether a bollard has been
surveyed and confirmed as non-removable, or if it hasn't been surveyed
in sufficient detail (e.g. bollard visible on satellite imagery but no
one checked on it in person).

--Jarek

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


Re: [Tagging] [Tagging} no stopping, no parking

2020-02-10 Thread Jarek Piórkowski
On Mon, 10 Feb 2020 at 18:32, Jarek Piórkowski  wrote:
>
> On Mon, 10 Feb 2020 at 13:29, Volker Schmidt  wrote:
> > Why are "stopping=yes|no" and "parking=yes|no" (and variants of these) not 
> > in use in OSM?
> > But the much more complex "parking:lane:both=no_stopping" and 
> > "parking:lane:both=no_parking" are in use with the same meaning.
>
> Because parking:lane:both=no_parking is part of a tagging schema that
> allows consistently tagging more complex values, such as:
>
> parking:lane:right=parallel
> parking:condition:right=no_stopping
> parking:condition:right:time_interval=Mo-Fr 07:00-09:00
> parking:condition:right:2=ticket
> parking:condition:right:2:time_interval=Mo-Fr 09:00-21:00; Sa
> 08:00-21:00; Su 13:00-21:00
>
> or
>
> parking:lane:right=no_parking
> parking:lane:left=parallel
> parking:condition:left=free
> parking:condition:left:maxstay=1 h
> parking:condition:left:time_interval=08:00-18:00

... and to expand on this a little bit: around here at least, I am
under the impression most of this parking information was added based
on streetside imagery by people working on behalf of organizations who
are interested in parking and stopping conditions. For a variety of
reasons these organizations aren't interested in sections that are a
plain "no parking" always on both sides of the street, and instead are
more interested in more complex situations. So that might be part of
why the simple tags didn't get used as much.

--Jarek

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


Re: [Tagging] [Tagging} no stopping, no parking

2020-02-10 Thread Jarek Piórkowski
On Mon, 10 Feb 2020 at 13:29, Volker Schmidt  wrote:
> Why are "stopping=yes|no" and "parking=yes|no" (and variants of these) not in 
> use in OSM?
> But the much more complex "parking:lane:both=no_stopping" and 
> "parking:lane:both=no_parking" are in use with the same meaning.

Because parking:lane:both=no_parking is part of a tagging schema that
allows consistently tagging more complex values, such as:

parking:lane:right=parallel
parking:condition:right=no_stopping
parking:condition:right:time_interval=Mo-Fr 07:00-09:00
parking:condition:right:2=ticket
parking:condition:right:2:time_interval=Mo-Fr 09:00-21:00; Sa
08:00-21:00; Su 13:00-21:00

or

parking:lane:right=no_parking
parking:lane:left=parallel
parking:condition:left=free
parking:condition:left:maxstay=1 h
parking:condition:left:time_interval=08:00-18:00

--Jarek

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


Re: [Tagging] amenity=faculty?

2020-02-04 Thread Jarek Piórkowski
On Tue, 4 Feb 2020 at 11:44, Greg Troxel  wrote:
> Mateusz Konieczny via Tagging  writes:
> > Universities may have faculties, that often deserved to be mapped 
> > separately.
> > ...
> > It seems to me that amenity=faculty would be useful.
>
> Perhaps, but beware that in US English, this is bizarre usage.  Faculty
> refers to the set of people that are professors, not a place, and not a
> subdivision of a university.
> ...
>
> I'm sure other universities contain within them colleges, and I suspect
> "school" is fairly common.
>
> Really my point is that "Faculty of mathematics" is going to be
> confusing to en_US speakers.  I have no idea if it's used in en_GB, but
> I've never heard of it.

As a counterpoint, at my en_CA university established in 1957 we did
have faculties in the sense used by Mateusz. Schools were generally
ordered lower than faculties: School of Architecture was part of
Faculty of Engineering. Most sub-parts of faculties were named
Departments.

--Jarek

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


Re: [Tagging] road names and refs

2020-01-30 Thread Jarek Piórkowski
On Thu, 30 Jan 2020 at 09:38, Rob Savoye  wrote:
> On 1/30/20 2:08 AM, Richard Fairhurst wrote:
> > "County Road 12" is a ref. It is not a name. People often refer to roads by
> > their ref. That's fine. I will say "I'm taking the A3400 to Stratford"
>
>   I'm wondering if "CR 12" or "County Road 12" (the abbreviation
> expanded) was the proper value for a ref. If the abbreviation is fine
> for the ref, should it then have a name that is expanded ? The wiki
> isn't clear.

One solution I've seen advanced is that the ref in that case is just
12. But that rather raises more new questions than it answers, because
while no one says "I'm going to take the Highways England A3400" or
"the British A3400", people do say "I'm going to take County Road
12"...

--Jarek

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


Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

2020-01-29 Thread Jarek Piórkowski
On Wed, 29 Jan 2020 at 18:08, Joseph Eisenberg
 wrote:
> The problem is that new users of iD do not know that they are adding
> tags like healthcare=pharmacy and dispensing=yes.
>
> I reviewed the pharmcies in the cities I have mapped, and found that I
> had added healthcare=pharmacy to 8 features unintentionally, since I
> used iD for my first year of mappping.
>
> Also they all have dispensing=yes, which is mostly true I think, but I
> do not recall checking any option to add this, which makes me question
> whether the tag has any meaning when it is automatically added by iD.

Checking now, it appears dispensing=yes is not actually automatically
added by iD when using the upgrade function on an amenity=pharmacy
that does not have that tag.

Although it _is_ added if you choose "Pharmacy Counter" as a POI
preset when explicitly creating a POI or changing its category.

--Jarek

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


Re: [Tagging] Deprecate healthcare=pharmacy and healthcare=hospital

2020-01-29 Thread Jarek Piórkowski
On Wed, 29 Jan 2020 at 07:25, Joseph Eisenberg
 wrote:
>
> > iD also brings up the "suggestion" that existing amenity=clinic, pharmacy &
> > (I think) dentist tags by themselves are "incomplete" & should be upgraded
> > by adding healthcare=
> > eg https://www.openstreetmap.org/edit#map=21/-28.07641/153.42326
>
> That's interesting. I wonder if there is a way to find what percentage
> of the healthcare=pharmacy tags were added by iD or other editors in
> this way.

One could crunch edit history of some affected nodes and see how many
of the tags were added by which editor according to created_by tag on
the changeset.

While we're on the subject, "amenity pharmacy" would make a good
addition to the recently discussed
https://wiki.openstreetmap.org/wiki/Counterintuitive_key_names wiki
page.

I'm also curious about your thoughts regarding public_transport=*
double tagging, regarding tagging both wikipedia and wikidata, and
regarding brand keys (name=McDonald's + brand=McDonald's)

--Jarek

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


Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

2020-01-28 Thread Jarek Piórkowski
On Tue, 28 Jan 2020 at 19:55, Paul Johnson  wrote:
>
>
>
> On Tue, Jan 28, 2020 at 6:51 PM Jarek Piórkowski  wrote:
>>
>> On Tue, 28 Jan 2020 at 19:45, Paul Johnson  wrote:
>> > On Tue, Jan 28, 2020 at 6:14 PM Yaro Shkvorets  wrote:
>> >> That passage should be rewritten. That's certainly not the common 
>> >> practice.
>> >> I personally tag `highway=cycleway` where bikes significantly outnumber 
>> >> foot traffic, `highway=footway` where foot traffic significantly 
>> >> outnumbers bikes, `highway=path` for the rest.
>> >> If you need to explicitly disallow bikes or foot you use access tags.
>> >
>> > This seems a little iffy.  I mean, footway is obvious, is it designed for 
>> > people on foot, and too narrow for oncoming bikes to meet?  Footway.  City 
>> > sidewalk?  Footway.  A path through a park?  Probably a path (especially 
>> > if it's multiuse), unless it's really narrow, then footway.  Has lanes but 
>> > isn't a street?  Cycleway.
>>
>> Around Toronto I've generally seen (and also tagged myself), for
>> routes through a park, footway if it's paved or otherwise major, path
>> if it's unpaved or overgrown or status uncertain. So I interpret
>> highway=footway to be "higher grade" than highway=path - the opposite
>> of your interpretation, I fear...
>
> Not higher grade, just not as specialized in its design purpose and what 
> other use modes will not find their needs particularly addressed if it's 
> allowed at all.  In a venn diagram of bridleway, cycleway and footway, path 
> is in the middle.

Hm, that's not how I think about it. In my mental map: bridleway
doesn't exist (as a big-city mapper); path is something for people but
nothing major; footway is usually paved with a lot of pedestrians on
it and if not a sidewalk maybe bikes but not majority; cycleway is
usually paved with relatively a lot of bicycles on it (can be unpaved
if out in nature).

I see now that wiki disagrees, I'll try to adjust my mapping
accordingly... JOSM's rendering of footway as solid line and path as
dashed doesn't help.

--Jarek

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


Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

2020-01-28 Thread Jarek Piórkowski
On Tue, 28 Jan 2020 at 19:45, Paul Johnson  wrote:
> On Tue, Jan 28, 2020 at 6:14 PM Yaro Shkvorets  wrote:
>> That passage should be rewritten. That's certainly not the common practice.
>> I personally tag `highway=cycleway` where bikes significantly outnumber foot 
>> traffic, `highway=footway` where foot traffic significantly outnumbers 
>> bikes, `highway=path` for the rest.
>> If you need to explicitly disallow bikes or foot you use access tags.
>
> This seems a little iffy.  I mean, footway is obvious, is it designed for 
> people on foot, and too narrow for oncoming bikes to meet?  Footway.  City 
> sidewalk?  Footway.  A path through a park?  Probably a path (especially if 
> it's multiuse), unless it's really narrow, then footway.  Has lanes but isn't 
> a street?  Cycleway.

Around Toronto I've generally seen (and also tagged myself), for
routes through a park, footway if it's paved or otherwise major, path
if it's unpaved or overgrown or status uncertain. So I interpret
highway=footway to be "higher grade" than highway=path - the opposite
of your interpretation, I fear...

--Jarek

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


Re: [Tagging] Page about mismatching key names (historic=wayside_shrine used for modern ones etc)

2020-01-24 Thread Jarek Piórkowski
On Fri, 24 Jan 2020 at 09:12, Volker Schmidt  wrote:
> Il ven 24 gen 2020, 11:51 Mateusz Konieczny via Tagging 
>  ha scritto:
>> One of topics often appearing is mismatch between meaning of key
>> and key text.
>> ...
>> It is created at
>> https://wiki.openstreetmap.org/wiki/Mismatching_key_names
>> but page name is horrible. Ideas for a better one is welcome.
>>
>> Also, I only started it - help in expanding and improving it
>> is highly welcomed.
>
> These are no mismatches.
> Keys and values are in principle arbitrary sequences of alphanumeric 
> characters. By convention we try to make them mnemonic by using strings that 
> somehow help us remember the meaning of the string. By convention we use 
> British English words for keys and values, plus numbers, mainly for values.
>
> This explanation needs to be placed prominently on the new page, to avoid any 
> doubt.

Please no. That wiki page is a much better explanation than this "it's
only symbols".

Keys and values are ways for us as human editors to communicate with
each other. Those are commonly called "words" - well, at least in
Canadian English, I don't know about British English.

It is definitely worth explaining why some words as OSM editors use
them are different from words as the rest of the world (or a subset of
the world) might use them.

--Jarek

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


Re: [Tagging] Continuous Sidewalk or Cycleway

2020-01-23 Thread Jarek Piórkowski
On Thu, 23 Jan 2020 at 17:05, Volker Schmidt  wrote:
> On Thu, 23 Jan 2020 at 21:11, Florimond Berthoux 
>  wrote:
>> How to map a continuous sidewalk or cycleway ?
>> In order to solve this question I created a wiki page to sum up my first try 
>> to tag this:
>> https://wiki.openstreetmap.org/wiki/Continuous_Sidewalk
>>
>> The main idea is to use the tag:
>> junction=continuous_sidewalk|continuous_cycleway
>> on node or ways of a feature.
>>
>> Helpful comments are welcome.
>
> How is this legally and physically different form this situation:
> https://www.openstreetmap.org/way/203142300
> https://www.mapillary.com/map/im/B9kqmuGy9C2qp0O86oQy5Q
> ?

"for instance in France a car driver crossing a sidewalk must give way
to others" says the wiki page. Presumably this is a different legal
case than at a crosswalk in France.

--Jarek

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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-16 Thread Jarek Piórkowski
On Thu, 16 Jan 2020 at 00:51, European Water Project
 wrote:
>>5. Re: Query regarding seasonal tag combined for outdoor water
>>   fountains. (Jarek Piórkowski)
>>   >>>>  Jarek, I think preferable to avoid seasons on open hours and put 
>> month range to avoid Northern/Southern hemisphere confusion. What do you 
>> think?

That would be ideal. However in my case I really don't know what the
active months are.

I know it's shut off in the dead of winter, and I'm guessing it's shut
down before first freezes and turned back on after thaws. But I don't
know exactly, and the temperatures/freeze dates can vary widely.

I could probably find out from the city/responsible authority, but
that raises issues with verifiability.

--Jarek

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


  1   2   >