Re: [Tagging] "satellit"

[Jean-Marc Liotier]

On 3/6/19 6:00 AM, Warin wrote:

So .. what is the best way to map them?


My proposal would be a straightforward main tags chain to describe the 
physical landmark features - and then all the extra sauce specialists 
might want, but in a way that won't complicate the basics. So...


man_made=antenna
antenna=dish (or monopole/dipole/yagi/helical/phased_array ...)

and then radio aficionados may add as much of 
https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use as 
they want (so we would amend this proposal to make it a complement to 
the physical landmark features main tags).




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

Re: [Tagging] "satellit"

[Jean-Marc Liotier]

On 3/6/19 3:31 AM, Sergio Manzi wrote:
My friend, there are 88 persons who have mapped 520 antennas 
(https://taginfo.openstreetmap.org/keys/antenna).


Compare it to the billions of antennas out there and I think we are 
far below the "/noise level/" and that all energy "invested" in trying 
to regulate this is... lost energy.


The only antennas I would personally map and tag are those who are 
enough conspicuous to represent landmarks


We are currently at 7252 for man_made=antenna alone 
(https://taginfo.openstreetmap.org/tags/man_made=antenna) and then there 
are all the strange things such as (man_made=mast + 
tower:type=communication) which may or may not record a mast with antennas.


But yes, my goal is landmarks such as conspicuous parabolas, not my 
neighbour's pet yagi.



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

Re: [Tagging] amenity=police

[Jan S]

Am 6. März 2019 00:35:44 MEZ schrieb Graeme Fitzpatrick :
>On Tue, 5 Mar 2019 at 22:01, Jan S  wrote:
>
>
>How about emergency=police?
>
I had thought about that, too. But my impression is that the emergency tag is 
more restricted to facilities that help you in ongoing situations of distress 
and are on the spot. I assume it's rather unusual to go to the police in an 
emergency, but you'd rather call them.

The police station itself may be for less urgent situations mainly. So also for 
that reason, the emergency tag may be inaccurate.

Best, Jan

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

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

[Florian Lohoff]

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

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

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

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


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

Re: [Tagging] Possibility to draw parking properties as an area

[OSMDoudou]

Parking spaces, you mean ?

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging laboratories

[Mark Wagner]

On Tue, 5 Mar 2019 14:03:37 +1100
Warin <61sundow...@gmail.com> wrote:

> On 04/03/19 21:25, Martin Koppenhoefer wrote:
> >
> > Am Mo., 4. März 2019 um 09:37 Uhr schrieb Warin
> > <61sundow...@gmail.com >:
> >
> >
> >
> > These can be commercialfirms, part of the government, or part
> > of a university etc.
> >
> > They usually specialise in one field so will need sub tags.
> >
> >
> >
> >
> > I would question whether we put all kind of "laboratory" into the
> > same category and distinguish them by subtags. There are too many
> > different kind of things that could be subsummized as "laboratory".
> > Think about eletronic laboratories, chemistry research labs,
> > biochemical labs, labs for human healtcare analytics, etc.
> > First distinction could be "research lab" vs. "analytical lab" vs. 
> > maybe more types, and these should IMHO become main tags, not
> > subtags.
> >
> > There is also some potential confusion with the word "laboratory" 
> > being used as a hyped name for workspace where you would not expect 
> > it, e.g. software laboratory, architectural design laboratory, art 
> > laboratory, etc.
> > So we would need some definition, what the criterion for
> > "laboratory" is (or is it the name?).  
> 
> To me a true 'laboratory' has controlled environmental conditions, 
> usually temperature is tightly controlled, the better labs have
> humidity control probably not as tight.
> They may have other things controlled too - such as radio
> interference, dust.

I guess the mechanical-testing laboratory I worked at in college
doesn't count as a "true" laboratory: as long as the temperature within
10 degrees F of 75, we could keep running tests.  That's a far wider
range than you'd normally find in an office environment.

(Other environmental conditions weren't any more tightly controlled.
Aluminum and steel don't really care what you're subjecting them to,
and the measuring instruments we were using were similarly robust.)

-- 
Mark

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

Re: [Tagging] "satellit"

[Warin]

On 06/03/19 13:31, Sergio Manzi wrote:

On 2019-03-06 03:20, Warin wrote:

On 06/03/19 12:38, Sergio Manzi wrote:
Also, if on the other hand you don't expect all TV antennas to be 
mapped, what will be the value of such fragmentary and sparse 
information? "/Cui prodest/"? Who is going to benefit from such 
information? Those with a concrete interest in such information will 
surely already have their accurate sources of information and 
disregard our fragmentary and sparse information of unknown accuracy.


Unfortunately people are tagging antennas .. in all sorts of ways. 
And it is a mess.


I seek to provide some constancy so that the information is at least 
usable for those that want it.


A short look at 
https://taginfo.openstreetmap.org/keys/antenna%3Atype#values will 
give you a feeling of what is happening and why there needs to be 
some guidance on it.
The numbers are small .. but best to provide some guidance now rather 
than end up with 'oh but it is in use so we cannot fix it now'. 



My friend, there are 88 persons who have mapped 520 antennas 
(https://taginfo.openstreetmap.org/keys/antenna).




I am one of those 88. Well at least one who has modified other peoples 
work on some antennas that have been mapped.
An example ... Way: Murchison Widefield Array (607964749) - there will 
be 2,048 dipole arrays here .. I have chose to map them as an area as 
that is easiest at least for the moment.


I have tagged it as
  "website"="http://www.mwatelescope.org/";
    "man_made"="telescope"
    "telescope:type"="radio"
    "name"="Murchison Widefield Array"
    "description"="2048 dual-polarization dipoles when combined forms a 
single telescope"

    "antenna:polarisation"="dual"
    "antenna:configuration"="dipole array"
    "antenna:propagation"="reception"
    "frequency"="80 - 300 MHz"

There are located near a collection of other radio telescopes ... higher 
frequency ones .. with steerable dishes.


Compare it to the billions of antennas out there and I think we are 
far below the "/noise level/" and that all energy "invested" in trying 
to regulate this is... lost energy.


The only antennas I would personally map and tag are those who are 
enough conspicuous to represent landmarks.





The ones I am mapping are certainly conspicuous.

So .. what is the best way to map them?

That is the function of this list, does not matter how many.. just get 
the tagging as good as we can and then let the mappers use or not use it.



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

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-06 03:20, Warin wrote:
> On 06/03/19 12:38, Sergio Manzi wrote:
>> Also, if on the other hand you don't expect all TV antennas to be mapped, 
>> what will be the value of such fragmentary and sparse information? "/Cui 
>> prodest/"? Who is going to benefit from such information? Those with a 
>> concrete interest in such information will surely already have their 
>> accurate sources of information and disregard our fragmentary and sparse 
>> information of unknown accuracy.
>
> Unfortunately people are tagging antennas .. in all sorts of ways. And it is 
> a mess.
>
> I seek to provide some constancy so that the information is at least usable 
> for those that want it.
>
> A short look at https://taginfo.openstreetmap.org/keys/antenna%3Atype#values 
> will give you a feeling of what is happening and why there needs to be some 
> guidance on it.
> The numbers are small .. but best to provide some guidance now rather than 
> end up with 'oh but it is in use so we cannot fix it now'. 


My friend, there are 88 persons who have mapped 520 antennas 
(https://taginfo.openstreetmap.org/keys/antenna).

Compare it to the billions of antennas out there and I think we are far below 
the "/noise level/" and that all energy "invested" in trying to regulate this 
is... lost energy.

The only antennas I would personally map and tag are those who are enough 
conspicuous to represent landmarks.

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Warin]

On 06/03/19 12:38, Sergio Manzi wrote:
Also, if on the other hand you don't expect all TV antennas to be 
mapped, what will be the value of such fragmentary and sparse 
information? "/Cui prodest/"? Who is going to benefit from such 
information? Those with a concrete interest in such information will 
surely already have their accurate sources of information and 
disregard our fragmentary and sparse information of unknown accuracy.


Unfortunately people are tagging antennas .. in all sorts of ways. And 
it is a mess.


I seek to provide some constancy so that the information is at least 
usable for those that want it.


A short look at 
https://taginfo.openstreetmap.org/keys/antenna%3Atype#values will give 
you a feeling of what is happening and why there needs to be some 
guidance on it.
The numbers are small .. but best to provide some guidance now rather 
than end up with 'oh but it is in use so we cannot fix it now'.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-05 23:48, Warin wrote:
> On 05/03/19 21:30, Sergio Manzi wrote:
>>
>> On 2019-03-05 11:14, Warin wrote:
>>
>>> On 05/03/19 20:08, Jean-Marc Liotier wrote:
 On Mon, March 4, 2019 11:20 pm, Warin wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
 This is a way to solve most of the problem, but it fails the "map it as I
 see it" test.

 man_made=antenna + antenna:reflector=dish does map the satellite
 communications antenna I just spotted... But what the naïve mapper I am
 really wants is man_made=antenna + antenna=dish (or
 monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !

 Then one can add antenna:propagation, antenna:application,
 antenna:propagation, antenna:polarisation etc. but they are accessory.

 Am I mistaken in believing that the main tags chain should focus on
 offering a straightforward way to map the apparent physical features,
 rather than invisible distinctions ? Not that invisible distinctions are
 not welcome too - but they should stay out of the way.
>>>
>>> Sympathies!
>>>
>>> An alternative is available ...
>>>
>>> man_made=antenna
>>>
>>> dish=yes
>>
>> So far, so good.
>>
>>
>>> cross_gain_feed=yes
>>
>> What does that mean? I'm a licensed radio amateur (/for more than 30 years/) 
>> and I never heard of that term... :-/
>>
>
> Arr  casse grain ... apologies. (added word to spell checker)


Ah, OK, a Cassegrain antenna, one with the Illuminator on (/or close to/) the 
surface of the main concave reflector and a secondary convex reflector. 
Amazing, but it takes the name from the inventor of this design, Laurant 
Cassegrain, 1*_6_*29-1*_6_*93!!!  :-)


> How is the reflecting dish signal connected? There must be a real antenna 
> that does that.
> And then there is the way the antenna gets the reflected signal.
> https://en.wikipedia.org/wiki/Parabolic_antenna
>
>
>
> There is a lot to learn, we should have more life times ...
>
>>> two_way=yes
>>
>> Prove that!
>>
> As an example: This may be a TV studio where TV programs are transmitted to a 
> satellite for distribution.
> As a TV studio it may also receive TV signals from remote broadcasts... or 
> other TV studios connected to the satellite.


I'm sure you understand that the above argument isn't worth a dime: you only 
move the issue of "/knowing/" that an antenna is a two ways antenna to the one 
of "/knowing/" that below the antenna there is a production studio broadcasting 
stuff and therefore there must be a two_ways antenna somewhere on the roof: one 
of the probably many antennas up there.


> OSM accepts 'knowledge' as a suitable source of information.


Really? OSM accepts 'knowledge' as a suitable source of information? Whose 
knowledge? How verifiable? I don't know if this is really an official policy 
(/to me it seems to violate the observability and verifiability principles/), 
but if it really is (/is it?/), I tell you, I'm not interested in that kind of 
information: in a GIS I only trust observable and verifiable truths, even if 
you have all the rights to "map your knowledge".


>>> satellite=yes
>>
>> Prove that! Because it points at the sky? There are many other good reasons 
>> to point an antenna at the sky...
>>
>
> Again? If you don't know .. don't tag it. But don't deny others from adding 
> stuff they do know.
>
> Don't know that a road is closed in winter? then don't tag it.
> Know that a road is closed in winter - tag it.
> Come across an open road in summer that is tagged closed in winter ... and 
> you want to verify the closure? Come back in winter or contact the relevant 
> mapper.


Yes, sorry, again and again. Of course if I don't know something I will not tag 
it, but I'm more concerned about those who thinks or pretend to know and will 
tag "something" which is not generally and easily verifiable.

If on the antenna on the roof there is a board stating "This is a two_ways 
antenna" and on the road there is a board stating its winter closure, I fully 
accept the tagging. If there is no such board I don't trust that information, 
nor for the antenna, nor for the road and I'll seek more reliable sources of 
information (/of course the "boards" could be "virtual boards", such as 
officially published information from the road/building operator/).


> The most common antenna people see are TV antennas, most pople know what they 
> are and can tag them at least the basics. Next would be mobile phone 
> antennas. After that they are not so well known, most would have to look them 
> up to find out what they are.


Now tell me that you really expect (and hope) to map all TV antennas in the 
world, on the roof of their respective buildings. You understand we are in all 
likelihood talking of billions (10^9) objects, do you? And you surely 
understand that such huge quantity of information will cause inefficiencies 
(/and costs.../) for the system.

I'm also very much unsure that a s

Re: [Tagging] RFC rewritten proposal Via_ferrata_simplified

[Kevin Kenny]

On Tue, Mar 5, 2019 at 11:11 AM egil  wrote:
>
> The 3 main goals of this proposal are:
>
> 1. the removal of the special tag highway=via_ferrata,
> 2. encouraging tagging of via ferratas as routes and
> 3. general improvement of the data about via ferratas in OSM via new keys.

Slightly off topic: vie ferrate are not a familiar thing in the
mountains near me.
Does 
http://aspiringfortysixer.com/Upper_Lower_Wolfjaw,_Armstrong_%26_Gothics_files/P1010309.jpg
count?
In favourable weather, the usual drill is to walk up holding onto the
cables as those climbers are doing.
In foul weather, it's common to wear a climbing harness and slap
ascenders on the cables.
http://3.bp.blogspot.com/-rZItzz3zkDY/US1KUkrBj_I/Ggs/dXDiGGn1-ls/s1600/P1020365.JPG
The slick feldspar there makes that stretch well-nigh un-hikable
without the aids.
I'm not sure what the folks in the Alps consider the defining features
of a via ferrata to be.

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

Re: [Tagging] amenity=police

[Martin Koppenhoefer]

sent from a phone

> On 5. Mar 2019, at 12:17, Jan S  wrote:
> 
> Any thoughts on this?


if you think about it, there are more police forces in Germany, particularly if 
we find more specific tagging for specific categories of forces (e.g. 
Bereitschaftspolizei, Autobahnpolizei, Wasserschutzpolizei, LKA, BKA) and 
others that might eventually be considered police like Zoll, Steuerfahndung, 
Justizvollzugsbeamte, Küstenwache, Forstamt (forrester), Ordnungsamt, 
Wirtschaftskontrolldienst, Feldjäger, ...

Belonging to “military” does not necessarily exclude a body from being a police 
force, neither in osm, or does it?

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

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Martin Koppenhoefer]

sent from a phone

> On 5. Mar 2019, at 23:30, Tobias Knerr  wrote:
> 
> Of course, connecting the sidewalk to the highway with a relation would
> likely offer a solution to that issue, too.


there’s a proposal for a relation type=area which lets you add sidewalks, 
kerbs, guard rails and other barriers (all should be more or less parallel) 
together with highways into an  area relation (defines implicitly an area 
between the ways)

Cheers, Martin 




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

Re: [Tagging] RFC rewritten proposal Via_ferrata_simplified

[Martin Koppenhoefer]

sent from a phone

> On 5. Mar 2019, at 23:06, Richard  wrote:
> 
> highway=via_ferrata is supported by almost all renderers(*) and you will
> break them.
> Not only is there no need to remove it but it is highly counterproductive.
> 
> via_ferrata_scale on a highway=path would be considered (yet another) troll 
> tag so that would be a step back.


+1, the reason via ferrata has been given its own highway value was to require 
from data consumers to explicitly include it (so they would be aware and had to 
decide how and if it was included in their work). If it would just be a 
property of an established highway class like path, many maps would 
accidentally render these in an inappropriate way without being aware of it.


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

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

[Greg Troxel]

leisure=common seems wrong for two reasons:

  the original notion of town common was land that could be used by all
  and was owned by the town or somehow public.   A bit of land that is
  grass in an urban area does not fit this.

  town commons were about grazing or perhaps a meeting place; calling
  them leisure seems very odd

Agreed with others that if it's just grass then just use landcover.

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

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

[Warin]

On 05/03/19 22:34, Mateusz Konieczny wrote:




Mar 5, 2019, 11:48 AM by s...@smz.it:

Hi!

On 2019-03-05 11:13, Mateusz Konieczny wrote:


Mar 5, 2019, 9:00 AM by mky...@email.cz :

Typically a small areas in the city between apartment
buildings. These areas are not official parks, gardens or
grass. It is just a green accessible for everoyne. So we can
say it is a *public* or *common* green.

So far I usually tagged such places as follows:

Made sure that it is within landuse=residential (as it is a
residential area)
Mapped physical features (leisure=playground, natural=tree,
landuse=grass, highway=footway etc)


Is it land*use*=grass or land*cover*=grass? I tend to agree with
Alessandro Sarretta who uses landcover...

landcover=grass also would be fine in this case, but meaning of this 
tags is the same and

landuse=grass is more popular

I also have doubts about leisure=playground as it is not a
physical feature but it describe the usage done of that space, not
its characteristics.

I use leisure=playground solely for cases where it clearly describes a 
physical feature
Something like 
https://commons.wikimedia.org/wiki/File:Aire_de_jeux_en_2017_(20).jpg 

I am not advocating for entire to be tagged as playground, just parts 
that are playgrounds

(the same with natural=tree, landuse=grass, highway=footway - such things
should be tagged only where this features are)

Also that very same space could be used for different things
(/fairs, concerts, rallies, etc./) at different times...

Sounds like landuse=recreation_ground or leisure=park to me.



On 06/03/19 10:28, Graeme Fitzpatrick wrote:




On Tue, 5 Mar 2019 at 21:36, Mateusz Konieczny 
mailto:matkoni...@tutanota.com>> wrote:


Sounds like landuse=recreation_ground or leisure=park to me.


Yep, I'd also suggest =recreation_ground.


Could be used
That does not mean they are used as a recreation ground. Only could.
They could be used to land a helicopter too .. would you map it as a 
helipad too???


Map what you know, trees grass... leave 'could' for someone that knows?


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

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

[Joseph Eisenberg]

> over the top of residential area, so it will appear as a lighter patch of
> green in between your buildings, & can have things such as playgrounds or
> basketball hoops included inside it.


This is not the original meaning of “Recreation Ground” in British English.
A recreation ground in England is like a large area used for sports and
games. It’s not just a playground or basketball court or patch of grass in
a residential area

But I admit it has been used for many other things

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Drecreation_ground
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Possibility to draw parking properties as an area

[Graeme Fitzpatrick]

On Wed, 6 Mar 2019 at 02:56, yo paseopor  wrote:

> Moment has arrived.
> I need the use of the tagging scheme into a separated items (not only the
> highway itself) to make possible the draw of specific parking areas (or
> spaces if it is specified) in the streets with their properties exactly
> drawn as areas or ways.
>

What's wrong with amenity=parking, or am I misunderstanding your question?

Thanks

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

Re: [Tagging] amenity=police

[Graeme Fitzpatrick]

On Tue, 5 Mar 2019 at 22:01, Jan S  wrote:

> As amenity=police is currently being used indiscriminately for almost all
> police-related facilities, we would have to review all police buildings
> manually anyways to differentiate police stations and other units. In the
> long run, I would therefore get rid of amenity=police altogether (and thus
> decongestionate the "amenity"-tag a bit).
>

How about emergency=police?

Thanks

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

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

[Graeme Fitzpatrick]

On Tue, 5 Mar 2019 at 21:36, Mateusz Konieczny 
wrote:

> Sounds like landuse=recreation_ground or leisure=park to me.
>

Yep, I'd also suggest =recreation_ground.

I've just tried & it renders over the top of residential area, so it will
appear as a lighter patch of green in between your buildings, & can have
things such as playgrounds or basketball hoops included inside it.

 Thanks

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

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Nick Bolten]

> Unlike associatedStreet, which contains all street ways sharing the same
name and can thus contain networks of essentially unbounded complexity,
these relations should probably only span the stretch between two
junctions, though.

Agreed. This was something I had in mind but forgot to say out loud. This
might also help with naming, as it is very similar to the idea of a "block
face". Drawing from that name as inspiration, a potential "blockFace"
relation could be either "left" or "right" and only have to deal with one
set of amenities at a time (on the left or right side of the street). This
would cut down on the amount of features one would have to reference in a
single relation.

Re: kerb lines: you're right about potential duplication of data, but
similar to the sidewalks situation, I'm firmly in the camp that this data
doesn't get mapped with much specificity without its own intuitive home for
detail. The coverage for barrier=kerb / kerb=* on roads is pretty scanty
and definitely doesn't describe the actual curb interfaces for even a
single small town. For example, kerb:right is used 300 times according to
TagInfo, whereas I just looked at mapping kerbs around one block and found
at least 25 kerb changes on kerb:right alone. This tells me that the kerb
tag, when applied to roads, has not been mapped very specifically. tl;dr: I
could beat that tag count in about 30 minutes *and* create a bunch of great
data for pedestrian modeling + parking if I felt confident in the tagging
schema.

Best,

Nick

On Tue, Mar 5, 2019 at 2:32 PM Tobias Knerr  wrote:

> On 05.03.19 01:01, Nick Bolten wrote:
> > What would you think
> > of a new 'associatedStreet'-style relation that would organize the
> > various features that should be associated between streets and the
> > surrounding environment?
>
> That approach could work, yes – and it's one of the few practical
> options I can think of at the moment. (The other would be drawing an
> area:highway polygon around all the individual ways.)
>
> Unlike associatedStreet, which contains all street ways sharing the same
> name and can thus contain networks of essentially unbounded complexity,
> these relations should probably only span the stretch between two
> junctions, though.
>
> While I would want to cobble together a proof of concept implementation
> to be sure that I'm not overlooking anything, such a relation would
> probably to solve the issue from a data consumer point of view. Of
> course, it would have to actually be used by mappers to be helpful.
>
> > Just to clarify, the road can keep all of its same data as is currently
> > mapped. This would be an additional piece of information that tends to
> > go unmapped.
>
> In theory, the two approaches could peacefully coexist as long as tags
> for kerbs, parking:lane etc. on the street ways themselves (and
> highway=crossing nodes) remained available after drawing the separate
> ways – at the cost of duplication and therefore additional maintenance.
>
> There are some hurdles, though. Even mapping just sidewalks as a
> separate way tends to break stuff. For example, people understandably
> connect incoming footways only to the sidewalk way, not to the street
> way. So an application that filters out these separate ways, hoping to
> instead rely on tags on the street way, will find itself with missing
> connections to the pedestrian network.
>
> Of course, connecting the sidewalk to the highway with a relation would
> likely offer a solution to that issue, too.
>
> Tobias
>
> ___
> 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] "satellit"

[Warin]

On 05/03/19 21:30, Sergio Manzi wrote:


On 2019-03-05 11:14, Warin wrote:


On 05/03/19 20:08, Jean-Marc Liotier wrote:

On Mon, March 4, 2019 11:20 pm, Warin wrote:

https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
This is a way to solve most of the problem, but it fails the "map it 
as I

see it" test.

man_made=antenna + antenna:reflector=dish does map the satellite
communications antenna I just spotted... But what the naïve mapper I am
really wants is man_made=antenna + antenna=dish (or
monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !

Then one can add antenna:propagation, antenna:application,
antenna:propagation, antenna:polarisation etc. but they are accessory.

Am I mistaken in believing that the main tags chain should focus on
offering a straightforward way to map the apparent physical features,
rather than invisible distinctions ? Not that invisible distinctions 
are

not welcome too - but they should stay out of the way.


Sympathies!

An alternative is available ...

man_made=antenna

dish=yes


So far, so good.



cross_gain_feed=yes


What does that mean? I'm a licensed radio amateur (/for more than 30 
years/) and I never heard of that term... :-/




Arr  casse grain ... apologies. (added word to spell checker)

How is the reflecting dish signal connected? There must be a real 
antenna that does that.

And then there is the way the antenna gets the reflected signal.
https://en.wikipedia.org/wiki/Parabolic_antenna



There is a lot to learn, we should have more life times ...




two_way=yes


Prove that!

As an example: This may be a TV studio where TV programs are transmitted 
to a satellite for distribution.
As a TV studio it may also receive TV signals from remote broadcasts... 
or other TV studios connected to the satellite.


OSM accepts 'knowledge' as a suitable source of information.




satellite=yes


Prove that! Because it points at the sky? There are many other good 
reasons to point an antenna at the sky...




Again? If you don't know .. don't tag it. But don't deny others from 
adding stuff they do know.


Don't know that a road is closed in winter? then don't tag it.
Know that a road is closed in winter - tag it.
Come across an open road in summer that is tagged closed in winter ... 
and you want to verify the closure? Come back in winter or contact the 
relevant mapper.


The most common antenna people see are TV antennas, most pople know what 
they are and can tag them at least the basics. Next would be mobile 
phone antennas. After that they are not so well known, most would have 
to look them up to find out what they are.






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

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Tobias Knerr]

On 05.03.19 01:01, Nick Bolten wrote:
> What would you think
> of a new 'associatedStreet'-style relation that would organize the
> various features that should be associated between streets and the
> surrounding environment?

That approach could work, yes – and it's one of the few practical
options I can think of at the moment. (The other would be drawing an
area:highway polygon around all the individual ways.)

Unlike associatedStreet, which contains all street ways sharing the same
name and can thus contain networks of essentially unbounded complexity,
these relations should probably only span the stretch between two
junctions, though.

While I would want to cobble together a proof of concept implementation
to be sure that I'm not overlooking anything, such a relation would
probably to solve the issue from a data consumer point of view. Of
course, it would have to actually be used by mappers to be helpful.

> Just to clarify, the road can keep all of its same data as is currently
> mapped. This would be an additional piece of information that tends to
> go unmapped.

In theory, the two approaches could peacefully coexist as long as tags
for kerbs, parking:lane etc. on the street ways themselves (and
highway=crossing nodes) remained available after drawing the separate
ways – at the cost of duplication and therefore additional maintenance.

There are some hurdles, though. Even mapping just sidewalks as a
separate way tends to break stuff. For example, people understandably
connect incoming footways only to the sidewalk way, not to the street
way. So an application that filters out these separate ways, hoping to
instead rely on tags on the street way, will find itself with missing
connections to the pedestrian network.

Of course, connecting the sidewalk to the highway with a relation would
likely offer a solution to that issue, too.

Tobias

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

Re: [Tagging] RFC rewritten proposal Via_ferrata_simplified

[Richard]

On Tue, Mar 05, 2019 at 05:09:31PM +0100, egil wrote:
> The 3 main goals of this proposal are:
> 
> 1. the removal of the special tag highway=via_ferrata,

highway=via_ferrata is supported by almost all renderers(*) and you will
break them.
Not only is there no need to remove it but it is highly counterproductive.

via_ferrata_scale on a highway=path would be considered (yet another) troll 
tag so that would be a step back.

Both tags are marked in use since a long time, just let people map whatever 
they want.

(*) Those which are targeted for outdoor users display it and those targeted for
general audience deliberately don't

Richard

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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 19:07, Jarek Piórkowski  wrote:

>
> Again, frankly - approximately zero general-purpose apps will support
> whatever scheme we could come up with in OpenStreetMap to tag the
> situation "this stop is served by a route that has two separate
> timetables that are both valid, and is also served by another route,
> and here are the links to PDFs of these three timetables".


If we don't come up with a sensible tagging scheme we can guarantee that no
app
will support it.

Yes, url=* would work for a timetable.  But what if we also want to link to
GTFS?  What if a user
clicks on a url=* expecting a timetable and gets a GTFS?  Let's make it
user- and app-friendly,
not user- and app-unfriendly.  It costs us nothing to have specific keys
for these things (except
the time spent arguing here) and has no downside; going with url=* and
finding out later
that it was a bad idea would cause problems.

Routes do exist with more than one operator.  They've happened around here
in the past when
the county council wanted to split subsidized routes between two
operators.  I also encountered
such routes between a large town and a city when both population centres
had town/city
councils who ran their own bus services, on the route between the two
localities.  I encountered
it in a large city after government deregulation meant that a national
operator and the city's own
bus service competed on some routes to nearby commuter villages.

So even if we restrict this to routes and don't put it on stops, we need to
handle the case where two
(or more) operators put up partial timetables or partial GTFS data.  This
isn't an edge case, it's
what happens.  Again, the cost of dealing with it now (even if it's rarely
needed) is minimal; the
cost of changing it later (if we find it's not a rare thing) will not be.
Bad tagging decisions never
die, and they rarely fade away.

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

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

On Tue, 5 Mar 2019 at 13:35, Paul Allen  wrote:
> But I'd prefer we have specific keys for
> timetables and GTFS data rather than rely upon either of those.  Much better 
> to make things clear
> with timetable=* and gtfs=* (except we have to deal with partial 
> timetables/feeds from operators
> who both run the same route, so we'll need something fancier than that).

Again, frankly - approximately zero general-purpose apps will support
whatever scheme we could come up with in OpenStreetMap to tag the
situation "this stop is served by a route that has two separate
timetables that are both valid, and is also served by another route,
and here are the links to PDFs of these three timetables". So for
these edge cases skip a long discussion, be bold, and just go with
whatever seems to make some sense. And use the time saved to create a
GTFS file instead :)

+1 on the rest of your message.

--Jarek

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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 17:37, Jarek Piórkowski  wrote:

>
> If your use case is people using the query tool on
> https://openstreetmap.org to follow links to PDFs to plan a journey,
>

Might be a PDF or a simple web page or a Web 2.0 page with funky effects
and even live
updates.  Sadly, given the stupidity of the operators around here, the URL
changes every
time the timetable is updated.

then whatever tagging specification you use doesn't really matter as
> long as it's understandable to the people viewing it - a link looks
> like a link so that's quite easy.


Yes, humans will be OK with whatever key is used as long as the query tool
turns
values that look like URLs into links (which is what it appears to do).
However, it's
nice if we have something consistent and distinct from either website=* or
url=*
which may have other application for the route (or stop, if we add this
information to
stops).  It's always better to make it clear what a link is for than rely
on "that's
a link to something, perhaps it's a timetable."  Especially if we want to
be able
to link to both timetables (for humans) and GTFS data (for apps).

For that matter, for the 10-trips-a-day routes, if you're willing to put in
> the manual

effort, you can probably put the departures into a "departures" tag on the
> stop and it'll be useful when someone queries the stop - the proposal
> got rejected so it's not official guidance, but it doesn't have to be
> official for you to add it and for people to view it.
>

It's not useful on many routes.  Like ones where there's a different
timetable for Saturdays,
no service on Sundays, and one or two of the departures change on school
holidays.  Here
are the codes applying to the T5 route near me:

Sch   Schooldays only
FSVia Fishguard High School on schooldays
S+H Saturday and school holidays only
A  Via Pembrokeshire College on college days
S  Via Aberaeron School on schooldays
SAT  Operates Saturdays only
Col  Connects with College buses
L  Via Llanbadarn Road
HS   Drops off High Street, doesn't drop off at Bus Station
LCVia Llanbadarn Campus, Aberystwyth
X50  Journey destination shows X50, not T5.
T1Change onto T1 service at Aberaeron
FHConnection at Fishguard Square for 410 Fishguard Harbour
FSVia Fishguard School [is this different from the FS above?]
C  Timed to meet with T1 at Aberaeron
cb Connection with Cardi Bach

Actually, it's a little more complex than that. There are other annotations
too.
https://www.richardsbros.co.uk/wp-content/uploads/2018/10/T5-October-2018.pdf

General-purpose transit apps need a machine-readable data format and
> for better or worse, GTFS is the least bad and by far most widespread
> one we've got. Everything else is proprietary, horrible to work with
> (XML SOAP and the like), or both. I know that NaPTAN data got imported
> in some regions of London a good couple of years back, but I really
> draw your attention to the "last modified 2013" in the DfT page you've
> linked - GTFS won and the world has moved on, even Germans are
> starting to publish transit open data as GTFS now.
>

I'm glad GTFS won.  That means we can ignore the NaPTAN stuff.

Where we don't have GTFS, but want to have machine-readable and
> widely-machine-understood timetables for public transit systems,
> building a GTFS file seems a far better option than inventing yet
> another standard within OSM.
>

That seems the best option to me.  It's the primary reason I voted down the
departures
proposal.  There are even sites that give you tools to do that and host it
for you.  Much better
than trying to shoehorn all that into an OSM value.

> I'd use website=* for domains like www.foo.com but url=* for a specific
> page within a website.
>
> I'm not familiar with tagging guidance that suggests this,



>From https://wiki.openstreetmap.org/wiki/Key:url

This tag is being used for very different types of content - official
websites of an amenity or its operator, third-party pages, the object's
Wikipedia entry, photographs featuring the object, or even documentation on
the OSM wiki. So it is advised not to use this tag when more specific
alternatives are available such as website...

So if there's a whole website about an object I use website=* but if it's a
single page within a website
I use url=*.  It's not mandatory (nothing is) but it's what I do.  But I'd
prefer we have specific keys for
timetables and GTFS data rather than rely upon either of those.  Much
better to make things clear
with timetable=* and gtfs=* (except we have to deal with partial
timetables/feeds from operators
who both run the same route, so we'll need something fancier than that).

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

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

Paul,

If your use case is people using the query tool on
https://openstreetmap.org to follow links to PDFs to plan a journey,
then whatever tagging specification you use doesn't really matter as
long as it's understandable to the people viewing it - a link looks
like a link so that's quite easy. For that matter, for the
10-trips-a-day routes, if you're willing to put in the manual effort,
you can probably put the departures into a "departures" tag on the
stop and it'll be useful when someone queries the stop - the proposal
got rejected so it's not official guidance, but it doesn't have to be
official for you to add it and for people to view it.

But that will never be consumed by transit apps not specialized to a
given area, so the benefit of worldwide standardization is very very
slim.

General-purpose transit apps need a machine-readable data format and
for better or worse, GTFS is the least bad and by far most widespread
one we've got. Everything else is proprietary, horrible to work with
(XML SOAP and the like), or both. I know that NaPTAN data got imported
in some regions of London a good couple of years back, but I really
draw your attention to the "last modified 2013" in the DfT page you've
linked - GTFS won and the world has moved on, even Germans are
starting to publish transit open data as GTFS now.

Where we don't have GTFS, but want to have machine-readable and
widely-machine-understood timetables for public transit systems,
building a GTFS file seems a far better option than inventing yet
another standard within OSM.

> I'd use website=* for domains like www.foo.com but url=* for a specific page 
> within a website.

I'm not familiar with tagging guidance that suggests this, though
everyone may tag as they like, and in the end the tagging doesn't
really matter as any tags on stops that give URLs to HTML or PDF
timetables or departures will not be used by general-purpose transit
apps.

--Jarek

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

Re: [Tagging] tagging laboratories

[Jmapb]

On 3/5/2019 2:48 AM, Volker Schmidt wrote:

... and then there are big research centres that are called 
"laboratory". Like LLNL or Los Alamos National Laboratory.



These sorts of things I've seen tagged as amenity=research_institute.

https://wiki.openstreetmap.org/wiki/Tag:amenity=research institute

J


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

[Tagging] Possibility to draw parking properties as an area

[yo paseopor]

Moment has arrived.
I need the use of the tagging scheme into a separated items (not only the
highway itself) to make possible the draw of specific parking areas (or
spaces if it is specified) in the streets with their properties exactly
drawn as areas or ways.
I assume also the position about the use of some relation called
associatedStreet to "join" the different items we talk last days: the road
itself,the parking area (if it is) the cycleway it is associated, the kerb,
the sidewalk, the traffic signs...and so on.

What do you think?
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC rewritten proposal Via_ferrata_simplified

[Mateusz Konieczny]

> In the case of OSM Carto the smart thing may be to not render paths that

I am against proposals attempting to dictate how things should be rendered,
in specific renderers.

Can I recommend rephrasing it to a more neutral
"data consumers can choose hadle specially (hide, avoid in routing, display 
differently) paths that"
?

Note that in any case "vote on wiki demanded to change rendering" will not 
automatically result in changing rendering anyway.

> Implies

I would encourage explicit tagging of wheelchair=no and similar, at least at 
start
via_ferrata=yes will be rarely used and more general tags would be useful.

Mar 5, 2019, 5:09 PM by e...@riseup.net:

> The 3 main goals of this proposal are:
>
> 1. the removal of the special tag highway=via_ferrata,
> 2. encouraging tagging of via ferratas as routes and
> 3. general improvement of the data about via ferratas in OSM via new keys.
>
> I welcome any comments and suggestions for improvements. Voting is scheduled 
> in few weeks.
>
> Cheers
> pangoSE
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Via_ferrata_simplified 
> 
>
> ___
> 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] RFC rewritten proposal Via_ferrata_simplified

[egil]

The 3 main goals of this proposal are:

1. the removal of the special tag highway=via_ferrata,
2. encouraging tagging of via ferratas as routes and
3. general improvement of the data about via ferratas in OSM via new keys.

I welcome any comments and suggestions for improvements. Voting is 
scheduled in few weeks.


Cheers
pangoSE

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

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

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

[Mateusz Konieczny]

Mar 5, 2019, 2:37 PM by matkoni...@tutanota.com:

> Mar 5, 2019, 1:47 PM by > pelder...@gmail.com > :
>
>> Landcover now has about 170 000 usage count.
>>
>> Still growing rapidly despite not yet being rendered on OSM Carto. 
>>
>> I would say that is enough reason to start renderin landcover on OSM Carto 
>> and other renderings. 
>>
> Just usage count is generally not enough to render anything anywhere.
>
> Is it actually used by mappers or blindly added by botlike edits to existing 
> landuse=forest/natural=wood?
>
> But such rendering discussion is offtopic here - please report and discuss it 
> rather on issue trackers of
> specific renderings (open a new issue or comment in existing one if someone 
> created one already).
>
For OSM Carto I posted comment with specific topics for research:
https://github.com/gravitystorm/openstreetmap-carto/issues/2548#issuecomment-469685609
 

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

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

[Mateusz Konieczny]

Mar 5, 2019, 1:47 PM by pelder...@gmail.com:

> Landcover now has about 170 000 usage count.
>
> Still growing rapidly despite not yet being rendered on OSM Carto. 
>
> I would say that is enough reason to start renderin landcover on OSM Carto 
> and other renderings. 
>
Just usage count is generally not enough to render anything anywhere.

Is it actually used by mappers or blindly added by botlike edits to existing 
landuse=forest/natural=wood?

But such rendering discussion is offtopic here - please report and discuss it 
rather on issue trackers of
specific renderings (open a new issue or comment in existing one if someone 
created one already).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

Landcover now has about 170 000 usage count.

Still growing rapidly despite not yet being rendered on OSM Carto.

I would say that is enough reason to start renderin landcover on OSM Carto
and other renderings.
Once it renders, usage of landcover=[trees|grass|scrub] will grow even
faster. Other values are mentioned less often, these three would do nicely
for now.

Many small areas of grass, trees and scrub within residential areas can be
tagged as landcover patches, without breaking up the landuse or tagging
landuse over landuse.

Fr gr Peter Elderson


Op di 5 mrt. 2019 om 13:08 schreef Andy Townsend :

>
> On 05/03/2019 11:48, Marián Kyral wrote:
> > landuse=grass -  means that there will be landuse (grass) on landuse
> > (residental). Is this OK? I'm not sure If I want to create a lots of
> > multipolygons because of this.
> >
> >
> Yes, renderers normally do sane things in cases such as this.  In any
> case the actual OSM tag is irrelevant by the time it gets to the
> renderer, so landuse vs landcover makes no difference if the renderer
> handles both.
>
> What would be a problem would be if anyone were to assume that "every
> place is part of one and only one landuse polygon" but that isn't the
> case for OSM now anyway.
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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] amenity=police

[Mateusz Konieczny]

Mar 5, 2019, 12:59 PM by grimpeu...@gmail.com:

> I imagined that all public-facing police stations be tagged as:
>
> police=station
> operator=(Bundespolizei/Straż Miejska etc.)
> opening_hours=*
> ...
>
> Police barracks would then be
>
> police=barracks
> operator=*
> ...
> And an administrative building could be
>
> police=administration
> operator=*
> opening_hours=*
> ...
>
>
> As amenity=police is currently being used indiscriminately for almost all 
> police-related facilities, we would have to review all police buildings 
> manually anyways to differentiate police stations and other units. In the 
> long run, I would therefore get rid of amenity=police altogether (and thus 
> decongestionate the "amenity"-tag a bit).
>
That works quite well! Some comments:

For administrative building I would really use office tag.

I see no value in dropping amenity=police, even in far future.
I see no harm whatsoever in supposed "congestion" and breaking all data 
consumers
using amenity=police would not be nice.

I am not sure about using operator for police type, in some cases it may cause 
conflicts with
normal use of operator tag.

Maybe police:type?

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

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

[Andy Townsend]

On 05/03/2019 11:48, Marián Kyral wrote:
landuse=grass -  means that there will be landuse (grass) on landuse 
(residental). Is this OK? I'm not sure If I want to create a lots of 
multipolygons because of this.



Yes, renderers normally do sane things in cases such as this.  In any 
case the actual OSM tag is irrelevant by the time it gets to the 
renderer, so landuse vs landcover makes no difference if the renderer 
handles both.


What would be a problem would be if anyone were to assume that "every 
place is part of one and only one landuse polygon" but that isn't the 
case for OSM now anyway.


Best Regards,

Andy



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

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

[Mateusz Konieczny]

Mar 5, 2019, 12:48 PM by mky...@email.cz:

> landuse=grass -  means that there will be landuse (grass) on landuse 
> (residental). Is this OK?
>
Perfectly fine. If something is both grass and residential area then this 
tagging is perfectly fine.

In the same way as forested industrial area may be within two landuse=* areas or
forested residential areas may be withing two landuse areas.

With landuse=recreation_ground we may have even place that belong to three 
landuse=* areas
at once :)



In the same way we may have

natural=cave_entrance node
in
natural=water area
in
natural=sinkhole area

Something similar should be possible also with amenity and leisure tags.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Sergio Manzi]

On 2019-03-05 12:48, Marián Kyral wrote:
>
> -- Původní e-mail --
> Od: Mateusz Konieczny 
> Komu: Tag discussion, strategy and related tools 
> Datum: 5. 3. 2019 12:35:28
> Předmět: Re: [Tagging] leisure=common replacement for public areas with some 
> trees
>
>
>
>
>
> Mar 5, 2019, 11:48 AM by s...@smz.it:
>
> Hi!
>
> On 2019-03-05 11:13, Mateusz Konieczny wrote:
>
>
> Mar 5, 2019, 9:00 AM by mky...@email.cz :
>
> Typically a small areas in the city between apartment 
> buildings. These areas are not official parks, gardens or grass. It is just a 
> green accessible for everoyne. So we can say it is a *public* or *common* 
> green.
>
> So far I usually tagged such places as follows:
>
> Made sure that it is within landuse=residential (as it is a 
> residential area)
> Mapped physical features (leisure=playground, natural=tree, 
> landuse=grass, highway=footway etc)
>
> Is it land*use*=grass or land*cover*=grass? I tend to agree with 
> Alessandro Sarretta who uses landcover...
>
> landcover=grass also would be fine in this case, but meaning of this tags 
> is the same and
> landuse=grass is more popular
>
>
> landcover=grass - still not rendered: 
> https://www.openstreetmap.org/way/402959582
>

Thanks for hinting about landcover=grass not being rendered (/I guess we should 
open a Github issue for that if one doesn't exist already.../).


> landuse=grass -  means that there will be landuse (grass) on landuse 
> (residental). Is this OK? I'm not sure If I want to create a lots of 
> multipolygons because of this.


As I already mentioned in a different context, I think the correct technique 
would be to be to just draw one multipolygon (/the "main" one, probably tagged 
with landuse=residential in this case/), and then create a new relation, 
containing just the "main" multipolygon, and tag that relation with the 
secondary landuse.


> Marián




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=police

[Jan S]

Am Di., 5. März 2019 um 12:46 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

>
>
>
> Mar 5, 2019, 12:17 PM by grimpeu...@gmail.com:
>
> I would hence suggest to introduce a new tag "police" with keys like
> "station", "administration", "criminal police", "barracks", "range",
> "naval_base" (for river police or coast guard), etc. The type of police
> could then be tagged as "operator=*"
>
> "police=station" should be defined as comprising all police stations of
> the lowest level, where you can turn to in case of an emergency, no matter
> whether the operating entity is formally a civil or a military one. Other
> areas or buildings, like barracks, ranges, administrative units etc. could
> then be tagged as "police=*" or "military=*", according to the
> classification of the operating force.
>
> Any thoughts on this?
>
> I would tag office with internal police administration with some office=*
> tag, without amenity=police
>
> We should not tag Tesco headquarters as shop, we should not tag government
> office
> maintaining canals as waterway=canal and we should not tag government
> office
> managing police as amenity=police
>
> Similarly, police laboratory, range, barracks, academy, warehouse should
> also should not be
> tagged amenity=police.
>
> But police tag makes sense, just do not require or request to always add
> also amenity=police.
>
> I would keep amenity=police to public-facing police places.
>
> To values of police tag - there is also municipal police (in Poland called
> "Straż Miejska"
> that is usually mostly handling illegally parked vehicles and minor
> disturbances like
> drunk people).
>
> So also police=municipal?
>
> BTW, I would not mix police type (municipal, state, military, etc) with
> object type (naval_base,
> administration, barracks, range) in one key.
>
> Thanks for commenting!

Maybe my post was confusing.

I imagined that all public-facing police stations be tagged as:

police=station
operator=(Bundespolizei/Straż Miejska etc.)
opening_hours=*
...

Police barracks would then be

police=barracks
operator=*
...
And an administrative building could be

police=administration
operator=*
opening_hours=*
...

As amenity=police is currently being used indiscriminately for almost all
police-related facilities, we would have to review all police buildings
manually anyways to differentiate police stations and other units. In the
long run, I would therefore get rid of amenity=police altogether (and thus
decongestionate the "amenity"-tag a bit).

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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 01:41, Jarek Piórkowski  wrote:

>
> On Sat, 2 Mar 2019 at 19:42, Paul Allen  wrote:
> > As I said, I'd prefer not to use url=* because it could be for anything
> - a page about the history of
> > the bus stop (maybe the shelter is a listed building),
>
> That would rather be website=* though.


Not necessarily.  I'd use website=* for domains like www.foo.com but url=*
for a specific page
within a website.

And to keep it simple, you can do a lot worse than putting an "upcoming
> buses from this
>
stop" page URL into the website=* for vast majority of stops out there. Only
> problem is that doesn't scale very nicely to 1 stops.
>

There are other problems.

1) Many services around here don't have an "upcoming buses from this stop"
page.  We're lucky
they've finally managed to put the timetables on the web.

2) Upcoming buses are useful if you find yourself stranded near a bus
stop.  If you're planning
a future journey you want a timetable.

3) You can always figure out the upcoming buses if you have a timetable;
you cannot figure out
the timetable from upcoming buses.

> or a timetable or whatever web page the
> > mapper happened to think relevant.  I'd prefer to distinguish between a
> human-readable timetable
> > and raw GTFS data (not really human-readable but could be parsed by an
> app).  For lack of anything
> > better, I'd be happy with timetable=* and gtfs=* but I expect somebody
> will be along shortly to explain
> > why those are a very bad idea.
>
> I'd be happy with gtfs= on a possibly high-level
> relation that ultimately includes stops, and timetable= or
> departures= on stops where available as HTML page.
>

Again, "upcoming buses" just doesn't cut it for me.  Great for big towns
and cities.  Not so good
for rural routes.  Great for when you're unexpectedly stranded near a bus
stop.  Not so good for
planning a journey  in advance.

I think the Berlin tagging makes sense:
> https://osm.org/node/1137469153 with website=http://qr.bvg.de/h309003.
> Other pages I'm familiar with are
> https://nb.translink.ca/text/stop/50167 or
>
> http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N&Stop=n.b._on_Shaw_St_at_King_St_West_North_Side&Stops=timed


I'm not sure what point you were making there.  They're web pages, not
tagging schemes. If
you wanted me to admire the pretty web pages, that's nice.  If you want to
see what I have to
put up with, here's what one operator has:
https://www.richardsbros.co.uk/wp-content/uploads/2018/08/408-sept-2018.pdf
and here's the
county council's version of the same route (showing more stops):
https://www.ceredigion.gov.uk/media/4410/408.pdf
There is no "next 3 buses" info.  These pages are not updated live.
They're just PDFs.

>From Canadian English perspective, "timetable" would be more likely to
> be interpreted as all departures for the whole week (as on the TTC
> page). "departures" matches the "next 3 buses" case a bit closer. But
> perhaps it's different in British English.
>

>From the perspective of a Brit who uses (but doesn't operate) buses, that
sounds about right.
Where we differ is which is most useful.  We probably need tags for both
(for when both
are available), rather than leave it to the mapper to decide.

> Whatever we go for, we have to cater to the fact that a particular route
> may have more than one
> > operator (I'm not talking about super-routes here).  Around here there
> are many small local operators,
> > and longer routes sometimes split the service between two operators
> (i.e., the route X to Y might
> > be split between an operator based in X and another operator based in Y).
>
> GTFS as a format is operator agnostic (the operator information is not
> in the data at all, only "agency", but each route must be tied to
> exactly one agency). It is more of a question whether a full timetable
> is provided in a given GTFS file or if it is a partial timetable and
> we want to support merging timetables.
>

Good question.  On the routes I have in mind, the county council and one
operator
provided full timetables but the other operator provided a partial
timetable.  The operator
who provided full timetables has managed to produce broken GTFS for some
routes
(it works, but the answers it gives are silly).  I have seen no indication
that the county council
has even heard of GTFS.

What I have seen in transit data collection is one physical stop
> served by multiple agencies which provide separate GTFS files, and
> sometimes they reference the stop using different stop IDs. But in
> that case it would be using different routes, and it should be doable
> with ref:=123 + ref:=abc (where agency_1 and
> agency_2 preferably match the GTFS agency IDs...)
>

Ummm, wouldn't that mean GTFS data about every route by that agency?

However, you've made me abandon hopes of adding this information to stops.
Yes, it
means more steps when using the query tool on standard carto, and some
users won't
be able to handle that, but trying to cater

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

[Marián Kyral]

-- Původní e-mail --
Od: Mateusz Konieczny 
Komu: Tag discussion, strategy and related tools 
Datum: 5. 3. 2019 12:35:28
Předmět: Re: [Tagging] leisure=common replacement for public areas with some
trees
"










Mar 5, 2019, 11:48 AM by s...@smz.it:

"
Hi!


On 2019-03-05 11:13, Mateusz Konieczny wrote:

"



Mar 5, 2019, 9:00 AM by mky...@email.cz(mailto:mky...@email.cz):

"
Typically a small areas in the city between apartment buildings. These areas
are not official parks, gardens or grass. It is just a green accessible for
everoyne. So we can say it is a *public* or *common* green.

"
So far I usually tagged such places as follows:





Made sure that it is within landuse=residential (as it is a residential 
area)


Mapped physical features (leisure=playground, natural=tree, landuse=grass,
highway=footway etc)

"
Is it landuse=grass or landcover=grass? I tend to agree with Alessandro
Sarretta who uses landcover...

"
landcover=grass also would be fine in this case, but meaning of this tags is
the same and


landuse=grass is more popular

"



landcover=grass - still not rendered: https://www.openstreetmap.org/way/
402959582

landuse=grass -  means that there will be landuse (grass) on landuse
(residental). Is this OK? I'm not sure If I want to create a lots of
multipolygons because of this.




Marián

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

Re: [Tagging] amenity=police

[Mateusz Konieczny]

Mar 5, 2019, 12:17 PM by grimpeu...@gmail.com:

> I would hence suggest to introduce a new tag "police" with keys like 
> "station", "administration", "criminal police", "barracks", "range", 
> "naval_base" (for river police or coast guard), etc. The type of police could 
> then be tagged as "operator=*"
>
> "police=station" should be defined as comprising all police stations of the 
> lowest level, where you can turn to in case of an emergency, no matter 
> whether the operating entity is formally a civil or a military one. Other 
> areas or buildings, like barracks, ranges, administrative units etc. could 
> then be tagged as "police=*" or "military=*", according to the classification 
> of the operating force.
>
> Any thoughts on this?
>
I would tag office with internal police administration with some office=* tag, 
without amenity=police

We should not tag Tesco headquarters as shop, we should not tag government 
office 
maintaining canals as waterway=canal and we should not tag government office 
managing police as amenity=police

Similarly, police laboratory, range, barracks, academy, warehouse should also 
should not be 
tagged amenity=police.

But police tag makes sense, just do not require or request to always add also 
amenity=police.

I would keep amenity=police to public-facing police places.

To values of police tag - there is also municipal police (in Poland called 
"Straż Miejska"
that is usually mostly handling illegally parked vehicles and minor 
disturbances like 
drunk people).

So also police=municipal?

BTW, I would not mix police type (municipal, state, military, etc) with object 
type (naval_base, 
administration, barracks, range) in one key.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Mateusz Konieczny]

Mar 5, 2019, 11:48 AM by s...@smz.it:

>
> Hi!
>
> On 2019-03-05 11:13, Mateusz Konieczny  wrote:
>
>>
>> Mar 5, 2019, 9:00 AM by >> mky...@email.cz >> :
>>
>>> Typically a small areas in the city between apartment  buildings. 
>>> These areas are not official parks, gardens or  grass. It is just a 
>>> green accessible for everoyne. So we can  say it is a *public* or 
>>> *common* green.
>>>
>> So far I usually tagged suchplaces as follows:
>>
>> Made sure that it is withinlanduse=residential (as it is a 
>> residential area)
>> Mapped physical features(leisure=playground, natural=tree, 
>> landuse=grass,highway=footway etc)
>>
>
> Is it land> use> =grass or land> cover> =grass? I tend to  agree with 
> Alessandro Sarretta who uses landcover...
>
>
landcover=grass also would be fine in this case, but meaning of this tags is 
the same and
landuse=grass is more popular

>
> I also have doubts about leisure=playground as it is not a  physical 
> feature but it describe the usage done of that space, not  its 
> characteristics.
>
>
I use leisure=playground solely for cases where it clearly describes a  
physical feature
Something like 
https://commons.wikimedia.org/wiki/File:Aire_de_jeux_en_2017_(20).jpg 

I am not advocating for entire to be tagged as playground, just parts that are 
playgrounds
(the same with natural=tree, landuse=grass,highway=footway - such things
should be tagged only where this features are)

>  Also that very same space could be used for  different things (> fairs, 
> concerts, rallies, etc.> ) at  different times...
>
Sounds like landuse=recreation_ground or leisure=park to me.

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

Re: [Tagging] amenity=police

[Jan S]

Am Fr., 1. März 2019 um 18:55 Uhr schrieb Greg Troxel :

> Martin Koppenhoefer  writes:
>
> > I wonder what we call "police" in OSM.
> >
> > The wiki does not offer a lot of guidance (France aside): "A police
> station
> > is a building where police officers and other staff work and are
> dispatched
> > from, and where suspects and evidence are collected and processed."
> > https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpolice
> >
> > Is this limited to civil police forces, or does it include military
> forces?
> > The French seem to include the Gendarmerie (military force under the
> > jurisdiction of the Ministry of the Interior), and similarly we include
> the
> > Carabinieri in Italy (adding also landuse=military).
>

I have looked at some police facilites in my area and must admit that I am
now even more confused about how to map them.

Here in Germany, there are two main police forces, the 16 state polices and
the federal police. Also, in some cities there is a municipal police, which
are usually uniformed members of the city administration who are not
allowed to recur to the use of force. Still, they do some minor policing
tasks. There's also a military police, but afaik their competences are
restricted to issues within the military forces.

Here in Frankfurt for example, the municipal police station is tagged as
"amenity=police" and "operator=Stadtpolizei" (
https://www.openstreetmap.org/way/440792258), which to me is fine. State
and federal police stations are also tagged as "amenity=police" albeit
without the "operator" tag (e.g. https://www.openstreetmap.org/way/440792258
for a federal police station and
https://www.openstreetmap.org/node/401296942 for a state police station).
That's also fine, I guess, although the "operator" tag might be helpful.

However, other facilities of the state police, like barracks for special
units, are also tagged as "amenity=police" (
https://www.openstreetmap.org/way/55342341), although they don't attend the
public at all. And even stranger, barracks of the federal police are tagged
as "military=barracks" (https://www.openstreetmap.org/way/4537958),
although since the Federal Border Protection Service (Bundesgrenzschutz)
has been transformed into the federal police in the 1990s, it has lost its
combatant status under international law and today clearly is a civil
police force.

In France, I've checked only one Gendarmerie site, where the area has been
tagged as "landuse=military" but the Gendarmerie station on the area, where
the public is attended, has been tagged as "amenity=police" (
https://www.openstreetmap.org/way/47840959). However, the barracks of the
Compagnie Républicaine de Sécurité at Strabourg are also mapped as
"amenity=police", although there doesn't seem to be a post to attend the
public, either.

The combination of "office=government" and "government=police" is hardly
used at all in Germany and France (which is not surprising at all, given
that taginfo only returns 75 instances at all).

In consequence, I don't see that the current way of tagging police
facilities was useful for several reasons:

1) Police facilities are tagged as "amenity=police", indiscriminately of
whether one can go there in an emergency or not. Even purely administrative
units which don't attend the public at all receive the same tag as common
police stations.

2) The police has a variety of facilites, similar to the military forces,
that cannot be currently differentiated.

3) There is a confusion about what to tag as "police" and what to tag as
"military".

I would hence suggest to introduce a new tag "police" with keys like
"station", "administration", "criminal police", "barracks", "range",
"naval_base" (for river police or coast guard), etc. The type of police
could then be tagged as "operator=*"

"police=station" should be defined as comprising all police stations of the
lowest level, where you can turn to in case of an emergency, no matter
whether the operating entity is formally a civil or a military one. Other
areas or buildings, like barracks, ranges, administrative units etc. could
then be tagged as "police=*" or "military=*", according to the
classification of the operating force.

Any thoughts on this?

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

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

[Sergio Manzi]

Sorry, my answer was meant to regard the "common replacement" (topic of the 
thread) more than the situation described by Marián for which "playground" is 
probably OK...

On 2019-03-05 11:48, Sergio Manzi wrote:
>
> Hi!
>
> On 2019-03-05 11:13, Mateusz Konieczny wrote:
>>
>> Mar 5, 2019, 9:00 AM by mky...@email.cz:
>>
>> Typically a small areas in the city between apartment buildings. These 
>> areas are not official parks, gardens or grass. It is just a green 
>> accessible for everoyne. So we can say it is a *public* or *common* green.
>>
>> So far I usually tagged such places as follows:
>>
>> Made sure that it is within landuse=residential (as it is a residential area)
>> Mapped physical features (leisure=playground, natural=tree, landuse=grass, 
>> highway=footway etc)
>
> Is it land*use*=grass or land*cover*=grass? I tend to agree with Alessandro 
> Sarretta who uses landcover...
>
> I also have doubts about leisure=playground as it is not a physical feature 
> but it describe the usage done of that space, not its characteristics. Also 
> that very same space could be used for different things (/fairs, concerts, 
> rallies, etc./) at different times...
>
> TBH I don't have an answer to the problem, but I tend to agree that we 
> should, A) describe the physical characteristics of the place, and, B) 
> describe the fact that the place is of public interest...
>
>
>> Maybe one may also add access tag to landuse=residential to tag it as a 
>> public?
>> AFAIK this is not commonly done at this moment, but I see nothing wrong with 
>> it.
>
> Sergio
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Sergio Manzi]

Hi!

On 2019-03-05 11:13, Mateusz Konieczny wrote:
>
> Mar 5, 2019, 9:00 AM by mky...@email.cz:
>
> Typically a small areas in the city between apartment buildings. These 
> areas are not official parks, gardens or grass. It is just a green accessible 
> for everoyne. So we can say it is a *public* or *common* green.
>
> So far I usually tagged such places as follows:
>
> Made sure that it is within landuse=residential (as it is a residential area)
> Mapped physical features (leisure=playground, natural=tree, landuse=grass, 
> highway=footway etc)

Is it land*use*=grass or land*cover*=grass? I tend to agree with Alessandro 
Sarretta who uses landcover...

I also have doubts about leisure=playground as it is not a physical feature but 
it describe the usage done of that space, not its characteristics. Also that 
very same space could be used for different things (/fairs, concerts, rallies, 
etc./) at different times...

TBH I don't have an answer to the problem, but I tend to agree that we should, 
A) describe the physical characteristics of the place, and, B) describe the 
fact that the place is of public interest...


> Maybe one may also add access tag to landuse=residential to tag it as a 
> public?
> AFAIK this is not commonly done at this moment, but I see nothing wrong with 
> it.

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-05 11:14, Warin wrote:

> On 05/03/19 20:08, Jean-Marc Liotier wrote:
>> On Mon, March 4, 2019 11:20 pm, Warin wrote:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
>> This is a way to solve most of the problem, but it fails the "map it as I
>> see it" test.
>>
>> man_made=antenna + antenna:reflector=dish does map the satellite
>> communications antenna I just spotted... But what the naïve mapper I am
>> really wants is man_made=antenna + antenna=dish (or
>> monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !
>>
>> Then one can add antenna:propagation, antenna:application,
>> antenna:propagation, antenna:polarisation etc. but they are accessory.
>>
>> Am I mistaken in believing that the main tags chain should focus on
>> offering a straightforward way to map the apparent physical features,
>> rather than invisible distinctions ? Not that invisible distinctions are
>> not welcome too - but they should stay out of the way.
>
> Sympathies!
>
> An alternative is available ...
>
> man_made=antenna
>
> dish=yes

So far, so good.


> cross_gain_feed=yes

What does that mean? I'm a licensed radio amateur (/for more than 30 years/) 
and I never heard of that term... :-/


> two_way=yes

Prove that!


> satellite=yes

Prove that! Because it points at the sky? There are many other good reasons to 
point an antenna at the sky...


> --
> This does open it up for adding 2 things that are mutually exclusive eg
> yagi=yes
> monopole=yes
>
> but in other respects is easier to use.


Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-05 10:08, Jean-Marc Liotier wrote:
> On Mon, March 4, 2019 11:20 pm, Warin wrote:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
> This is a way to solve most of the problem, but it fails the "map it as I
> see it" test.
>
> man_made=antenna + antenna:reflector=dish does map the satellite
> communications antenna I just spotted... But what the naïve mapper I am
> really wants is man_made=antenna + antenna=dish (or
> monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !
>
> Then one can add antenna:propagation, antenna:application,
> antenna:propagation, antenna:polarisation etc. but they are accessory.
>
> Am I mistaken in believing that the main tags chain should focus on
> offering a straightforward way to map the apparent physical features,
> rather than invisible distinctions ? Not that invisible distinctions are
> not welcome too - but they should stay out of the way.

+1!

As far as I'm concerned, lack of observability and/or lack of verifiability are 
a no-go for inclusion in OSM!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Warin]

On 05/03/19 20:08, Jean-Marc Liotier wrote:

On Mon, March 4, 2019 11:20 pm, Warin wrote:

https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use

This is a way to solve most of the problem, but it fails the "map it as I
see it" test.

man_made=antenna + antenna:reflector=dish does map the satellite
communications antenna I just spotted... But what the naïve mapper I am
really wants is man_made=antenna + antenna=dish (or
monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !

Then one can add antenna:propagation, antenna:application,
antenna:propagation, antenna:polarisation etc. but they are accessory.

Am I mistaken in believing that the main tags chain should focus on
offering a straightforward way to map the apparent physical features,
rather than invisible distinctions ? Not that invisible distinctions are
not welcome too - but they should stay out of the way.


Sympathies!

An alternative is available ...

man_made=antenna

dish=yes

cross_gain_feed=yes

two_way=yes

satellite=yes

--
This does open it up for adding 2 things that are mutually exclusive eg
yagi=yes
monopole=yes

but in other respects is easier to use.





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

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

[Mateusz Konieczny]

Mar 5, 2019, 9:00 AM by mky...@email.cz:

> Typically a small areas in the city between apartment buildings. These areas 
> are not official parks, gardens or grass. It is just a green accessible for 
> everoyne. So we can say it is a *public* or *common* green.
>
So far I usually tagged such places as follows:

Made sure that it is within landuse=residential (as it is a residential area)
Mapped physical features (leisure=playground, natural=tree, landuse=grass, 
highway=footway etc)

Maybe one may also add access tag to landuse=residential to tag it as a public?
AFAIK this is not commonly done at this moment, but I see nothing wrong with it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] leisure=common replacement for urban public areas in Africa

[Jean-Marc Liotier]

The openstreetmap-carto rendering of leisure=common was recently dropped
(https://github.com/gravitystorm/openstreetmap-carto/commit/4df96c4e4927c3e029b31e34c0cf1be2dda6f637).

In Mali and Senegal, I had found leisure=common to be an expedient way to
describe explicitly designed publicly accessible undeveloped
municipality-owned open dirt areas in cities, public squares in the barest
sense, used for gatherings, impromptu soccer games and more generally as
breathing space in a dense urban fabric: it is dedicated to leisure and it
is a common area...

But it did stray a bit from the original British vernacular meaning, which
was akin to landuse=village_green in that the commons are normally grass
covered. So I usually combined leisure=common with surface=ground or
surface=sand to express the African reality... But still - this bends the
concept quite far out of its original shape.

So, though we do not map for the renderer, maybe this is a good time to
find a better tag to map that feature.

My candidate is
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Drecreation_ground - and
now that I think about it, I wonder why I didn't use it to begin with.

As I'm the author of a good many leisure=common in Mali and Senegal, my
near-term goal about them is to replace occurrences of leisure=common with
the better term but only in Mali and Senegal.

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

Re: [Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

[althio]

Tobias Knerr:

> Can we please first define a solution (e.g. a relation) for connecting
> such separately mapped components of a road to the highway?
>
> Painting lines next to each other fails to express the important
> information that this kerb/sidewalk/cycleway is part of that highway
> over there. Such missing information may be easily guessed by a human
> viewer, but it's currently not available in a machine-readable form.
>

If they are next to each other, you have already some of the information
because we use a geographic database with coordinates of the "painted
lines" (and not a pure relational database).
I would say that 99%+ of cases could be treated automatically once data is
loaded in a geographic tool like a pgsql-PostGIS database.
Advanced PostGIS users, please correct me if I am wrong.

Some points are also made in
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

> The "relations" [...] are meant to model a close (and usually local)
relation between objects, [...] as in: These fifteen parts together make up
so-and-so road. [...] Our database is a spatial database; this means that
it has intrinsic knowledge about the location of objects. [...] A good
example for a valid and useful grouping is the "route
" relation, where
multiple ways are connected to form a cycle route or a walking route or
something else; a way may be part of any number of routes so this cannot be
solved by tagging the way with "route
=xxx".

Other than that, you already have relation tools existing if you absolutely
need them, you could either pick or extend
https://wiki.openstreetmap.org/wiki/Relation:street or
https://wiki.openstreetmap.org/wiki/Relation:associatedStreet
Although it feels like that are needed for edge cases of addresses only.
I do not think we need relations at the moment to assign a pavement, a
kerb/curb, a lamppost unambiguously to a street. These objects are related
to the nearest highway or the nearest crossing between several highways
(use buffers accordingly in the pre-treatment).

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

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

[Marián Kyral]

-- Původní e-mail --
Od: Warin <61sundow...@gmail.com>
Komu: tagging@openstreetmap.org
Datum: 5. 3. 2019 10:04:46
Předmět: Re: [Tagging] leisure=common replacement for public areas with some
trees
"

Usually the cover  does not follow the 'use' 100% so map them individually,
the tree area separate from grass, flowers, rock etc.
natural=wood for the tree area
natural=bare_rock for rocks
man_made=flower_bed for flowers

"



It seems like landuse=flowerbed is used more often even it is not approved
nor rendered: https://wiki.openstreetmap.org/wiki/Proposed_features/
flowerbed




Marián







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

Re: [Tagging] "satellit"

[Jean-Marc Liotier]

On Mon, March 4, 2019 11:20 pm, Warin wrote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use

This is a way to solve most of the problem, but it fails the "map it as I
see it" test.

man_made=antenna + antenna:reflector=dish does map the satellite
communications antenna I just spotted... But what the naïve mapper I am
really wants is man_made=antenna + antenna=dish (or
monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !

Then one can add antenna:propagation, antenna:application,
antenna:propagation, antenna:polarisation etc. but they are accessory.

Am I mistaken in believing that the main tags chain should focus on
offering a straightforward way to map the apparent physical features,
rather than invisible distinctions ? Not that invisible distinctions are
not welcome too - but they should stay out of the way.

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

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

[Alessandro Sarretta]

On 05/03/19 09:50, Marián Kyral wrote:


-- Původní e-mail --
Od: Marián Kyral 
Komu: tagging@openstreetmap.org
Datum: 5. 3. 2019 9:02:03
Předmět: [Tagging] leisure=common replacement for public areas with 
some trees



What about e.g.: landuse=public_green? It could be also extended
by tags like trees=yes, scrub=yes or public_green=grass /
public_green=flowers.


One more thing: Should we use landuse there? As these areas are 
usually inside of landuse=residental? Maybe use leisure=public_green 
instead?


I would suggest to use landcover=grass 
 and maybe 
access=yes


m2c

Ale

--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

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

[Warin]

On 05/03/19 19:00, Marián Kyral wrote:

Hi,
recently was dropped [1] the leisure=common rendering from 
openstreetmap-carto as it is "misused" by mappers. A suggested 
replacements are: *leisure=park, landuse=grass and/or 
landuse=farmland*. But there are many places around, that are not 
official park and not grass as there are some trees as well. Typically 
a small areas in the city between apartment buildings. These areas are 
not official parks, gardens or grass. It is just a green accessible 
for everoyne. So we can say it is a *public* or *common* green.


So question is, how to tag it? There is also tag landuse=village_green 
[2], but I don't like the word "village" there and as well, there are 
plans to remove it, because it has the same issue as leisure=common.
On landuse=village_green wiki, there is a nice sentence: *Such use of 
the tag is incorrect, and a better tagging for these situations needs 
to be defined.*


So is the right time to do it now? What tag/tags we should use for 
such pieces of green that are too small or to be a park, are not a 
garden and are public accessible.


What about e.g.: landuse=public_green? It could be also extended by 
tags like trees=yes, scrub=yes or public_green=grass / 
public_green=flowers.


Separate things...

Land use

verses

Land cover

Try not to mix them up.

Usually the cover  does not follow the 'use' 100% so map them 
individually, the tree area separate from grass, flowers, rock etc.

natural=wood for the tree area
natural=bare_rock for rocks
man_made=flower_bed for flowers

Grass is unfortunate in that most tag it as a 'landuse=grass' when it is 
actually 'landcover=grass'. I use both tags, one for the render the 
other for clarity.
Concrete has no primary tag .. so I'd use landcover=concrete, it will 
not render. If it is a pedestrian way then tag the area as 
highway=pedestrian, surface=concrete.


Public? That is an access thing ... and as everyone has access there is 
no need to add a tag access=* - so leave it off and be happy.


Now the problem of land use.
A small areas in the city between apartment buildings is not a 'common'. 
Nor a 'park'.
I would simply say it is part of the residential area .. and leave it at 
that. So landuse=residential if it is not already part of a greater 
landuse=residential area.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Marián Kyral]

-- Původní e-mail --
Od: Marián Kyral 
Komu: tagging@openstreetmap.org
Datum: 5. 3. 2019 9:02:03
Předmět: [Tagging] leisure=common replacement for public areas with some
trees
"
What about e.g.: landuse=public_green? It could be also extended by tags
like trees=yes, scrub=yes or public_green=grass / public_green=flowers.


"



One more thing: Should we use landuse there? As these areas are usually 
inside of landuse=residental? Maybe use leisure=public_green instead? 




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

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

[Marián Kyral]

Hi,

recently was dropped [1] the leisure=common rendering from openstreetmap-
carto as it is "misused" by mappers. A suggested replacements are: *leisure=
park, landuse=grass and/or landuse=farmland*. But there are many places
around, that are not official park and not grass as there are some trees as
well. Typically a small areas in the city between apartment buildings. These
areas are not official parks, gardens or grass. It is just a green
accessible for everoyne. So we can say it is a *public* or *common* green.




So question is, how to tag it? There is also tag landuse=village_green [2],
but I don't like the word "village" there and as well, there are plans to 
remove it, because it has the same issue as leisure=common.

On landuse=village_green wiki, there is a nice sentence: *Such use of the
tag is incorrect, and a better tagging for these situations needs to be 
defined.*





So is the right time to do it now? What tag/tags we should use for such 
pieces of green that are too small or to be a park, are not a garden and are
public accessible.




What about e.g.: landuse=public_green? It could be also extended by tags
like trees=yes, scrub=yes or public_green=grass / public_green=flowers.




What do you think? Some better idea?






Thanks,

Marián




[1] https://github.com/gravitystorm/openstreetmap-carto/commit/4df96c4e4927c
3e029b31e34c0cf1be2dda6f637

[2] https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dvillage_green


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