Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Lionel Giard]

At the moment, the tagging scheme for charging station ask to indicate
capacity (for number of charging point) and socket (for the type of socket
like CCS or slower charging standard, and the respective number of each)
and socket power (ex a ccs charger with 350 kW max power) is also indicated
if fully mapped. All these tags can be used to count the number of charging
points with as many filters as we want (like do want to know fast charging
only or something like that).

So the *capacity *tag reflects the n*umber of simultaneous charging
vehicles possible*. The *socket *(and subtag for it) reflects the type of
charging plug available and the power it can give.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - EV Charging Station Mapping

[Lionel Giard]

The idea behind clarifying the amenity=charging_station for a place where
there is one or more charge points, is that we use the same idea for
amenity=fuel where it just shows the place where there is one or more fuel
pump. Also most of the time for charging station in my area, it was already
tagged assuming that.

And it also seems logical to use "man_made" category to tag the individual
charge points as we do for fuel pumps.

At least, it would just be consistent between various similar tagging
schemes.

Regards,
Lionel

Le jeu. 30 mars 2023 à 10:47, Marc_marc  a écrit :

> Hello,
>
> Le 30.03.23 à 10:25, NKA mapper a écrit :
> > The definition of amenity=charging_station will change slightly and will
> represent both locations with a single charge point and locations with a
> group of chargers. A new optional feature, man_made=charge_point will be
> created to separate detailed mapping of each charge point from the main
> amenity amenity>=charging_station feature at locations.
>
> I disapprove the idea of changing the meaning of "in use" tag.
> we already have what you want :
> - a charging station : amennity=charging_station
> - a site of charging station relation type=site
>
> Regards,
> Marc
>
>
>
> ___
> 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] site relations for city walls?

[Lionel Giard]

In the parking example that i talk about, the multipolygon is not usable if
i want to indicate the specificity of each part of the parking lot like
capacity or capacity:disabled (as the tagging is global for every outer
part). I like the site relation as it allows to also group the vending
machine or the amenity=parking_entrance for underground parking (as a car
park may have both underground + overground parkings). I find a site
relation more practical in such cases and I never used it technically for
malls with only overground parkings (but that was in the original proposal
example i think ^^).

My use case was more about the underground parking where I grouped all the
parking_entrance (both pedestrian and for vehicle) with a "site=parking"
relation. One example is this one :
https://www.openstreetmap.org/relation/8425228#map=18/50.66911/4.61226
(there are one vehicle entrance, one vehicle exit, multiple pedestrian
entrance/exit and few vending machines for it). *Do you have a better way
of tagging this ? ^^*
I just used what i found on the wiki at the time, and it was clean in my
opinion. :-p

Le mer. 15 juil. 2020 à 09:35, Martin Koppenhoefer 
a écrit :

> Am Mi., 15. Juli 2020 um 01:40 Uhr schrieb Paul Allen  >:
>
>> On Tue, 14 Jul 2020 at 23:44, Matthew Woehlke 
>> wrote:
>>
>> The multipolygon is just ammenity=parking, but the sub-objects are
>>> tagged with more information (capacity, in particular). Again, is that
>>> sane, or do I need to do this differently?
>>>
>>
>> Doesn't look sane at present.  You have combined one public parking area
>> with two private ones.  If they're all private, for use by the
>> restaurant, mark
>> them all as private.
>>
>
>
> if they are for the clients of the restaurant, the typical tagging is
> access=customers
> Also you should not have 2 objects amenity=parking which cover the same
> area (regardless of additional tags).
>
>
>
>>
>> Even so, is a multipolygon giving any information that couldn't be had
>> by separate parking areas with the appropriate operator tag?
>>
>
>
> +1, this is what I would choose, no relation at all. It is also what you
> can probably argue for "on the ground": two parkings operated by the same
> business, not one parking spread over 2 areas.
>
>
>
>
>>
>> (BTW, is there any accepted way to tag a 'carry-out only' space?)
>>>
>>
>> If you're talking about one (or both) of those parking areas by the
>> restaurant, then it is (or they are) not really a parking area.  I'd
>> probably make it a closed way with highway=service + area=yes
>> and then risk the wrath of purists by naming it "Pick-up Zone".
>>
>
>
> there is the "maxstay" tag which can be used with a value like 5 or 15
> minutes.
> https://taginfo.openstreetmap.org/keys/maxstay#values
>
> Cheers
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] site relations for city walls?

[Lionel Giard]

>
> Wouldn't a multipolygon with just two outers solve that parking case?
> Best Peter Elderson
>

That's a bit of a stretch of the multipolygon definition as there is no
inner ring.  I never used multipolygon for anything else than complex
geometry (with inner ring(s)) and that seems to be what the feature is for.

As we already have the site relation for grouping features that are part of
the same thing, but disjoint, i think that it is good to use it. It also
solves the problem when mappers use multipolygon for two polygons sharing
the same edge (it is forming an invalid geometry), while with site relation
it is not a problem. Another advantage is that it is quite easy to edit.
You just need to add or remove a feature : no specific roles (yet) or order
needed.

Le lun. 13 juil. 2020 à 23:29, Volker Schmidt  a écrit :

>
>
> On Mon, 13 Jul 2020 at 22:56, Martin Koppenhoefer 
> wrote:
>
>> actually all of these could be „grouped“ with tags alone, e.g distributed
>> museums could have an identifying „network“ tag (or sth similar).
>>
> But why invent a new network tag, if we have  a site relation, waiting to
> be used. (I was thinking of open air museums, where the various exhibits
> are spread over the landscape)
>
>> For power plants a site might be appropriate, if an area does not do it
>> and you don’t want to rely on only tags.
>>
> If you have ever looked at the complexities of a hydro-power-plant with
> dams, lakes, pipes, turbines deep in the mountains or in dedicated
> buildings . they are really complex, and only parts of it are visible on
> the surface.
>
>> In theory objects like the Great Wall in China can and should be modeled
>> as areas, although they seem to be linear in nature, they are also thick
>> enough to „require“ an area representation in order to be well mapped in
>> the scale of OpenStreetMap (you can walk on it).
>>
> That's not true - you can walk on parts of it, other parts are completely
> missing, others are heaps of stones.
>
>> In practice we would also want a way to have preliminary mapping as a
>> line, and mixed geometry relations. A multipolygon relation for all parts
>> of the great wall would likely be broken every day, and would be over the
>> member limits for relations.
>>
> It's not a multipolygon - it is bits and pieces, some connected, same not.
> Some may be linear (in first approximation).
>
>
>> Would those that are in favour of using a site relation for a linear,
>> circular, interrupted structure, 19km long and some meters wide, also see
>> it as a good relation type for the Chinese Great Wall?
>>
> You lost me with your question here.
>
> Volker
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_8037950653339377666_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] site relations for city walls?

[Lionel Giard]

I also saw it used for parking lot that are completely separated (like on
two sides of a big highway) but still part of the "same" parking
technically (like the example of mall parking in different parts separated
by highways). To add to the two area mapped as amenity=parking, there was a
site relation grouping them (site=parking).  ^_^

Le lun. 13 juil. 2020 à 19:04, Volker Schmidt  a écrit :

> Looking back at the history of the site relation, it looks as if the
> concept originated from schools, colleges, universities, airports,  and
> military bases for situations where the objects are not within a well
> defined perimeter. Documented uses include historical sites, even though
> they are not quoted in recent versions of the wiki page.
>
> Reading the wiki versions, I would say the "site" relation is extremely
> vaguely defined.
>
> I would think we are free to make it something useful.
>
> At the risk of repeating myself, I believe there is a need  for something
> like the site relation for a whole array of more or less widely scattered
> objects that belong together. Just a few:
>
>- non-campus universities, research institutions, schools
>- the offices of public institutions (city, regional, country
>governments, the European Union institutions)
>- archaeological sites (aqueducts, Hadrian's Wall, the Limes in
>Germany, the Great Wall of China, The Iron Curtain, city walls, former
>Railways, former canals and other waterways, former underground mines, ...)
>- power plants (hydro-electric, wind power, ...)
>- active mines
>- distributed museums
>
> Volker
>
>
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-7074691897933095803_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] site relations for city walls?

[Lionel Giard]

The aurelian walls left today are not one continuous element, so the site
relation is practical as it allows to group all the linear or area features
that are forming the old city walls.
I used many time in cities when few ruins of the same original object exist
at different places (often walls), so you can clearly link them together
with this relation. ^_^

Best Regards,
Lionel

Le lun. 13 juil. 2020 à 09:00, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > On 13. Jul 2020, at 05:59, Yves  wrote:
> >
> > Why do you say "A site means things are concentrated around a point",
> sites relation helps to map disjoint elements, but I don't think I saw
> anything about their repartition.
>
>
> it is my interpretation of the term “site” and a kind of proposal to
> modify the site relation description in the wiki
>
>
> > Also it certainly makes no sense to have sites extending over extremely
> large areas.
>
>
> at least not if they aren’t “compact”
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Refining heritage tag

[Lionel Giard]

In my experience of mapping heritage stuff (mainly in Belgium), i never
found any case where i would need to re-use the scheme
*ref:=* *(where
the "" is the group of letter given by the other tag
*heritage:operator=*) for another thing (and it was always
comprehensible, as all other subtag of the heritage around here are based
on this "" value).

And seeing heritage:ref:operator seems less logical to me as it would not
directly indicate that it is a "ref" value in that tag (as the ref is not
the first word). But it may just be subjective. ^_^

Le mar. 21 avr. 2020 à 01:58, Paul Allen  a écrit :

> On Tue, 21 Apr 2020 at 00:30, António Madeira 
> wrote:
>
>> As I already wrote before in this thread, lutz already agreed with and
>> supported my proposal.
>>
>
> Then you don't have to worry about it being rendered.  That's one of your
> questions dealt with.
>
> My problem with the actual ref tag is that there are many ref tags for
>> other schemes and elements, but I don't know if this concern is pointless
>> or not.
>> I would like to see this scheme more organized and not so ambiguous data
>> wise, but I don't know if that's technically better or if there are actual
>> problems with ref tag being "all over the place".
>>
>
> As it stands, there is a possibility for namespace collision. That is
> theoretically
> a problem.  An object might have two references, but we've made heritage
> references take the form ref:xxx=* so if the other ref is of the form ref=*
> there won't be a collision.  But it's also possible that both schemes want
> to use ref:xxx.  So adding heritage to the ref key fixes that remote
> possibility.
>
> As it stands, overpass queries would not be able to distinguish the right
> ref
> if an object has a heritage ref:xxx=yyy and a non-heritage ref:aaa=bbb.  A
> remote possibility.  Adding heritage to the ref key fixes it.
>
> One downside is lutz having to support two different ways of tagging
> heritage refs, probably in perpetuity as I doubt they'll all be upgraded.
> But he's agreed to your scheme so he doesn't see it as a significant
> problem.
>
> Another downside is that some people dislike long keys.  Even if
> they're keys they never use and never will use.
>
> --
> Paul
>
> ___
> 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] Updating definition and description of place=square

[Lionel Giard]

If we take the key "place=*", all the values are only related to toponym :
place=city/town/village/neighbourhood/locality/... They all are just the
name of a location of some type (either defined by population or other
aspect like an ocean/sea/...). So the place=square tag seems to be the only
one that both indicate a location with a name (or not) and a feature. If we
were only using place=square to indicate the name of a location categorized
as a "square", then, maybe we do need another tag just to describe what the
open area is... (man_made=square for example) ? And by using place=square
only for naming a location, it can probably be on a polygon with other tag
without problem (it is just indicating the toponym and the area covered -
as it can be useful for routing), or on a node (like we do for other
place=* tag).

Regards,
Lionel

Le mar. 24 mars 2020 à 13:13, Martin Koppenhoefer 
a écrit :

> Am Di., 24. März 2020 um 03:33 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> > Place=square was defined until 3 days ago as “a
>> > named square” and “a town or village square which is an open space
>> common in
>> > urban centres, typically crossed by streets but can also be a pedestrian
>> > area or more rarely green areas.”
>> >
>> > I am perfectly fine with this documented definition
>>
>> But the first part wasn't a definition. "A named square" is not a
>> defintion at all, since the word "square" is undefined.
>
>
>
> is it? The English wikipedia has an article "Town square"
> https://en.wikipedia.org/wiki/Town_square and tries to give a definition
> (although the article is in bad shape and also has a warning that the
> affirmations are not backed by citations, and it links to articles in other
> languages which have different definitions, and which may be partial, due
> to these other languages having several similar concepts). Also the article
> states that "Other names for *town square* are *civic center
> *, *city square*, *urban
> square*, *market square *, 
> *public
> square*, *piazza *, *plaza
> *, and *town green*." but these are
> not all 1:1 synonymous.
>
> Oxfordlearnersdictionary also has a definition: " [countable] an open
> area in a town, usually with four sides, surrounded by buildings"
>
> We did not so far define the words "street" or "road". It is taken as
> granted in the highway tag definitions that you know what it is.
>
>
>
>> If this means
>> "a feature that includes the word "square" in the name" as the page
>> suggested back in 2015-2016 this is even worse, since it is completely
>> culturally determined. I would be justified to tag all "alun-alun"
>> feature as squares, even those that are 100% soccer pitch now, and
>> those function as a walled palace garden.
>>
>
>
> whether and how many of all objects with "square" (and similar) in the
> name are actually the kind of object we are tagging with place=square will
> likely depend on the culture and language. If this works for Italy with all
> (or almost) piazza, piazzale, piazzetta, largo, campo, it does not imply it
> works in Indonesia as well.
>
>
>
>> The first second definition was a little better: " an open space
>> common in urban centres..."
>>
>
>
> yes, but it implies a certain kind of urbanism, in particular how centers
> and peripherical areas look like, and I believe it is not universally
> applicable (if it is intended to exclude squares in the outskirts).
>
>
>
>> Though this could be used for a leisure=pitch or leisure=park or
>> leisure=garden or an amenity=parking, or a fenced-off roundabout
>> etc...
>>
>
>
> no, the place=square can hardly be the same area as a leisure=pitch or
> leisure=park. You won't have the park cover the whole area and end at the
> buildings, there'll be a way or street along the buildings.
>
>
>>
>> But then the second half of the definition offers several more
>> possibilitiies:
>> "typically crossed by streets" - That one is unclear, does it mean a
>> street intersection/ road junction? Most mapped place=squares are NOT
>> crossed by streets, it turns out.
>>
>
>
> it may depend how you define "street" and "crossed". I guess it includes
> pedestrian streets, and crossed may also be seen as "at the borders". If
> you read it like this, there won't be many examples that do not fit (can
> you post one?).
>
>
>
>>
>> "But can also be a pedestria area or more rarely green areas.”
>>
>> A highway=pedestrian area is certainly a type of open public space, so
>> that is fine, and the most classic squares fit that definition.
>>
>
>
> although not all pedestrian areas are squares. It could also be a parking
> (sadly).
>
>
>>
>> But what does "more rarely green areas" mean? Is a green area just a
>> flat, mowed lawn, or can it be an elaborate garden with trees, knolls,
>> ponds? Can it be a leisure=pitch? Can it 

Re: [Tagging] Please fix unnamed square tagging / was: ... description of place=square

[Lionel Giard]

My only problem with "fixing unnamed place=square" is that i know at least
2 locations where the village center open area is definitely a place=square
(i.e. an open area with some car parks, and open just in front of the
church that was historically the place for gathering people but also cattle
(and now used for people, cars, market, village gathering,...)) *but they
have no name, it is just an open area.* We just refer it to the "Place"
(literally "Square" in french), and sometimes we say "Place du village"
(Village square). Do you think that adding the name = "Place" is preferable
? It might be what we want even if it is not official ? Or would you map it
otherwise, maybe place=locality (but it seems wierd to me) ? :-)

Regards,
Lionel

Le lun. 23 mars 2020 à 06:26, Joseph Eisenberg 
a écrit :

> > the keywords from the preset translation
>
> Yes, thank you. (Sorry, I use a satellite internet connection, so iD
> doesn't work too well for me):
>
> "Praça ou largo: Praça, praceta ou largo: espaço numa zona urbana,
> normalmente sem edifícios (apenas a volta desta), que constitui um
> espaço público aberto"
>
> This translates back to English as (approximately):
> "Praça, praceta or largo: space in an urban area, usually without
> buildings (except for around it), which constitutes a public open
> space"
>
> This definition is taken from the Data Item
> https://wiki.openstreetmap.org/wiki/Item:Q6077 - where it is by far
> the most complete definition.
>
> Most of the others are just "A named square" translated into the local
> language:
>
> Una plaza con nombre.
> Une place nommée.
> Piazza.
> Pojmenované náměstí
> Ein öffentlicher Platz
>
> I'll update this to the new definition from the English page.
>
> I've also created an Indonesian page, which gives a couple examples of
> "alun-alun" in Indonesia which fit the definition:
>
> 1)
> https://upload.wikimedia.org/wikipedia/commons/thumb/a/ac/Alun-alun_Garut.jpg/400px-Alun-alun_Garut.jpg
>
> 2)
> https://upload.wikimedia.org/wikipedia/commons/thumb/d/d4/Alun_-_Alun_Bandung_Masjid_Raya_Bandung.jpg/400px-Alun_-_Alun_Bandung_Masjid_Raya_Bandung.jpg
>
> But there are many other alun-alun that are grassy urban parks, not
> squares:
>
> A)
> http://4.bp.blogspot.com/-zpwpVxKz0q0/UXoUmFzUAXI/BpI/brIHP9_dQQY/s400/images.jpg
>
> B)
> https://commons.wikimedia.org/wiki/File:Alun-alun_Tugu_-_Bunder_-_panoramio.jpg
>
> C)
> https://commons.wikimedia.org/wiki/File:Square_Trenggalek_-_Alun-Alun_Trenggalek_-_panoramio_(10).jpg
>
> -- Joseph Eisenberg
>
> On 3/23/20, António Madeira  wrote:
> > When you say description, are you referring to the definition from the
> > wiki, or the keywords from the preset translation?
> > This?
> > https://i.imgur.com/Id8xOaJ.png
> >
> > Or this?
> > https://i.imgur.com/tXXb0Yr.png
> >
> >
> > Às 22:25 de 22/03/2020, Joseph Eisenberg escreveu:
> >> So in iD does it just show "uma praça" as the description for
> >> place=square?
> >>
> >> -- Joseph Eisenberg
> >>
> >> On 3/23/20, António Madeira  wrote:
> >>> In Portuguese it's "Praça", similar to Piazza, which comes from the
> >>> Latin "platea".
> >>> Depending on its size and location, it can be named officially as
> >>> "Praça", "Largo"or "Praceta".
> >>>
> >>> The English description of place=square in iD is empty.
> >>>
> >>> https://i.imgur.com/AIqEuuC.png
> >>>
> >>>
> >>>
> >>> Às 21:41 de 22/03/2020, Joseph Eisenberg escreveu:
>  Curious: what is the translation used in Portuguese?
> 
>  Do you also know the English description of place=square used in iD?
> 
>  On 3/23/20, António Madeira  wrote:
> > I agree that the place=square needs some kind of polishing, specially
> > regarding name tag, which should be mandatory.
> > In Portugal, the definition of square can have three meanings,
> > depending
> > on its size and region, but it's easy to map them because they all
> > have
> > name.
> >
> > The problem with iD can be its translation/localization. The
> > Portuguese
> > community had to discuss what was the best translation so that
> newbies
> > could get it right more often via iD.
> > Maybe this must be done also in Germany.
> >
> >
> > Às 10:46 de 22/03/2020, Tom Pfeifer escreveu:
> >> Yes there is inconsistent use of place=square, in particular for
> >> _unnamed_ objects.
> >> As the place=* key is used to indicate that a particular location is
> >> known by a particular name,
> >> a place=* tag without a name is fundamentally wrong.
> >>
> >> (As the world is not black and white, there might be exceptions.)
> >>
> >> In Germany alone I found >600 such taggings, and all I probed were:
> >>
> >> 1. not squares as in the definition, but small and insignificant
> >> paved
> >> surfaces, like a round piece of footway in a park, the service yard
> >> of
> >> a fire station, or similar.
> >>
> >> 2. they were all added 

Re: [Tagging] amenity=faculty?

[Lionel Giard]

The site relation was originally created for groups of features : power
plant (wind turbine nodes spread over the land or sea), historical sites
(often only some element (one tower, one building, ...) are historic and
not the entire place) and parking (especially underground parking with only
entrance mapped) spread over multiple locations. It fit exactly what is an
university spread over a city or multiple places. The word "site" may be
wrong, but that was the one chosen there and could be changed i suppose (i
don't care for the word used myself ^_^). But creating a new relation type
which would be with the same specification than a site relation would be a
bit weird to me. It is overly complex for the usage no ? As the only
interest is to have one feature in OSM that group all the university part
and get all the university attribute. Is that really important that it is
called "site" instead of "institution" ? :p

In any case, it would be interesting to define it correctly in the wiki so
other mappers can find a "how to map" (either on site relation or a new
relation if more people are in favour for that). :-)

Le jeu. 6 févr. 2020 à 12:13, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > Il giorno 6 feb 2020, alle ore 11:37, Volker Schmidt 
> ha scritto:
> >
> > Sorry, Martin, but what do you do, if you have a big multi-storey
> building and all you have is the door bell on the street level? Not map it?
>
>
> that’s indeed a problem with multipolygons ;)
> But you wouldn’t call something a „site“ either that is, hm, many sites,
> would you?
>
>
>
> > The Tuebingen example illustrates the problem. The relation has two
> nodes in a multipolygon as outer? That is not kosher either.
>
>
> Yes, the Tübingen example is far from perfect, it was just an illustration
> for a university with many locations, but there are many details that are
> not kosher (e.g. the streets are not part of the campus, at least the
> unrestricted, public ones, also the nurse residences could be questioned,
> while the library arguably consists also of the grounds, not just the
> building, etc.)
>
> Do we need another kind of relation? If we want an object for the
> university, maybe yes. Adding just a tag like university= the university> on all the parts would maybe do the trick as well? It
> wouldn’t allow for adding details about the university though (e.g.
> start_date, alt_name, wikipedia/wikidata, website, operator, etc.).
>
> Either we could say, a university in or around the same town, seen on a
> global level, is still a “site”, although on the local level it would be
> seen as several sites.
> Or we’d make a more generic kind of new relation for things that belong
> together under a certain point of view (together they form an institution,
> for example public city offices also belong to the same institution and are
> often distributed over the city, or on a national level ministries and
> agencies, there we’re doing it with admin level. For pt routes, there are
> specific route master and network relations.
> Time for an university relation? Or more generically a “type=institution”
> relation?
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=faculty?

[Lionel Giard]

One problem with multipolygon relation is that by definition you can't
put *node
*it those and you can't put *contiguous buildings* either. How do you group
"node + polygons + multipolygon" (some buildings are a multipolygon already
where the hole is not part of the university ^_^) with other thing than a
site relation ? If you have any suggestion feel free to share as i never
find anything else (and we already discussed it in the past on this mailing
list, always to say "okay it is the best fit for the time being"). :-)

You can't put big polygon around these things either, as many of these
"city university" don't own the ground around the building (they are really
in the middle of the city spread across it) and as you said, many parts are
only an "office" in a building shared with other companies or services (so
only nodes in OSM).

Le jeu. 6 févr. 2020 à 02:58, Joseph Eisenberg 
a écrit :

> > ... put the tag "amenity=university" and all the information only 1 time
> for the whole university
>
> > I would generally just use a multipolygon relation for this
>
> +1 for the common multipolygon relation, not type=site.
>
> ___
> 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=faculty?

[Lionel Giard]

Site relation are more used to put the tag "amenity=university" and all the
information only 1 time for the whole university when it is spread across a
city or multiple sites. This site relation equal to the amenity=university
area under a campus that's all grouped into one place. Otherwise, if you
query the data, you'll see many amenity=university (which means multiple
universities) that are exactly the same which is wrong. But i don't see how
it solve the subdivision either.

I also map the building name or ref as what the university use in general,
and put node "POI" for school or institute if they are officially located
there in one place (or if you could argue that their main office is there).


Le mer. 5 févr. 2020 à 22:55, Graeme Fitzpatrick  a
écrit :

> You also have the problem of different Schools sharing the same building.
>
> With the Uni I'm familiar with, in one case you have the Clinical Sciences
> building 1, which holds 3 lecture theatres, plus the School of Nursing &
> the School of Pharmacy.
>
> It's currently mapped as "G16 - Clinical Science 1", which is how the Uni
> refers to it.
>
> & that Uni, incidentally, is spread over 5 separate campuses across 2
> cities!
>
> Thanks
>
> Graeme
> ___
> 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] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Lionel Giard]

In my usage, i always thought that using a barrier=* + any other main tag
was wrong and widely accepted (as i saw that it was separated in most
examples when i started mapping). Thus my method has always been to map
them separately (one way for the barrier and one way for the other main
tag, even if they are exactly sharing the same node). This is in order to
keep the one feature to one object and keep things manageable and without
ambiguity. Thus to me, all the examples of "barrier=*" (+ "area=yes" +)
"leisure=playground" are a tagging error, that should be two separate
objects.

If it is a tagging error, then we don't need to remove the rendering, it
just need to be corrected on the data side by mappers. Am i wrong in
thinking that ?

Le mer. 5 févr. 2020 à 22:43, marc marc  a
écrit :

> Le 05.02.20 à 22:08, Christoph Hormann a écrit :
> > (either 'invalid', '1d barrier' or '2d barrier'):
>
> Here is my view AND I known that osm consensus is not that :
>
> > closed way, barrier=fence
>
> 1d barrier
>
> > closed way, barrier=fence, area=yes
>
> 2d barrier
>
> > closed way, barrier=fence, leisure=playground
>
> bad idea
>
> > closed way, barrier=fence, leisure=playground, area=yes
>
> 2d barrier
>
> > multipolygon, barrier=fence
>
> 2d barrier
>
> > multipolygon, barrier=fence, area=yes
>
> 2d barrier
>
> > multipolygon, barrier=fence, leisure=playground
>
> 2d barrier
>
> > multipolygon, barrier=fence, leisure=playground, area=yes
>
> 2d barrier
>
> > closed way, barrier=hedge
>
> 1d barrier
>
> > closed way, barrier=hedge, area=yes
>
> 2d barrier
>
> > closed way, barrier=hedge, leisure=playground
>
> 2d barrier
>
> > closed way, barrier=hedge, leisure=playground, area=yes
>
> 2d barrier
>
> > multipolygon, barrier=hedge
> > multipolygon, barrier=hedge, area=yes
> > multipolygon, barrier=hedge, leisure=playground
> > multipolygon, barrier=hedge, leisure=playground, area=yes
>
> all : 2d barrier
>
> > closed way, barrier=ditch, waterway=ditch
> > closed way, barrier=ditch, waterway=ditch, area=yes
> > closed way, barrier=ditch, waterway=ditch, leisure=playground
> > closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes
>
> all : same as for barrier=hedge
> ___
> 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=faculty?

[Lionel Giard]

Each country (and maybe university) have different subdivision, and
sometimes even inside one university there are multiple different
subdivision co-existing : for example in Belgium i know at least a few
universities that use two separate division at the same time :

   - for the education part : Université > Faculty > School ;
   - for the research part : University > Sector > Institute.

All of these can overlap. One professor can be part of one (or multiple)
school and institute at the same time. And for buildings, an institute can
be spread across multiple building, sharing space with a school ... It is
not simple and purely administrative as there isn't always an unique
spatial localisation for each institute or school. At the moment, i
sometimes see the institute or school name on the building if it is
generally located in one place. I have also seen many research institute
tagged on a node with "office=research" as they are well known publicly,
but again that's not always the case.

Thus, it seems difficult to find "one" subdivision that will always work
worldwide ?! :-) Maybe that we should keep a generic word and allow
everything in it (like subdivision=* with the name of "School",
"Institute", "College",... if relevant) ?

Le mer. 5 févr. 2020 à 03:24, Jarek Piórkowski  a
écrit :

> On Tue, 4 Feb 2020 at 11:44, Greg Troxel  wrote:
> > Mateusz Konieczny via Tagging  writes:
> > > Universities may have faculties, that often deserved to be mapped
> separately.
> > > ...
> > > It seems to me that amenity=faculty would be useful.
> >
> > Perhaps, but beware that in US English, this is bizarre usage.  Faculty
> > refers to the set of people that are professors, not a place, and not a
> > subdivision of a university.
> > ...
> >
> > I'm sure other universities contain within them colleges, and I suspect
> > "school" is fairly common.
> >
> > Really my point is that "Faculty of mathematics" is going to be
> > confusing to en_US speakers.  I have no idea if it's used in en_GB, but
> > I've never heard of it.
>
> As a counterpoint, at my en_CA university established in 1957 we did
> have faculties in the sense used by Mateusz. Schools were generally
> ordered lower than faculties: School of Architecture was part of
> Faculty of Engineering. Most sub-parts of faculties were named
> Departments.
>
> --Jarek
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Lionel Giard]

That's clearer when we get all the history thank you Joseph ! :-)
I agree with you that the added value of duplicating the key is very
limited, so i understand your edit on the wiki. ^_^

Le mer. 29 janv. 2020 à 14:49, Paul Allen  a écrit :

>
> On Wed, 29 Jan 2020 at 13:34, Joseph Eisenberg 
> wrote:
>
>> I looked up the history again, and it's clear that the healthcare tags
>> which duplicated common amenity tags were never popular until they
>> were added to the iD presets in 2017:
>>
>
> Like it or not, iD has more influence on tagging than this list or carto
> does.  If
> iD decides a certain tag should be used in preference to an alternative,
> or that
> dual-tagging should happen, then that's what happens.  Only in the case of
> very strong objections will iD undo some change it decided to make without
> consultation with anybody else.
>
> As I said, OSM doesn't do joined-up thinking.  It would be nice if it did.
>
> --
> Paul
>
>
> ___
> 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] Deprecate healthcare=pharmacy and healthcare=hospital

[Lionel Giard]

If i understood correctly the objective of the revamping of healthcare is
to change the old way of tagging all these "amenity" (hospital, clinic,
pharmacy, ...) and use the "healthcare" key instead. But at the moment, the
preset is using both tags at the same time. So i'm asking the following
question : "does tagging healthcare=pharmacy ALONE is enough (with any
subtag if needed like dispensing=yes) ?". Theoretically, it should be
correct if i'm understanding the healthcare scheme. Then we could propose
to change the preset in the editor to promote a change of key
(amenity=pharmacy -> health=pharmacy), instead of a simple "duplicating".

@Joseph I think that you are "Jeisenbe" on the wiki ?! :-)
I see that you changed the healthcare wiki page saying that we should use
"amenity" key instead for the 'duplicated values' (clinic, hospital, ),
but as said above, this seems counterproductive as the idea is to slowly
deprecate the amenity tag, not to promote its usage ! :p Is there something
that i am missing here ? ^_^

Le mer. 29 janv. 2020 à 13:26, Joseph Eisenberg 
a écrit :

> > iD also brings up the "suggestion" that existing amenity=clinic,
> pharmacy &
> > (I think) dentist tags by themselves are "incomplete" & should be
> upgraded
> > by adding healthcare=
> > eg https://www.openstreetmap.org/edit#map=21/-28.07641/153.42326
>
> That's interesting. I wonder if there is a way to find what percentage
> of the healthcare=pharmacy tags were added by iD or other editors in
> this way.
>
> ___
> 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] Question about capacity:*=* on parking_space

[Lionel Giard]

Allesandro,

I wasn't speaking about disabled only here, even if it must exist countries
where disabled are marked but not enforced by law, but i don't know any
example. But for other dedicated parking space like "parent" or "electric
charging", there are not many country enforcing them by law, even if they
still are dedicated to these kind of people or users. Thus
capacity:charging=1 for a parking_space dedicated to electric charging is
the only correct way of mapping it (especially since an access tag doesn't
exist for that) and in most country, nothing enforce you legally to not
park there if you want (it is only asked to not park there if you are not
the target group and you don't risk a fine for doing it anyway). Same for
special parking for parent near a supermarket entrance. These are designed
as a large parking space to ease the entry and exit of the car for parents
with small children (and toddler). You can always park there, even it may
be seen as selfish if you don't have any children... ;-)

Le sam. 18 janv. 2020 à 09:23, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > On 17. Jan 2020, at 19:57, Alessandro Sarretta <
> alessandro.sarre...@gmail.com> wrote:
> >
> > If the parking_space with specific symbology is regulated by law and
> only accessible by disabled persons (like in Italy)
>
>
> btw, in Italy disabled parking spaces are accessible by everyone, but only
> disabled people may park there (everybody may halt there, but you may not
> go away and leave your vehicle there)
>
> Cheers Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] EV charging stations questions and proposals

[Lionel Giard]

For motorcar vs car, it seems logical to update it to motorcar as it is the
recommended way of tagging car access, as it is probably just an old wiki
information on the amenity=charging_station. At the same time, should we
use another tag than scouter=* for them ? Because it is not an existing tag
on the access wiki page. Maybe using moped=* + motorcycle=* would be better
and more in line with the access wiki page ?! Same for truck=* which
doesn't exist, but i'm not sure if hgv=* would be the correct one ? How do
we tag a fuel station dedicated to truck ? Because we could use the same
tagging for electric charging that will be available for truck only. I
don't know if any exist yet, but they are coming this year or next year at
least with the new electric truck that start to appear.

To my understanding it is both a device and a place which is confusing.
Maybe we should use the current tagging for the place (similar to
amenity=fuel) and another for the device if needed. Because historically,
there weren't many real "station" like we would have "fuel station". It was
mostly simple charging socket on a place in a parking lot. This is not a
station to me, but a device alone. At the moment, we use
amenity=charging_station both for such socket/device in a parking lot and
for larger station like Fastned station

in the Netherlands, Ionity station or Tesla supercharger. It seems quite
different and maybe we should refine it with one tag for a place looking
like a station (with multiple charging devices) and a tag for just the
device (especially for place like the airport where you can have many
charging socket in a parking that are there to park your car and leave it
charging when you take the plane) - i don't think these place are a
"station".

Le sam. 18 janv. 2020 à 16:26, Mateusz Konieczny 
a écrit :

> 18 Jan 2020, 13:37 by fl.infosrese...@gmail.com:
>
> Hi all,
>
> As we plan to start a new "Project of the month" in France to improve EV
> charging facilities mapping, a few questions raise regarding tagging of
> those amenities.
>
> We want to encourage people to use the established tagging and want to be
> sure we won't do it in the wrong way as well.
>
> Thanks for reviewing tagging and tagging docs as part of that!
>
> amenity=charging_station recommends to use car=* to state the feature is
> accessible by car.
> According to more general highway tagging, motorcar=* is preferred to
> describe such access rules. Should this recommendation evolve to replace
> car=* by motorcar=* for charging stations ?
> Open question on Talk :
> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcharging_station#Vehicles
>
> So charging station for bicycles and charging station for cars is supposed
> to be have the same top tag?
>
> According to official terminology, a station sounds to be a device in a
> pool which refers to the place where you find several devices to charge
> your EV. amenity=charging_station then should refers to individual devices
> and not to whole facilities.
> Can someone confirm this point please?
>
> https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dcharging_station#Is_this_a_device_or_a_place_.3F
>
> I really hope that it is for a place.
> If it is equivalent of tagging every pump separately then we need a new
> tag
> for the entire equivalent of amenity=fuel
>
> ___
> 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] Question about capacity:*=* on parking_space

[Lionel Giard]

Alesandro,

The thing is that disabled=designated is an access (so regulated by law),
and would depend because each country's law vary (not every country enforce
restriction for disabled parking or other type of vehicle...). Thus, it may
be wrong to tag an access when it doesn't exist. While a tag that's only an
attribute describing what type of parking exist, is unambiguous. It may be
parking_space=* or access:*=* , both are "good" for that as they are
unambiguous in their meaning. The only advantage of the second is that it
is already used for amenity=parking and seems coherent to use for the
parking_space in my opinion (even if it is only 1 place). The wiki page
already mention all the different type because there are many other than
disabled (like parent, women, electric charging,...) :
https://wiki.openstreetmap.org/wiki/Key:capacity

marc,

The capacity:*=* tag should not be used alone (as described for any
parking), it is an addition to the capacity=* tag. For example, a place
marked as "capacity=1" and "capacity:disabled=1" means that the 1 capacity
is disabled. A better example is for an amenity=parking, you have a parking
with "capacity=12" and "capacity:disabled=3" it means 3 of the 12 parking
space are disabled.
Theoretically, all parking_space should be capacity=1 (and if necessary
capacity:*=*) but the advantage (as mentioned above) is that it would use
the same tagging than for amenity=parking. Thus we wouldn't use two
different scheme for the same thing.


Le ven. 17 janv. 2020 à 09:52, PanierAvide  a
écrit :

> Hello Lionel,
>
> I totally agree with that, I never understood this special treatment of
> amenity=parking_space, and so I'm using capacity:*=* with that. My use case
> is for disabled people parking spaces : just look for capacity:disabled=*
> and you're good to go, whatever it is a parking or parking_space.
>
> Best regards,
>
> Adrien P.
>
> Le 17/01/2020 à 09:36, Lionel Giard a écrit :
>
> Hello everyone,
>
> I saw that on the parking_space wiki page it says that we shouldn't use
> capacity:*=* on parking_space, and instead use the access tag. But why is
> this the case? It seems logical to use capacity:disabled=* on a
> parking_space for disabled people or capacity:charging=* on a parking_space
> for electric vehicles that are charging. And there is not always legal
> access linked to these "special" parking spaces (e.g. I don't think there
> are many places regulating parking on parents' parking spaces in the law).
> It seems strange to forbid this, while promoting the tagging of
> "capacity=*". ^_^
>
> I therefore propose to change this description to favour this tagging
> (when useful) instead of prohibiting it. What do you think about this?
>
> Kind Regards,
> Lionel
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Question about capacity:*=* on parking_space

[Lionel Giard]

Hello everyone,

I saw that on the parking_space wiki page it says that we shouldn't use
capacity:*=* on parking_space, and instead use the access tag. But why is
this the case? It seems logical to use capacity:disabled=* on a
parking_space for disabled people or capacity:charging=* on a parking_space
for electric vehicles that are charging. And there is not always legal
access linked to these "special" parking spaces (e.g. I don't think there
are many places regulating parking on parents' parking spaces in the law).
It seems strange to forbid this, while promoting the tagging of
"capacity=*". ^_^

I therefore propose to change this description to favour this tagging (when
useful) instead of prohibiting it. What do you think about this?

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

Re: [Tagging] distance_from_road tag

[Lionel Giard]

Yes this is something you can do with any distance algorithm in available
in any GIS tool. That's not something that i would ever map as it would
vary with any geometry change of the ways between the road the point you
measure, added to the fact that it add nothing to explicitly map it (in my
opinion at least). It is essentially what any routing app will calculate
when you ask "find the nearest POI" for example.


Le mer. 15 janv. 2020 à 12:45, Mateusz Konieczny 
a écrit :

> I propose describing distance_from_road tag, defined as
> "distance in meters from nearest road" as a misguided idea that should not
> be used.
>
> https://wiki.openstreetmap.org/wiki/Key:distance_from_road was recently
> created by PangoSE and claims
> "Useful for indicating the distance to nearest road accessible by a
> normal car for people who cannot walk very long because of illness or
> pregnancy but anyway want to get out in nature. "
>
> "I'm quite sure there is a clever GIS way of calculating this using a
> routing engine,
> unfortunately no tool or website has yet been created to easily visualize
> this yet.
> When this is available we could probably get rid of this tag or generate
> its values by bot."
>
> I am 100% sure that such tags are not welcomed and especially bot idea is
> really
> poor, but I want to ask other for confirmation.
> ___
> 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] Incomplete addresses

[Lionel Giard]

In Belgium, the only two mandatory field are "house number" and "street
name", postcode and municipality/city can generally be derived from
administrative boundaries and thus are optional. I see a lot of people
using ID and adding those, as well as the country which is really not
needed (because the country is the one thing that you could always be found
easily as the boundaries are always present). The ID template must not be
taken a mandatory field, but only as a suggestion on what information is
generally useful for this feature (in the entire world, as i think that the
template are not different by countries ?!). :-)

Le mar. 7 janv. 2020 à 08:19, Mateusz Konieczny  a
écrit :

>
> 7 Jan 2020, 02:58 by graemefi...@gmail.com:
>
> I kept finding places with the street number & name entered, often
> together with the post code!, but with no suburb listed?
>
> Obviously, I have no idea which editor was used to map them, but shouldn't
> this sort of thing error to say "Incomplete address entered" or words to
> that effect?
>
> In many places, for example in villages
> and small towns there are no defined
> suburbs (at least in Poland).
>
> Also, in Poland, this is either very subjective
> or can be generated from mapped boundaries.
>
> And anyway is not used for addressing anyway.
>
> So in some places you are unable to tag it,
> in some places there is no good reason to tag this.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag Seveso sites ?

[Lionel Giard]

Seveso sites are all sites identified as source for a "potential major
industrial hazard" (mainly big chemical plant - and it doesn't include the
military or nuclear facilities). It is named after the Seveso disaster of
1976  (Seveso is a town in
Italy) which had a big media coverage and important impact on health in the
area (many animals were slaughtered, and many people affected).

As far as i understand, the seveso directive is based on different
threshold (the threshold depends on the chemical element, the stability of
the product, ...). If it is below the first threshold, it is not a Seveso
site (not at big risk), if it pass the first threshold it is "Low" (low
risk) and if it pass the second threshold it is ranked as "High" (high
risk).

Le ven. 8 nov. 2019 à 10:45, Shawn K. Quinn  a écrit :

> On 11/8/19 03:34, Joseph Eisenberg wrote:
> > What is a Seveso site? The link to the directive on Wikipedia says:
> >
> > “a European Union
> >  directive
> >  aimed at
> > controlling major chemical accident hazards. Seveso III is implemented
> > in national legislation and is enforced by national chemical safety
> > authorities.”
> >
> > Are these chemical hazard sites? Inspection sites?
>
> My first guess is it's at least roughly analogous to a Superfund site in
> the US.
>
> --
> Shawn K. Quinn 
> http://www.rantroulette.com
> http://www.skqrecordquest.com
>
> ___
> 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] Charging stations: socket::output -- which format for the value?

[Lionel Giard]

All electric charging station that i have ever encounter are in "kW" not in
watt (ex: 3 kW, 50 kW, 120 kW, 175 kW...). To me, it is the same as the
maxspeed tag, we don't put it in m/h but in km/h -> we use the common unit
as everyone use it. Thus we don't use the SI value everywhere and that seem
logical, so here it seems ok to me to leave it in kW.

Le mar. 30 juil. 2019 à 04:40, brad  a écrit :

> I don't have an opinion about kw or w, but if the value is only a number,
> then to prevent confusion and reduce mistagging the key should specify,
> output-kw=22 .
>
>
> On 7/29/19 5:00 AM, dktue wrote:
>
> I'd vote for kW aswell (and a value of "22" then), since we're not always
> using SI and not always base-unit-values (see kilometers per hour).
>
> Am 29.07.2019 um 12:53 schrieb Martin Koppenhoefer:
>
>
>
> Am Mo., 29. Juli 2019 um 12:39 Uhr schrieb dktue :
>
>> Hello,
>>
>> the OSM-Wiki-page on charging stations [1] defines the tag
>> socket::output=watt
>>
>> wheres the examples contain values like "22 kW".
>>
>> What would the preferred format be? "22000" or "22 kW"? I would like to
>> clearify this on the wiki-page.
>>
>> Personally I would prefer "22000" as it fits with other OSM-values (no
>> units).
>
>
>
> generally people are encouraged to add units for disambiguation reasons
> and to use locally used units and preferably SI units.
>
> For power, no default units are currently specified on this page:
> https://wiki.openstreetmap.org/wiki/Map_Features/Units
>
> And it doesn't even mention horsepower for power, a unit that for many
> people may be more evocative than Watt (everybody can imagine 30 horses,
> but how much are 22 kW?) ;-)
>
> Personally, if we were to set up a default for power units, I would prefer
> kW, because if we'd use Watt we will get very high numbers for MW (e.g.
> needed for power generators). Presuming, we would have the same standard
> unit for all things power, and not different defaults for socket and say
> power stations.
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ho to tag the position of objects on highways

[Lionel Giard]

For things like manhole or poles, i just tag them at their real position,
as it is not useful to connect them to the highway line which exist mostly
for routing purpose. There are a lot of object that can exist on the area
of a road (a pole, a manhole, a barrier, an underground fire hydrant,...)
so i don't see the problem to tagging them where they are with node (or
line if needed). It is on the ground like that, so even if you map the
highway area, it will just be an object on the highway.

One example when i tried on a small area detailed tagging with area:highway
+ manholes, fire hydrant, every pole, :
https://www.openstreetmap.org/edit#map=21/50.67546/4.71756 . The position
of the manholes, hydrants, ... are exactly where they are in reality. I
sometimes map the traffic sign on the side of the road as a separate node,
mainly for 3d purpose, but i suppose it also helps others contributors as
they can see that the maxspeed is given on the sign there. i see that
"physical traffic sign" as a different information that can be useful for
different usages (here more for 3d rendering).

Regards,

Le ven. 14 juin 2019 à 22:21, Volker Schmidt  a écrit :

> If I have an object on a highway, like a manhole on a road, or a traffic
> sign pole or lamp post on a footway, how do I map this object, when it is
> not on the centreline of the road or footway (and without mapping the
> highway as an area).
> Here   is a nice
> example of three objects on a combined foot-cycle-way with more ore less
> the same longitudinal position (with respect of the way that represents it
> in OSM).
>
> Volker
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_66563647600178258_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Deprecation of non-approved values for diplomatic=?

[Lionel Giard]

The editor presets are already changed (so any modification or new creation
of embassy, consulate or liaison use the new tagging scheme). The number of
diplomatic=* tag compared to the number of office=* tag is due to the fact
that the "diplomatic"=* tag was already existing but used slightly
differently and without any consensus. The new scheme is just a refinement
to better represent what it is.

After the proposal was accepted, the old main tag amenity=embassy was added
to the deprecated value. But it didn't mention diplomatic values used as it
was never properly referenced anywhere at this time ! ;-)
As usual, we don't massively change the objects tagged with a deprecated
value, as we need an human review to check whether it is still correct to
tag this object as embassy or consulate...
So it will change with time and become more and more prevalent, but it
takes time. We could always makes some sort of challenge by country to
check the embassy/consulate/... to speed things up. And I suppose that
adding the note on the wiki for diplomatic values will help and reflect
what is already applied in editor presets ?!


Le ven. 14 juin 2019 à 17:51, marc marc  a
écrit :

> Le 14.06.19 à 15:10, Martin Koppenhoefer a écrit :
> > we should be very reluctant to mark tags as deprecated (i.e. it
> > should happen after their usage significantly dropped
>
> in French we say "c'est le chat qui se mord la queue"
> tag use changes little as long as presets do not change.
> presets sometimes don't change as long as the tag usage doesn't change
>
> having a dual tag for the same meaning is a horror
> - each datause must test both if they want to have all the data
> - each contributor must add the 2 tags if he wants it to be used
> by everyone
> - each deletion of one of the 2 tags on an object is ambiguous: did the
> contributor mean that the attribute is deleted but forgot to delete the
> 2nd or did he want to delete the tag he doesn't like ?
> - somes publishers implement distributed mass publishing rules hidden
> in the real changes of contributors.
>
> I think the proposals for a new tag should clearly say:
> - add such tag
> - edit the old tag description to point the new tag
> - write to editors to adapt presets
> - propose a mecanical edit, if necessary by splitting it up
> to avoid a global opponent blocking everything
> - propose the depreciation of the old tag
>
> Regards,
> Marc
> ___
> 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] Deprecation of non-approved values for diplomatic=?

[Lionel Giard]

I think that the only deprecated tag in the accepted proposal is
"amenity=embassy" (which is indicated on the wiki page too).

The wrong diplomatic value are just what old tagging scheme lead to. It
doesn't need to be deprecated to me as it never existed officially (i
think) - and it will probably be fixed at some point in the future when
contributor update the embassy/consulate/...

The only action i would take is to *add the note on the wiki page of
"diplomatic=*" for each of the "non-approved" value*, where we specifically
tell what is the new approved *sub-tag* (so people know that there is an
alternative). Like for "diplomatic=honorary_consulate", note in the
description that it could be tagged as "diplomatic=consulate" +
"consulate=honorary_consul" with the new tagging scheme.

Regards,

Le ven. 14 juin 2019 à 12:32, Frederik Ramm  a écrit :

> Hi,
>
> in general, I try to avoid marking anything as deprecated. I think the
> term only gives people wrong ideas. If anything, try to find wording
> that says "today, most mappers prefer the X tag", but don't say "this
> tag is deprecated" except in very clear circumstances, where an
> overwhelming majority has actually decided that this tag should be
> listed as "deprecated".
>
> Claiming something is "deprecated" should never be a silent side-effect
> of some other vote.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Wiki changes for police tag

[Lionel Giard]

I also see it as a top-level tag. i find it similar to the recent
"healthcare=*" which can be used by itself too.

Le sam. 18 mai 2019 à 11:46, Jan S  a écrit :

> Interesting point... I'd suggest that it is a top-level tag itself.
> Otherwise you'd have to tag buildings as building=* and police=*, which I
> find an unnecessary duplication that might even result in contradictory
> tags.
>
> Best, Jan
>
> Am 18. Mai 2019 10:36:32 MESZ schrieb Simon Poole :
>>
>> Seems as if the proposal and now the definite wiki page is missing one,
>> not quite unimportant, bit of information:
>>
>> is police an attribute to be used on other "top-level" (say for example
>> building=xx OSM objects or does it define a stand alone "top-level" object
>> itself?
>>
>> Simon
>> Am 17.05.2019 um 23:03 schrieb Jan S:
>>
>> Hi everyone,
>>
>> I've created the pages https://wiki.openstreetmap.org/wiki/Key:police
>> and subpages for values police=barracks, police=car_pound,
>> police=car_repair, police=checkpoint, police=detention, police=naval_base,
>> police=offices, police=range, police=storage and police=training area, as
>> well as the generic police=yes.
>>
>> All this in accordance with the approved proposal for key:police.
>>
>> Best, Jan
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting results - Police facilites

[Lionel Giard]

There isn't any EU police or military force (that's still a political
discussion but there is none at the moment). The only existing thing is the
international cooperation that is increased between neighboring countries
and some special rules allowing one police force to pursue a suspect in the
other countries for some times (if they cross the border). Apart from that,
it is as everywhere : police force(s) separated by country.

For the proposal, the country specific tag could be just removed, as they
don't need to be mentioned on the global proposal (they are approved by the
local community in question (OSM France here), but they don't necessarily
need to be approved by the global communities). We have lots of local
tagging scheme in OSM, that are only defined in one country, and they work
well for them.

Thus, only voting for a proposal with the global tagging scheme would
probably be better (and leave the local tagging to the local communities
for the time being ?!).

Le mar. 23 avr. 2019 à 09:05, Warin <61sundow...@gmail.com> a écrit :

> I too missed it. Lot going on.
>
> There is a web page that helps
>
> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
> Looked at once a week it should pick up any proposal in 'voting' provided
> the status is set correctly..
> I have not been using it of late ..  :(
>
>
> On 23/04/19 12:25, Graeme Fitzpatrick wrote:
>
>
>
> Sorry to see that it missed out Jan :-(
>
> As Joseph suggests, maybe take out the country specific & try again?
>
> On Tue, 23 Apr 2019 at 11:22, Joseph Eisenberg 
> wrote:
>
>> It looks like several critical comments mentioned that the country
>> specific tagging (eg police:FR=*) was not good.
>>
>
> Just for interest's sake, in regard to that - is there any form of
> "European Police" across the EU, or is all law-enforcement still strictly
> under each countries control? There is an EU military force of some sort,
> isn't there?
>
>
> Crikey .. I hope not.
>
> ___
> 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] Subtag for place=locality?

[Lionel Giard]

In Belgium (where i map), we generally use this tag for place without
population that have a name ("lieu-dit" in french (look at this wikipedia
article) ), like a crossroads (like
"Carrefour de la Justice" (literally "crossroads of justice")), a field, a
part of a forest or some hills. It is often very old names that are shown
on various topographic map (generally the name is the same than in the
past, as we can see them on maps from 1700 ...) and it is really useful to
locate ourself.

Thus i would not limit to the sub-type that you propose (which are only
considering "abandoned places") because there are a lot of cases where they
were never anybody there (we can sometimes find that the crossroads are
inside a hamlet but the crossoroads itself is not inhabited). Also,
locality=junction isn't related to railway (if you look at example, it is
bridges
 or
crossroads ). So i would use
add sub-type for all those "never inhabited places".

Lionel

Le lun. 15 avr. 2019 à 03:57, Joseph Eisenberg 
a écrit :

> Currently place=locality is main in the database from imports, and it
> is also used as a way to tag a feature which is not currently rendered
> by most map renders so that the name will show.
>
> Since place=locality was originally defined as "a named place that has
> no population" it's easy to see how this (mis)use came about.
>
> There are certainly places that really should be tagged place=locality.
>
> The wiki mentions places that used to have a population, but are not
> longer inhabited; eg "ghost towns" and railway junctions in the USA.
> This features are often still shown on other maps, and may still have
> a sign that shows the location, but even if they are only know by
> local knowledge they may be useful for orientation.
>
> For example, the locations of old mining camps by the river were still
> used by fire fighters and police to specify locations of incidents in
> my home area in rural California.
>
> See https://wiki.openstreetmap.org/wiki/Tag:place=locality
>
> What we need is a way to distinguish the correctly-tagged features and
> those that are double-tagging for rendering. I would suggest that a
> subtag such as "locality=*" could be useful.
>
> https://taginfo.openstreetmap.org/keys/locality#values
>
> This tag is already used 65,000 times, but actually on boundaries; it
> was used for an import in Ireland with the values locality=townland
> and locality=subtownland. (These seem to be incorrect usages, because
> townlands seem to be populated places)
>
> Besides the import, it's been used 26 times with locality=junction
> (which could also be tagged railway=junction
> https://wiki.openstreetmap.org/wiki/Tag:railway%3Djunction)? The other
> values look incorrect; they are all populated places, or backwards
> (locality=place).
>
> So I think the key "locality=*" could be used to specify the type of
> locality. This would allow database users to decide which localities
> to render, out of the 1.3 million
>
> The most important value would be one for a locality that is a former
> populated place but no longer has a population.
>
> Ideas for the value?
>
> locality=ghost_town seems too American
>
> locality=formerly_inhabited could work but is rather wordy
>
> locality=abandoned_farm or =abandoned_hamlet might work?
>
> Are there other types of valid localities which cannot be better
> described with a different tag, other than former inhabited places?
>
> -Joseph
>
> ___
> 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] shop=plumber vs shop=plumbing vs shop=plumbing_supplies

[Lionel Giard]

Keep in mind that there is already the tags "man_made=works" + "products=*"
for industrial scale production. Like the example of a brewery that can be
tagged as craft=brewery (when small) or via man_made=works + product=beer
(when industrial).

To my understanding, at trade shop can't really be compared to a "craft"
guy, as the trade shop only sell bulk material (there is no production
there). :-)

Le mar. 26 mars 2019 à 12:00, ael via Tagging  a
écrit :

> On Tue, Mar 26, 2019 at 04:57:12PM +1000, Graeme Fitzpatrick wrote:
> > > there is also craft (combination or not) for places where you find
> > > specialized workers.
> > >
> >
> > I've never been very happy with a lot of the craft= tags.
> >
> > To me "craft" suggests small-scale, probably handmade, so things like
> > =basket_maker; beekeeper; blacksmith; cooper; embroiderer & so on all fit
> > as they're (usually) small, often one person operations.
> >
> > But =boatbuilder; builder; electrician; glaziery; hvac; mint; roofer;
> > sawmill etc are usually not small scale works.
>
> +1
>
> >
> > Should we possibly have a trade= key to cover the office / workshop /
> shed
> > / factory unit where these specialists are located, or from where they
> work
> > out of?
>
> As long as it is clearly distinguished from the exiting use of trade.
> I fear confusion if it uses exactly the same tag. But maybe it could
> work.
>
> ael
>
>
> ___
> 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] shop=underwear vs shop=clothes + clothes=underwear

[Lionel Giard]

I think that the shop=underwear could be deprecated indeed, as the other
tag is similar and more used (and probably more practical as it is a
sub-category of clothes shops).

For the underwear or lingerie name, both value are existing for "*clothes=**"
(depending if only selling for women or (also) for men).

Le mar. 26 mars 2019 à 13:29, Philip Barnes  a écrit :

> And shops just selling underwear usually describe themselves as lingerie.
>
> Phil (trigpoint)
>
> On Tuesday, 26 March 2019, Mateusz Konieczny wrote:
> > Is there any good reason to use
> >
> > shop=underwear
> >
> > rather than
> >
> > shop=clothes + clothes=underwear
> >
> > ?
> >
> > Both describe shop selling primarily underwear, second case seems to be
> > more universal to me.
> >
> > https://taginfo.openstreetmap.org/tags/clothes=underwear <
> https://taginfo.openstreetmap.org/tags/clothes=underwear> is also far
> more popular
> > than
> > https://taginfo.openstreetmap.org/tags/shop=underwear
> >
>
> --
> Sent from my Sailfish device
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Lionel Giard]

That's why the proposal state that we will keep the amenity=police tag on
the public-facing object so that they will still be backward compatible at
the moment. Thus, the "technical" problem doesn't exist, and if we drop the
amenity tag in the end, it will be probably after (at least) a year - if we
look at others tag changes in the past. Thus database users should have
plenty of time to adapt if needed ! ;-)

Le sam. 16 mars 2019 à 23:23, Joseph Eisenberg 
a écrit :

> The key “police” is not currently on the list of features that import as a
> polygon in osm2pgsql, when mapped as a closed way.
>
> So renderers and other database users that rely on osm2pgsql will need to
> add the “police” key to the lua transformations list and reimport the
> database.
>
> This is easy for cartographers that make insividual maps, but it’s a major
> undertaking for the main OSM servers, which is only done every couple of
> years. So it will take some time before any objects tagged “police=station”
> without an “amenity” tag could be rendered on the Standard map layer on OSM.
>
> This shouldn’t be a problem for things like warehouses, non-public
> offices, vehicle impound facilities etc. But it requires patience for
> police stations.
>
> -Joseph
>
> On Sun, Mar 17, 2019 at 4:16 AM Mateusz Konieczny 
> wrote:
>
>>
>> Mar 16, 2019, 3:08 PM by dieterdre...@gmail.com:
>>
>> On 16. Mar 2019, at 13:11, Jan S  wrote:
>>
>> All other police facilites, that may currently have been tagged
>> erroneously as amenity=police would be tagged only as police=*,
>>
>>
>>
>> The „problem“ with this approach is that maps who base the presence of
>> objects in their renderings on the presence of specific keys will likely
>> not happen to find these police=* things in their database.
>>
>> Why not? Is it concern about technical difficulties or that they would be
>> unaware that
>> this tag exists?
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Lionel Giard]

I don't see why people would care that much about a tag that could be seen
as a sub-tag at first (look at all the chain of tag that we have like :
man_made=street_cabinet + street_cabinet=power + power=substation +
substation=minor_distribution). So someone don't like the
"amenity=police" + police=station, i don't understand the reason. And even
if we consider that we want to remove the amenity=police in the future,
that's just what has been done for others big tag chains, where the higher
tag is not always added as it is implicit.

Otherwise, i like this proposal, as it looks to be an improvement to the
current scheme as it add a way to differentiate all these type of police
structures.

Le ven. 15 mars 2019 à 20:44, Mateusz Konieczny  a
écrit :

>
> Mar 15, 2019, 8:25 PM by ferdi98...@gmail.com:
>
> Woudn’t  it be possibel to do an Automated edit where we add fixme:Police
> to all amenity Police this shoud Speed up the Adoption and allow for the
> Elimination of the amenity=Police.
>
> In theory yes.
>
> See https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> In practice it is highly unlikely that people would consider it as
> something desirable.
> ___
> 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] Fwd: Re: Forest parcel with other landcover (scrub, scree…): how to map?

[Lionel Giard]

To summarize the different points of the recent messages, there are 2
points concerning the tag changes described as an alternative to
landuse=forest or natural=wood :
1) *Landcover :*

   - landcover=trees -> for areas with trees (instead of *landuse=forest*
   or *natural=wood*);
   - landcover=grass -> for areas with grass (replacing landuse=grass);
   - landcover=scrub -> for scrub areas [ *Do we need to replace
   natural=scrub here or does it still give another information ?* ];

2) *Landuse : *

   - landuse=logging -> for areas with logging activities (instead of
   landuse=forest or natural=wood).

*landuse=forest* and *natural=wood **will still exist*, and may be
deprecated (or not) at a later time. I say that in order to convince people
more easily, we could just offer a "better" alternative to the current
tagging, and build up on that ! ;-)
At this moment, I suppose that landuse=forest could still be used (if you
need it) for the other forests that are used for another purpose than
logging (like leisure), until we have better tag for it. But it would only
mean an area "*with some forest usage*" (no longer for the landcover or
logging) !

Note that the landuse should probably be rendered "below" the landcover (if
it exist). It should be easy as it is already what is happening, if you
have a landuse=residential and you draw landuse=grass or landuse=forest,
these are rendered above the landuse residential as both are supposed to be
"landcover". The difference is that we will be able to have better
differenciation like this. One improvement could maybe be to use slightly
different color for landuse=logging than for landcover=trees, so it could
be dissociated ?

Following the general definition of landcover and landuse (used in
geography), they could both coexist next to each other on a polygon (as a
data user could search only for one of them).

Le mer. 23 janv. 2019 à 13:36, Paul Allen  a écrit :

> On Wed, 23 Jan 2019 at 08:29, Mateusz Konieczny 
> wrote:
>
>>
>> You may prefer to use landuse=logging or something that has a clear
>> meaning
>> rather than landuse=forestry to tag areas used primarily to grow wood.
>>
>
> Given the wikipedia page you pointed to earlier in the thread, I agree
> that
> landuse=forestry is a bad idea (almost as bad as landuse=forest was).  What
> I was after was a way of distinguishing a large area in which trees are
> logged, part of which may currently have trees on it and part of which may
> currently have stumps, or saplings, or scrub.  Something with defined
> borders
> which do not change from year to year and so will not have to have the
> outline
> changed every time newer aerial imagery comes along.  I agree that
> landuse=logging is a far better tag than landuse=forestry.
>
> So is it possible for us to agree on landuse=logging here as an
> alternative to
> landuse=forest?  To agree that dual-tagging is permissible until the day
> that
> landuse=logging is rendered in standard carto?  To agree that
> landuse=forest
> be deprecated once landuse=logging is rendered?  To agree that, once
> landuse=logging
> is rendered, the wiki should say that landuse=logging + natural=wood can be
> simplified to just landuse=logging when editing existing features that are
> dual-tagged?
>
> If we can agree to all that here (and, let's recognize that there's
> nothing stopping anybody
> using landuse=logging + natural=wood right now) do we need a formal
> proposal or is
> a "show of hands" here sufficient to allow it to be added to the wiki?
>
> --
> Paul
>
> ___
> 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] The actual use of the level tag

[Lionel Giard]

As pointed out for underground station, the building outline doesn't always
cover the underground levels (i.e. the underground levels can extend far
beyond the building limit (and potentially under other buildings/roads...).
We find this problem for metro station, train station or other buildings
like mall.

One example is the mall "L'Esplanade" (Louvain-la-Neuve, Belgium) that you
can see indoor mapped (except parking levels) here
https://openlevelup.net/?l=1#18/50.67045/4.61647 .
It is on a concrete slab (only pedestrian traffic) that cover all the city
center and is more or less 2 levels above the streets where car drive (the
streets are in a "tunnel" when going under the city center. Most of the
time these 2 levels can be described like "street level / ground level" and
the "first level" is for parking, and the "second level" is at the surface
with the pedestrian area) and you have building going up to 6-7 floors
above that. But for the mall, you have a different leveling : the street
level is still the parking entrance, but the two levels above with shops,
so that means that the "first level" of shops is below the surface, and
indeed it is extended below two plazas and another building. To avoid the
mess that could occur with the levels tags, we choose to set an arbitrary
level tagging for the whole city center that's on the concrete slab (it can
be seen as a large building, and it is not too far from reality).

In this case, the level tag need to be synced with all the neighboring
building that are built on the same structure (the "concrete slab"),
otherwise you would have multiple objects at the same position when
rendered on a map. Ex : The mall is officially labelled as "-1" for the
parking entrance, "0" and "1" for the shops levels (the level 1 is on the
surface), while the building that's on top of some part of the mall have
level starting at "0" (the surface level with entrances from the concrete
slab) and going up to level 6 above that. If we use these local numbers for
the level tag, any tools would render the building surface level at the
same position than the shops level that's underneath it !!! For POI it
would be like "is it at level 0 in the mall or at level 0 in the building
?", thus an arbitrary level for all these buildings is really needed to
avoid such problems.

So, i'm really in favor of the level=* for a "data user friendly" tag (that
could correspond to local numbering, but not always) and a special tag for
the local levels. At this moment i would see a *local level tag *like
"level:ref=*" or "loc_level=*" (like we have for name and loc_name ?) but *on
each object*, as it would not be realistic to use an outline in the cases i
present).

PS: i hope my example is not too confusing, or badly explained. :-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] The actual use of the level tag

[Lionel Giard]

Yes it makes sense to keep this distinction : level tag can just be the
"logical order" of levels going from -xx to xx with an arbitrary 0 for each
building, so tools know the order (which one is above the other). Simple
Indoor Tagging already suggest the level:ref for the "local" naming scheme.
It could be used by tools when they show you the name of the level in their
interface (One example : a building with tags "level=0" + "level:ref=Ground
floor", instead of showing "level 0", the tool can display "Ground floor"
-> both the data user and the data consumers are happy ;-) ).

Le lun. 21 janv. 2019 à 09:20, PanierAvide  a
écrit :

> Hello,
>
> Just for your information, there is also this "level:ref" tag which was
> used in various context to solve this problem :
>
> - level tag is still used as defined in Simple Indoor Tagging
> - level:ref has a value which is linked to operator naming of levels
>
> That way, casual mappers/consumers don't need to stick to level definition
> which doesn't make regarding operator naming, they can set level:ref
> according to what they are used to see. And we keep the level definition
> which makes more sense for tools.
>
> Regards,
>
> Adrien.
>
> PanierAvide
> Géomaticien et développeur
>
> Le 21/01/2019 à 09:05, Simon Poole a écrit :
>
> As tordanik has already pointed out the main issue with the proposals is
> that there is no inherent ordering that can be deduced from level values
> on objects if they are not (integer) numbers, so any such scheme
> requires far more insight, effort and available context from
> joe-casual-mapper and joe-casual-data-consumer to get layering right.
> With the current scheme that is a no-brainer even if there are
> discrepancies between actual numbering of the floors and what is being
> used in OSM.
>
> Simon
>
> PS: addr tags are for postal addresses I don't think using them as a
> level name/ref makes very much sense outside of that very narrow
> application.
>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Lionel Giard]

You can also use height=* for both and add a "souce:height=estimated /
measured" tag with that to have a value that is usable by the apps and
tools but still keeping the information that it was only estimated ! ;-)


Lionel



Le ven. 9 nov. 2018 à 10:19, Dave Swarthout  a
écrit :

> There is already an est_width tag (Taginfo 77,000). I see no reason why
> you couldn't use est_height, which has over 1000 instances in Taginfo.
>
> Dave
>
> On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni 
> wrote:
>
>> I'm going to import a small dataset of trees. Some tree heights are
>> defined as "measured", some as "estimated".
>>
>> About estimated values, I've found a wiki definition only for width [1]:
>> shall I
>> derive an est_height tag,
>> go for most popular taginfo solutions,
>> simply assign an estimated value to height tag?
>>
>>
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:est_width
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> 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] mast / tower / communication_tower (again)

[Lionel Giard]

Maybe we should inspire us from the power=* scheme and using a telecom
tagging like (i'm looking to the idea of "power=pole" compared to
power=tower) :

- Keeping the tagging as a man_made=tower (or other suitable tag) for big
tower (like Eiffel tower) that have other purpose, and only tag the telecom
services (like radio);
- telecom=tower for all dedicated telecom tower / mast;
- And using a tag for small antenna support structure.

And really only tag the suitable information about the structure in
sub-tags (like structure=guyed_mast, tubes_mast, lattice,
tubular/tubes...). Note that i use the mast name only here, as the only
"known" usage of mast (that is clearly defined) is in the engineering
terminology where all mast are guyed.

Wouldn't it cover everything and simplify the tagging by using only 1 tag
for telecom=tower (instead of man_made=tower/mast +
tower:type=communication).
And creating a suitable tag for small structure supporting antenna.
It would also allow to continue the unification of telecom tagging under
the "telecom" key ! ;-)

it's just an idea, but it is useful to keep in mind that there are multiple
levels of tagging here : the main key only giving "basic information" (like
is it a big tower or a small antenna structure) and the sub-tags that give
indepth information about the structure in question.

PS: I would avoid to keep the choice of two main value and choose only
either mast or tower as the big telecom structure, and that's it ! This is
the main source of confusion and problems i think. ;-)

Le sam. 27 oct. 2018 à 06:12, Graeme Fitzpatrick  a
écrit :

> On Sat, 27 Oct 2018 at 10:28, Greg Troxel  wrote:
>
>>
>> So where I think we are is:
>>
>>   there is almost zero support for the notion that guy wires or not is
>>   critical and therefore these must not be part of definitions.  (Maybe
>>   just Graeme.)
>>
>
> Sorry if I sound pedantic about it - I'm not an engineer of any sort, I'm
> just working off the definitions shown on the tower wiki page, & many other
> spots found by a mast v tower Google search eg
>
> https://en.wikipedia.org/wiki/Guyed_mast
>
> A *guyed mast* is a tall thin vertical structure
>  that depends on guy lines
>  for stability. The mast itself
> has the compressive strength to support its own weight, but does not have
> the shear strength to stand unsupported, and requires guy lines to resist
> lateral forces such as wind loads
>  and keep it upright
>
> https://en.wikipedia.org/wiki/Radio_masts_and_towers
>
> The terms "mast" and "tower" are often used interchangeably. However, in
> structural engineering terms, a tower is a self-supporting or cantilevered
>  structure, while a mast
>  is held up by stays or guys
> . Broadcast engineers in the UK
> use the same terminology.
>
> http://braziltowercompany.com/en/mast-or-tower.html
>
> When discussing telecommunication antennas, the words “mast” and “tower”
> are often used interchangeably. However, structurally, they are not the
> same thing.
> A mast is an antenna held up by stays or guy-wires, while a tower is a
> self-supporting structure or is held up on one end only. Often, the term
> “tower” is used when the antenna is attached to the ground, while “mast” is
> used when the antenna is mounted onto another structure like a building or
> a tower.
>
>
>>   There are really multiple sorts of things we are talking about:
>>
>> A) towers that are more than for antennas, like Tokyo, Killesberg,
>> Eiffel, and other similar things that aren't really buildings but
>> which have a significant purpose beyond holding an antenna up high
>>
>> B) things that support antennas that are big enough that a person --
>> almost certainly a professional antenna repairer/installer or tower
>> maintainer -- can climb up inside of, or stand on some top platform.
>> Usually lattice or some sort of >1.5m diameter tube.
>>
>> C) things that support antennas that have lattice or foot platforms
>> and can be climbed by people externally, sort of like a ladder, with
>> a climbing harness, again only by trained people for repair/install.
>> Like Rohn 65.  Probably includes 30cm tubes that have climbing
>> protrusions.
>>
>> D) things that support antennas that are small enough that no person
>> can climb the outside.  Ranging from 2cm diamater to maybe 20cm.
>>
>> In my usage
>>   A is a kind of tower
>>
>>   B and C are "antenna tower" (separate from the A type tower) in the
>>   US.  I gather in the UK B is tower and C is mast.
>>
>>   D is a mast in the US
>>
>> I realize many here call A and B tower, and C and D mast.
>>
>> B and C are often different only in scale.  For example, B coudl be
>> triangular lattic that's 1.2m on a 

Re: [Tagging] mast / tower / communication_tower (again)

[Lionel Giard]

At my work (a telecom company in Belgium), i see these types of mobile
structure construction :
- *Self-supported pylons* (the "*tower*", mostly looking like the
power=tower in OSM, but also including the (older) self-supported tower in
concrete) ;
- *Guy-wired pylons* (the "*mast*" as described in the engineering
definition where it is a structure held by guys);
- *Self-supported roof structure* (half of them are just simple *antennas*,
the other half are *mast *(the larger structure that clearly hold more than
1 antenna on top of buildings));
- *Guy-wired roof structure* (all of them are *mast*);
- And some other things like on electricity pylons(all of them are just
antennas on top of something as far as i know).

And as a sub-type (indicating type of construction) : we got the "lattice
pylon", "tubular pylon", "lattice mast", "tubular mast" or just "tubes"
(for antennas isolated). So it would correspond to the t
*ower:construction=guyed_lattice* or *guyed_tube* (for mast) and* lattice*
or *freestanding *(for the tower). Note that the older concrete telecom
tower is noted as "tubular pylon".

Thus, as i see it, the *tower *tag is the equivalent of pylon (as in the
power=* tag where the power=tower is the equivalent of what we call
"electricity pylon" here) and the *mast *are either the guy-wired
structures OR the "largest" structures on the roof of buildings (which are
clearly not an unique antenna). And then we need a tag for isolated *antenna
*(i saw that a "telecom=antenna" was proposed on the telecom wiki page and
i used it some times, but that's just a tag to indicate either on a node
(on top of a building) or on another structure (like power=tower) that a
telecom antenna is there. So to me, this covers everything i see in our
database.

If we use the current definition, the only problem i see is for the
"self-supported pylons" which should all be tagged as tower (on engineering
terminology), but could currently be tagged as mast if they don't look like
"big tower". But the problem is minor, as if you look at the tag
"tower:construction", the "guyed_lattice" and "guyed_tube" already say that
it is a 'mast' in the engineering definition (and as far as i know, all
masts are either guyed_lattice or guyed_tube construction !). ;-)

=> And thus, the only change i would make is to the sub-tag
*tower:construction* : using "*lattice*" or "*tube*" for the "freestanding"
towers (the freestanding value is more general but give not much
information as if it is not guyed, i think it is always freestanding). So
at the end, the engineering definition is clearly indicated via this tag.

Best regards,
Lionel

Le ven. 26 oct. 2018 à 09:07, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> On 26. Oct 2018, at 01:57, Greg Troxel  wrote:
>
> for all things which are not buildings and basically exist to support
> antennas, and avoid the tower/mast word choice, which is pretty clearly
> contentious and/or confusing.
>
>
>
> what about this:
> https://upload.wikimedia.org/wikipedia/commons/1/11/Killesberg_Tower.jpg
>
> Actual tagging is even more weird, or does anyone recognize a mansard roof
> here?
> https://www.openstreetmap.org/way/306362151
>
> this is not a building, neither by the German nor by the English
> definition, but at least for Germans it is a tower.
> I would not require for towers to be a building (which at a minimum should
> provide some enclosed space).
>
>
> Cheers, Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] historic=memorial tagging question.

[Lionel Giard]

I would use memorial=stele (as it looks like a stele to me). If you go on
wikipedia it looks like some of the "usual" stele :
https://en.wikipedia.org/wiki/Stele .

Le mer. 17 oct. 2018 à 11:22, John Willis  a écrit :

> How would I map this object?
> https://www.machigururi.com/spot_detail.php?id=3762
>
> It is a stone tablet memorializing when a small levee failed and washed
> away part of a hamlet. This is in the park built on top of the levee repair.
>
>
> these kinds of stone tablets - always a freestanding carved or etched
> stone (not a plaque attached to a rock), and usually between 50cm and 2m in
> height, are the most common form of memorial object in Japan (very tall,
> thin, cut stone tablets anchored in the ground, covered with carved letters
> - not a memorial=stone). this example is a more modern version, with very
> little text. older ones are covered with text. though it looks like a
> headstone or a grave, this is not a common shape for a grave marker in
> Japan - but for memorial tablets.
>
> interestingly, the sub-tag of historic=memorial, memorial=*,  has a lot of
> suggested values in iD, including memorial - so memorial=memorial is a
> commonly tagged value (295 uses)!
>
> https://wiki.openstreetmap.org/wiki/Key:memorial
>
> to me, this is a tablet (20 uses), but if this object is better defined by
> another value, I would be happy to use it.
>
> Javbw
> ___
> 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] issues with the list of deprecated features

[Lionel Giard]

>
> I am not sure how it changes that we ended with tourism-artwork as a
>> standard.
>>
>> Also, "has nothing at all" is not true. Artworks are quite likely to be a
>> tourism attractions.
>>
>>
>
>
> following this argument, we would have to tag the national parliaments as
> tourism=parliament because they are quite likely tourism attractions.
>

For tourism=* tag, for me, it is just a method to not tag each artwork with
"tourism=attraction" i would suppose (as they are probably all an
attraction), while a parliament *could *be a tourism=attraction, while
another part of it (or another parliament building) is of no particular
touristic value !

The tourism=attraction is more the general way of tagging a touristic
attraction while, the specific tourism=* values are for things that are all
an attraction !

BTW, another thing potentially using this "tourism=artwork" tag are
statues. They have two existing tagging scheme : one using the
"tourism=artwork + artwork_type=statue" and another using the
"historic=memorial" + "memorial=statue". I understood it as the "memorial
statues" have historic values and was another scheme already, but they can
still be an attraction for tourism ! Nothing is easy ahah :p

3. amenity=creche and amenity=nursery
> For both tags amenity=kindergarten is suggested as alternative tagging,
> which seems clearly wrong (kindergarten is usually for ages 3-6 while these
> tags are for ages 0-3). There is also the suggestion for amenity=childcare,
> which is featured by iD presets, but which doesn't seem like a great idea,
> because it partly overlaps with the much more used amenity=kindergarten,
> and because it has a very generic meaning and can be used for any place
> that looks after "young children" (i.e. also after school places,
> nurseries, kindergartens, places in shops that take care of the kids for a
> few minutes, etc.) and the wiki states it is controversial.
>

For the amenity=creche..., in Belgium, we use the "amenity=childcare" for
an equivalent to "creche/nursery". It is a defined tag on the wiki (
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dchildcare ). I think, the
usage still depend on the country. ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Telecom local networks

[Lionel Giard]

In this proposal we use "telecom" key, but i would like to know what is the
limit/definition of this key ? Does it englobe internet provider, tv
provider and mobile provider (even if the company does only one of them
which is rarer today) ? Or only some of those ?

My question come from the wiki page about street_cabinet (
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstreet_cabinet#Street_cabinet_categories
) where the values of "street_cabinet" tag can be "telecom" and "cable_tv"
as two different values. Would it be preferable to merge them into
"telecom" ? As to me telecom means "telecomunication" which englobe TV,
internet and mobile.

Le mer. 10 oct. 2018 à 01:09, Graeme Fitzpatrick  a
écrit :

> Massive job, thanks Francois! :-)
>
> Question for you pleasse.
>
> Following on from the discussion re towers & masts, I've just mapped a
> couple of mobile phone towers.
>
> What should we call the base station hut / building usually adjacent to
> the base of the tower
>
> My understanding is they're not a street cabinet as you can walk inside
> them.
>
> So"
> building=hut
>
> telecom=???
>
> communication=mobile_phone???
>
> Thoughts / suggestions?
>
> Thanks
>
> Graeme
> ___
> 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] mast / tower / communication_tower (again)

[Lionel Giard]

The problem i see with that "multipurpose" value is that it give no
information and could be misused for other tower:type (like
defensive;observation) which should not be rendered as communication_tower.
Thus i would propose to render the "communication_tower" based on the
height > 250 m (arbitrary value for example) when in combination with
tower:type=communication (even when others tower:type are mentioned like in
your example : "tower:type=communication;observation"). I don't know if it
is feasible for the renderer to identify the presence of only one value in
the tag ? Otherwise i suppose it would need to put all alternative
available... :s

Le mar. 9 oct. 2018 à 02:28, Graeme Fitzpatrick  a
écrit :

>
>
>
> On Tue, 9 Oct 2018 at 10:13, Joseph Eisenberg 
> wrote:
>
>> " If you combine communications;observation, which would it render as?"
>>
>> It won't render at all, unless an individual renderer adds support for
>> this specific combination
>>
>
> Thanks Joseph
>
> So, if we use the existing rendered =communications_tower icon for my
> suggested =multipurpose, that will still render so the massive, visible for
> a long distance towers will be easily visible on the map
>
> Thanks
>
> Graeme
> ___
> 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] mast / tower / communication_tower (again)

[Lionel Giard]

I also support this simplification of definition and tags.

Is there a possibility to indicate that a tower is specifically a landmark
with a tag of some sort without knowing the height (most of them are not
publicly known around here) ? Because some are really useful for navigation
(visible from a long way) while other are only visible from up close.

I was personally using the communication_tower tag only to indicate that it
is a landmark when it is an especially huge tower (and that was the only
difference between a tower and this, to me).

Le ven. 5 oct. 2018 à 08:42, Graeme Fitzpatrick  a
écrit :

>
>
>
> On Fri, 5 Oct 2018 at 16:17, Joseph Eisenberg 
> wrote:
>
>> Sounds sensible to me. If JOSM and ID support man_made=tower +
>> tower:type=communication with a preset, it won't be any more work than
>> typing in a single tag.
>>
>
> Can confirm that it's preset in iD, as I've just mapped one (a mobile
> phone tower) but don't know about JOSM (or anything else)?
>
>
>> Does this require a proposal process? How does something become
>> officially deprecated?
>>
>
> Yep, that's the other question!
>
> Thanks
>
> Graeme
> ___
> 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] relation site <> multipolygon

[Lionel Giard]

My main use for site relation are for historical sites to group the
historical elements of the castle or other historical site including the
wall, moat, buildings (especially the ones touching each other) and various
nodes. An example in the historical commandry of the Hospital order (in
Belgium) here :
https://www.openstreetmap.org/relation/8671447#map=19/50.69111/4.88753 .
The only historical elements are grouped in the relation (we can still see
some of the coat of arms of the order on these buildings...). I couldn't
group all the buildings into a multi-polygon like usual farms as i wanted
to get the distinction between old and new buildings (some of them have
different start_date).
Same thing with an historical farm
https://www.openstreetmap.org/relation/8671752 , i wanted to keep the
information about the different parts of the building (in french here
saying "old stable", "main building", "dovecoat", ...) and once again, the
different parts get different start_date.

For those two examples, i couldn't use the multipolygon due to the
buildings sharing common edge. In those case, the site relation is mostly a
"multi-polygon" whitout its limitations and the possibility to group node
when needed like the old mines where the mineshaft (or the memorial stone
indicating the shaft) are represented as a node. O
Another use of the site relation for historic object is to tag the special
heritage concerning all the site (not only one building or element).

There are also the "multipolygon" for an university dispersed in a city
like in Louvain-la-Neuve (Belgium) :
https://www.openstreetmap.org/relation/8148420#map=16/50.6684/4.6142
If i want to group every part of the university into only 1
amenity=university, i needed a site relation as some part are only "node"
inside a buildings (to indicate the presence of a faculty in a multi
purpose building or one of the underground parking of the university). I
tried with a multi-polygons but i couldn't add the nodes, nor the
"touching" buildings (without creating "pseudo" polygon enveloping both and
without any reality existence). Also, some buildings are multi-polygon
themselft (the "donut-like" buildings) and in at least one case, the inner
ring is not part of the university itself.

I don't find site relation difficult to interpret in those case (as it is
not for rendering !), it is usable by application like gk.historic.place
website that show the site relation objects only (i suppose they only
download the members of the relation).

Le mar. 2 oct. 2018 à 18:03, Marc Gemis  a écrit :

> This relation combines a number of cave entrances the belong to the
> same system that is apparantly protected:
>
> http://gk.historic.place/historische_objekte/translate/en/index-en.html?zoom=16=50.67804=7.22231=BFT=3
> On Tue, Oct 2, 2018 at 5:08 PM Mateusz Konieczny
>  wrote:
> >
> > 2. Październik 2018 12:36 od marc_marc_...@hotmail.com:
> >
> > Le 02. 10. 18 à 11:46, Mateusz Konieczny a écrit :
> > > Can you link this case if that is more complicated?
> > it's a fictional example. ok not the better one.
> >
> > take again the example you cut in the initial message:
> > a wind turbin site with a few turbines represented by a few nodes
> > I hope your solution is not to make a way for each wind turbine
> > to be able to add in into a multipolygon to describe the site.
> > it would not make much sense to make a polygon encompassing all objects
> > between the wind turbines and describe that the whole thing is a wind
> site
> >
> >
> >  I agree that for wind turbines multipolygon may not be feasible.
> >
> >
> > So far it is the only known to me case where site relation maybe is
> useful
> >
> > (I have no experience with features like wind turbine farms so it is hard
> >
> > for me to judge this case - that is why I skipped it).
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] mast / tower / communication_tower (again)

[Lionel Giard]

Looking at the definition on the wikiproject telecom
https://wiki.openstreetmap.org/wiki/WikiProject_Telecoms (in the part
"Antennas / Masts / Towers", there is a section to indicate how to tag the
mast, tower ...:

>From my understandings, the three (four) cases are currently :
- a vertical structure supported by anchors for a mast;
- a free-standing structure for a tower (it can be a tower of 10 meters or
150 meters !);
- and the communication_tower is only a sub-category of a tower, for the
ones with an height > 100 meters (i suppose it is an historic method to get
big tower rendered differently without knowing the height exactly - for the
towers that are a clear landscape reference).
(- And for antenna (alone) on buildings,  there is "telecom=antenna".)

Probably most of the mast are only accessible via ladder, and most of the
big tower have a platform (i don't know if all of them does), but does it
really matter ?

The question i could see is : do we really need the communication_tower tag
or should it be a secondary tag of the tower itself (like tower_type=*) ? I
think it is useful to distinguish them somehow as it is useful as a
landmark on the map, but am i alone to think that ?

Le dim. 30 sept. 2018 à 18:04, SelfishSeahorse 
a écrit :

> On Sun, 30 Sep 2018 at 17:24, SelfishSeahorse 
> wrote:
> >
> > On Sun, 30 Sep 2018 at 14:45, Martin Koppenhoefer
> >  wrote:
> > >
> > > > To solve the contradiction we need to get rid of one of the two
> definitions.
> > >
> > > they could be combined: if it is intended to be accessed by people
> (not only for maintenance) and is not guyed it is a tower, otherwise it
> would be a mast.
> >
> > I think it's better to stick to either a common or a technical
> > definition. OSM-specific definitions are prone to create confusion and
> > tagging mistakes.
>
> PS: Except if this appears to be a common definition.
>
> ___
> 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] [OSM-talk-be] cadastral plan now open data

[Lionel Giard]

André, i don't really see your point with the argument you made about
cadastre data. i don't know of anybody looking to use this data to add
building into OSM. It is outdated data regarding buildings and roads in a
lot of different place in Belgium. And as, the people at cadastre are not
the source for these data, they don't need to update it anymore !  Most
people are only using the default imagery (they often don't know about
anything else).

When tracing buildings, we should always base our self on the PICC for
Wallonia or Urbis for Brussels or GRB for Flanders and the relevant best
imagery in each case (comparing them keeping in mind that vectorial data
are not up to date everywhere at the same time).

To quote a report from the last PICC meeting in June, wallonia have the
following idea on official source :

> Wallonia is planning a “*georeferentiel*” (base of layers that are high
> accuracy and authentic source) within the application of INSPIRE.There are
> 4 major datasets that will be made as accurate as possible and with one
> authentic source for each:
>
>- *buildings* (in PICC),
>
>
>- *admin limits* (in cadastre),
>
>
>- *addresses* (in ICAR) and
>
>
>- *Roads* (in PICC/”direction des routes” collaboration with
>attributes (like primary, secondary, highway, bridge,…) on road, not only
>geometry).
>
> from:
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Contacts_with_local_autorities/Wallonia/Compte_rendu_Rencontre_des_utilisateurs_du_PICC_Juin_2018

So cadastre is really about admin. limits and parcels :
- For admin. limits i already talked about it before (as quoted, it is even
the authentic source for all Belgium apparently),
- and for parcels, there is an open debate about adding this information to
OSM (mainly because it is huge amount of work to maintain it) -> as
discussed on the wiki page https://wiki.openstreetmap.org/wiki/Parcel

So there is no ambiguity in what official data exist, the only problem is
that ICAR for the addresses is not yet finished for all municipalities (and
not complete in the PICC as far as i know ?! but i may be wrong about that)
and more importantly, it is not open nor viewable except for special
customers. So we still need to rely on tracing from the imagery and the
PICC WMS at the moment (for buildings, roads and addresses) and now, the
Cadastre data (or wms) to maybe update admin limits.
Note that these official data are considerably improving over time ! They
are still outdated or imprecise in some place, but even then it is still
the official source at the moment (so we should NOT copy blindly as you
said, but compare with recent imagery and survey !!!). The plan is to make
an update cycle closer to 1-2 years (for every municipalities) for the
PICC, but they are still far from it (6.5 years of average update time).

Is there something i'm missing out in your explication ? If so tell me, i
may not understand all your point !


Le ven. 21 sept. 2018 à 23:23, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> On 21. Sep 2018, at 21:32, André Pirard  wrote:
>
> The whole cadastral map is offset by that 7m.
> ...
>
> *Picture 3:* So, I dragged his parcel right onto the wall.
> And now it's correctly located, aligned with the fencing all around.
>
>
>
> how did you know which source was off, the cadastral map or the orthophoto?
>
>
> ...
>
> The Belgian cadastre is not the only one with an error shift.
> With JOSM, I have similarly proved that Google Map has a 120m NE shift in
> Beijing.
> Nobody noticed it.
>
>
>
> it is well known that the chinese government requires all imagery and map
> providers to use chinese algorithms which distort the map coordinates
> systematically, in a way that they remain usable as long as your navigation
> system uses the same algorithms.
>
> Ciao, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Lionel Giard]

It depends as some ambulance_station are located inside the hospital
campus, some other are "external services" and are only a sort of "depot"
like for taxi or buses. Personaly, I don't think landuse is a good tag for
that. Why not an amenity tag like everything else ?
(amenity=ambulance_station to be similar to amenity=fire_station ...).

Le ven. 21 sept. 2018 à 11:00, Colin Smale  a écrit :

> What about landuse=ambulance_station on the area? What would the landuse
> be otherwise?
>
>
> Asking for a friend...
>
>
> On 2018-09-21 10:47, dktue wrote:
>
> How about ambulance stations?
>
> Should we tag the area with emergency=ambulance_station and the building
> with building=ambulance_station?
>
> dktue
>
> Am 21.09.2018 um 03:23 schrieb Mike H:
>
> I've only mapped one station like this so far, but the area is actually
> rendered on the map. https://www.openstreetmap.org/way/616033018
>
>
> On Thu, Sep 20, 2018 at 9:43 AM Tom Pfeifer 
> wrote:
>
>> Yes of course, I've been doing this for long already.
>>
>> On 20.09.2018 14:06, Philip Barnes wrote:
>> > Yes, just go for it. Makes perfect sense.
>> >
>> > Phil (trigpoint)
>> >
>> > On 20 September 2018 12:56:03 BST, dktue  wrote:
>> >
>> > Hello,
>> >
>> > I love how we map areas with amenity=school and buildings inside of
>> it
>> > with building=school. The same goes for amenity=hospital and
>> > building=hospital.
>> >
>> > What I'd like to have is the same schema for firestations: They
>> often
>> > have a large area and one or multiple buildings on it.
>> >
>> > Should I go with amenity=fire_station for the area and
>> > building=fire_station for the buildings inside of it?
>> >
>> > Cheers,
>> > dktue
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[Lionel Giard]

You are right in that in regards to KISS, i was not seeing it as being more
complex but easier to interact with the parking_space elements via editor
(but that was personal preference for sure). I was also following the
description here
https://wiki.openstreetmap.org/wiki/Proposed_features/parking where you can
see schema (in the example category) with grouping of the parking relation
like a "tree" (i found it easier to understand by human editor than just
keeping it via geographic relation only). After all, site relation is not
meant to be rendered, but only to be used as *an administrative tool . *

But i recognize that i have probably over-extended the definition with its
use for the "simple" parking. Do you think i should remove the relation for
the 'simple' parking that are "only on the surface" and all contained into
the amenity=parking polygon ?

For multi-site parking (like for mall or large venue place where parking
can be separated by highways, buildings, ...), i still see it as a good use
as it avoid the duplication of most tags (opening_hours...) and indicate
that they are all the parking for that particular place (without relying on
the name or something like that).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[Lionel Giard]

*@OSMDoudou :*
At the moment, i only used the role entrance for the underground parking
site relation with some parking_entrance, because it was suggested by JOSM.
Roles could be used when the situation is complicated (ex : no clear
perimeter exist -> like for underground parking), it may then be useful to
indicate the entrance role (even if it should be implicit from the tag
amenity=parking_entrance...). For the perimeter role, it may be more useful
when multiple polygons are in the site relation (like for historic castle
where you could have the whole site but also the inner court, ...). In case
of parking site relation, the perimeter role is maybe less useful as the
perimeter should always be the polygon with amenity=parking, but i'm not
really taking position on this old debate about implicit vs explicit values.

I often dupplicate the tags from the site relation to the amenity=parking
polygon (or a node/polygon for other site relation like for
historic=castle). And only to get "useful" data for most apps and services
that don't use site relation at all (i think only http://gk.historic.place/ use
site relation for historical features). For parkings, most of the tags are
duplicated by using the common scheme (polygon with amenity=parking) and
the "advanced scheme" (with site relation like in the proposal), all this
because i maintain compatibility with both scheme (which is good and
bad...).And as the site relation are mostly ignored by most tools and maps,
it doesn't matter at the moment. Finally, i find the site relation very
useful to quickly query the whole group of elements member of a site).

*@Martin*, I tried to use multipolygon relation for this before, but it is
not good in some cases. The site relation allow to group elements where a
multipolygon is not correct : like for university buildings dispersed into
a city (ex:
https://www.openstreetmap.org/relation/8148420#map=18/50.66823/4.62058),
where you can't make a multipolygon to group every elements of the
university (they can be nodes too), and using multiple "amenity=university"
is wrong as there is only one university.
It also allow to group elements like you would with relation=stop_area in
the public transport scheme (i.e. grouping every element at the same
location that are part of the same "site"). It is useful to group
historical elements of a castle for exemple (the moat, the walls, the
towers, the bridge, ...) to distinguish the part that are historic to the
ones that are not historic at all. I also use the relation to put the
"heritage" tag applied to the "Site" as a group (when it fits no other
polygon).

And as described in the site relation proposal, we should not use the site
relation, when everything fit into one area (like an area with tag
"amenity=school" or "amenity=university"). The parking site is an exception
in this to me, as the relation allow easier maintenance/selection of so
many polygons linked to the area (when you tag individual parking_space...)
and it allow to have only one scheme for every parking (the ones that are
only on the surface, the one that are underground AND the ones that are
both at the same time (like this one :
https://www.openstreetmap.org/relation/8431818 where i tagged the
underground part only with the parking_entrance nodes).

Le jeu. 13 sept. 2018 à 23:32, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > On 13. Sep 2018, at 22:35, OSMDoudou <
> 19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> >
> > What do you think ?
>
>
> I’m hardly using the site relation because you can express almost
> everything spatially (a (multi-) polygon for the site, everything inside is
> automatically part of the site), unless you want to employ specific roles
> or want to add lines and nodes outside of enclosing polygons. The roles
> you mention do not make a lot of sense:
>
> perimeter: this is usually implicit in the geometry
>
> entrance: this is also implicit in the geometry (a node with
> entrance=main/yes in the perimeter)
>
> label: nobody (AFAIK) uses this. A good label position depends on other
> factors (scale, other things labeled, etc.) which have to be determined
> individually for each map and situation, nothing you should map (it is not
> geodata).
>
>
> cheers,
> Martin
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[Lionel Giard]

In my use of the site relation, i try to add a polygon to indicate the
perimeter (when possible) like in the proposal of the site relation (
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site) and i use the
"amenity=parking" polygon for the site=parking. And then i add everything
that is inside the "site perimeter" like parking_space, services roads and
parking_aisle, vending machine, parking_entrance (if underground), ...

For underground parking, i tend to only put amenity=parking on the site
relation and don't draw a polygon (except when it match exactly a building
outline, then i use it as perimeter).

Le mar. 11 sept. 2018 à 21:00, OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> a écrit :

> Hello,
>
>
>
> When micro-mapping parkings, amenity=parking_space are to be brought into
> a relation (type=site and site=parking). [1]
>
>
>
> But I find it strange the "outer" object (i.e. amenity=parking) doesn't
> need to be added to the relation.
>
>
>
> I would have expected something like inner / outer in multipolygon
> relations to indicate to which parking the paking space belongs. [2]
>
>
>
> Any thoughts ?
>
>
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space
>
> [2] https://wiki.openstreetmap.org/wiki/Relation:multipolygon
> ___
> 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] Designated value as a key

[Lionel Giard]

I'm not seeing much difference seeing "designated=bicycle" versus the
in-use combinaison "bicycle=designated" (same for the other common tag like
motor_vehicle) except that the first one would use a different "access
paradigm" than everything else. That's not really a simplification to me,
and i don't understand the reason that you would use that. Is there really
a big problem in the processing of such access tag by software ?

For the very specific employee access, why is it better to use the
"designated subtag" instead of using a "private=Repsol workers" subtag ? As
most employees-only access are tagged via access=private.

Le dim. 9 sept. 2018 à 12:46, Philip Barnes  a écrit :

> Local bus is already covered by the psv tag, public service vehicle.
>
> I assume by schoolar you mean scholar? I would consider scholar an
> outdated term, something my grandparents used to say. It is more common to
> refer to students in modern English, which I believe is what you have in
> Spanish?
>
> Phil (trigpoint)
>
> On 9 September 2018 10:08:42 CEST, yo paseopor 
> wrote:
>>
>> Hi!
>>
>> When I tag the access to a way reading the meaning of the traffic sign I
>> miss some specific conditions. I know I can do it at general times with key
>> access, but in specific cases access is so "small for me". There are also
>> conditional tags but with these two keys I don't arrive to cover local
>> meanings and situations of restriction to some vehicles (example, you have
>> a living street, which is only allowed for the LOCAL bus line, nor the
>> other buses. So you can't tag it with bus=yes or bus=designated within the
>> complete meaning of the restriction given you by the traffic sign.
>>
>> For these situations I propose to "flip" designated value and convert it
>> to a subkey. In that way you would have an escalable subkey that you can
>> complete with the specific information of that tag. This key will be
>> together with the combination access=designated so you can complete the
>> information of the specific designation
>>
>> access=designated
>> designated=local_bus
>>
>> designated=bicycle
>> designated=motor_vehicle
>> designated=pedestrian
>> designated=Mo-Fr 9:00-9:30
>> designated:en=schoolars only
>> designated:ca=Només escoles
>> designated:es=Solo escuelas
>>
>> This also applies for other uses like some restrictions done by "marks"
>> (Example: in a industrial zone you have some private ways...but private of
>> who? In the reality you will have a traffic sign it says you who can pass
>> or who cannot)
>> With normal access scheme you would say...repsol_workers=yes but Would it
>> better if I can specify the "specific designation" ?
>>
>> access=designated
>> designated=Repsol workers
>>
>>
>> hey! but you have access tags yes/no to do that! ...And the software has
>> to guess which of the 32 keys with yes=no is for access . For general
>> purposes it's ok. But for an specific case the software can read this
>> designated value.
>>
>> What do you think?
>> Salut i accessos designats (Health and designated access)
>> yopaseopor
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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] Tagging suggestions for electricity

[Lionel Giard]

I'm also thinking that power_supply is different, as it give only
information of the type of power plug available in a location ! Implicitly
it would probably mean there is electricity there but for private houses,
we can't know that information without entering houses, and it doesn't say
if they have electricity from the grid or something else. And i don't think
the original idea is to get that much details (power_supply is a really
specific tag).

The proposed electricity tag is more general, and more useful to the idea
of knowing if there is electricity or not at some buildings, which can be
known from outside the building (like if there are power cable coming from
the grid or just asking people a simple question "do you have electricity
?" without needing to visit the house). That's useful information for
research and humanitarian uses (especially in developing countries).

Le mer. 29 août 2018 à 12:26, seirra  a écrit :

> wouldn't the use of access:private be sufficient? that would tell people
> the building is private meaning anything inside must be too. power supply
> already allows voltage and actually does allow intermittent now i look
> back. due to the fact electricity would often lead to the presence of a
> socket (and often all the same type) i imagine there might be a difficult
> overlap is all
>
> On 08/29/18 10:37, Dolly Andriatsiferana wrote:
>
> Thanks seirra for pointing to power_supply. But I don't know if it can
> really be applied to individual private buildings? Because as far as I
> understand it is to be used for services or amenities like camp sites, ie
> whether you can get power there to plug your electrical stuff? The
> difference is that electricity=* (or whatever should be used) is to
> indicate that there's a source of electricity power feeding a
> building/settlement but it doesn't have to be provided as part of a service
> for example.
>
> Le mer. 29 août 2018 11:56 AM, seirra  a écrit :
>
>> you might find power_supply to be better suited as it is already
>> documented https://wiki.openstreetmap.org/wiki/Key:power_supply it
>> already covers all of those topics except for intermittent, although if it
>> is relevant i don't see why you can't put it
>>
>> On 08/29/18 05:46, Dolly Andriatsiferana wrote:
>>
>> Hi,
>>
>> I was searching for a tag to indicate if a building has electricity or
>> not, and if possible to specify the electricity source. I've found no
>> documented tag, but a search on taginfo [1] led me to the key
>> electricity=*. Currently it's being used mostly with values
>> solar/none/generator/yes/always.
>>
>> On OSM Help [2] someone proposed the following tagging which seems better
>> in my opinion too:
>>
>>- electricity=yes/no/intermittent - to indicate the presence of
>>electricity
>>- electricity:source=solar/generator/distribution_company/windmill...
>>- to specify the electricity source
>>- electricity:voltage=* - the electricity voltage
>>- other details using namespaces...
>>
>> What do you think? Has someone here used the electricity=* tag before?
>> Afterwards we might be able to start documenting the tag on the wiki.
>>
>> Cheers,
>> Dolly
>>
>> [1] https://taginfo.openstreetmap.org/keys/electricity
>> [2]
>> https://help.openstreetmap.org/questions/65477/indicate-if-a-building-has-electricity-or-not
>>
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] undersea tourist route

[Lionel Giard]

I also agree with the location tag as it say it is underwater, while the
other method say that the path is made of "water" (as it would be made of
gravel or asphalt in other places).

Note that the tag layer=-1 don't mean anything by itself (if there is no
other data at the same location) as it is a relative tag (layer -1 means
below other element with layer 0 or above). And as you are not below the
water but in it, you can't technically use that to indicate underwater
element.  One example of feature below the water is the "Channel Tunnel"
between France and England, where it is technically in the rocks below the
sea, that's not the same thing that you want here. :-)

2018-08-08 11:18 GMT+02:00 Javier Sánchez Portero :

> I think that location=underwater is more exact that surface=water. With
> the second I expect to walk over the water like Jesus.
>
> Javier
>
> El mié., 8 ago. 2018 a las 1:13, Warin (<61sundow...@gmail.com>) escribió:
>
>> On 08/08/18 09:01, marc marc wrote:
>> > Le 08. 08. 18 à 00:26, Warin a écrit :
>> >> A scuba or snorkel route - some concrete drums with a chain between
>> then
>> >> and signs for people to follow. Like an under sea path.
>> > highway=path + location=underwater ? :)
>>
>> Humm
>>
>> highway=path
>>
>> layer=-1
>>
>> surface=water
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lane geometry in OSM

[Lionel Giard]

 > Also, I often see a center lane for left turns in both directions, as in
> https://ecn.t0.tiles.virtualearth.net/tiles/a0213330110033323031.jpeg?g=
6570
> That's next on my list.  It's currently tagged as a two lane road just a
> bit west of the intersection I referred to earlier.  Note the solid yellow
> lines which usually means "do not cross" to me, so I think I'll have to
> look up the law before I attempt to tag it.

You can tag it with :
lanes=3
lanes:forward=1
lanes:backward=2
turn:lanes:backward=left|through

and split the way where the two arrows are located, and inverse the tagging
on the other segment (put the lanes:forward=2; lanes:backward=1;
turn:lanes:forward=left|through).
As i suppose you should not drive further than the arrow in either
direction. So you have "two turn lanes" facing each other (that's more or
less what it looks).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lane geometry in OSM

[Lionel Giard]

 If you look at the wiki page about different lanes tagging (
https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a suggested
way of tagging (in "Examples/Motorways") is using letter to indicate which
lane goes to where (when there is a transition). This could be used to
extent the width tagging for transition lane (where one lane split to two
(or conversely). There are already a lot of possibility to tag detailed
lanes, but we could indeed add the width in it !

PS: sorry for the previous message, i miss-clicked.

2018-08-03 13:08 GMT+02:00 Lionel Giard :

> If you look at the wiki page about different lanes tagging (
> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a suggested
> w
>
> 2018-08-02 23:56 GMT+02:00 Tom Hardy :
>
>> I've experimented a bit with lane and road attributes as in
>> https://www.openstreetmap.org/way/505256201 and the adjoining
>> intersection.
>> No width, but number, function and placement of lanes.  For placement, I
>> always selected the center of the throughway.  This allows renderers that
>> pay
>> no attention to lane attributes to render a straight line through an
>> intersection.
>>
>> JOSM's "Enhanced lane and road attributes" visualizer shows this quite
>> well.
>>
>> --
>> Tom Hardy 
>>
>>
>>
>>
>> ___
>> 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] Lane geometry in OSM

[Lionel Giard]

If you look at the wiki page about different lanes tagging (
https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a suggested w

2018-08-02 23:56 GMT+02:00 Tom Hardy :

> I've experimented a bit with lane and road attributes as in
> https://www.openstreetmap.org/way/505256201 and the adjoining
> intersection.
> No width, but number, function and placement of lanes.  For placement, I
> always selected the center of the throughway.  This allows renderers that
> pay
> no attention to lane attributes to render a straight line through an
> intersection.
>
> JOSM's "Enhanced lane and road attributes" visualizer shows this quite
> well.
>
> --
> Tom Hardy 
>
>
>
>
> ___
> 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] landuse=basin

[Lionel Giard]

I would also add that "water=reservoir" is a sub-tag of "natural=water";
while "landuse=reservoir" is a tag that can go alone by itself. The main
thing is that the second scheme is older than the first, and thus still
more used.
Looking at the proposal to "simplify water tagging" that was approved a few
years ago (
https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details ), the
new scheme is to use *natural=water + water=** on most of the water related
features.

For the reservoir/basin that don't always contain water (*especially for
storm water retention !*), we already have another tag : "landuse=basin"
that is for *" An area of land artificially graded to hold water." * so it
already cover this part and the sub-tag here are clearly made to describe
storm water retention/infiltration and some other artificial uses like that.
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin

Thus, the landuse=reservoir tag is mostly an older scheme that still exist
and evolve as there are a lot of use in the database. Maybe should it be
discouraged to simplify the water tagging ? At the end, it doesn't really
matter that much for data users as it is only two schemes that say exactly
the same things (with the same sub-tag "reservoir_type=*"), it is more a
complexity in the database that could probably be avoided.

2018-07-19 10:08 GMT+02:00 Warin <61sundow...@gmail.com>:

> On 19/07/18 16:53, Mateusz Konieczny wrote:
>
> 18. Lipiec 2018 16:02 od e...@eric-poehlsen.de:
>
> The present OSM meaning of landuse=basin is "An area of land artificially
> graded to hold water."
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin
> This does not distinguish it from water=reservoir
> OSM defined as "A reservoir or artificial lake used to store water."
> https://wiki.openstreetmap.org/wiki/Tag:water%3Dreservoir
>
>
> I think it should have the word "temporarily" add to read
>
>
> "An area of land artificially graded to temporarily hold water."
>
>
> I see it as similar to the bathroom basin - it holds water, but not all
> the time.
>
> Thoughts?
>
>
> Have you checked what is mapped? If mappers use both tags in the same way
> then
>
> redefining them on wiki without resurveying most of them is pointless.
>
>
> I have not 'refined' them. I have simply stated the usual configuration.
> It is done to help mappers differentiate between them.
>
> As both are rendered the same the effect is negotiable.
>
> Dams are usually seen in imagery. And the larger of them are mapped. So
> that can confirm that no reservoirs are mapped as basins.
>
> I would expect reservoirs have been mapped for some time in OSM and basins
> only recently so there will be a fair few basins mapped as reservoir.
> This is a practice of 'best fit' and at worst 'tagging for the render'.  I
> possibly have a few of them...
>
> If future renders distinguish between them then mappers will have
> motivation to correct any errors.
> At the moment that motivation is very small.
>
> Where someone has used both tags on the same object there is a problem...
> which is it?
> In that case I would first consult the history - what was it originally
> tagged, and then look at imagery for possible confirmation.
> If the imagery is poor then I'd go with the original mapper. Contacting
> the relevant mappers is also a possibility.
>
>
> ___
> 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] wall and block that aren't a barrier

[Lionel Giard]

The main idea that i got for barrier=retaining_wall is to indicate that
between the lower ground and the upper ground, there is a retaining wall
preventing the movement to got this way (most probably, car or bicycle
can't go through the retaining wall easily, as it act like a small
"cliff"). That's why it is a barrier.

In this example, only the wall would be indicated by this tag as it prevent
people to go directly in that direction easily (you would need to escalade
the wall), so it is better to take the path around with the stairs.

2018-06-11 18:25 GMT+02:00 Tobias Knerr :

> On 09.06.2018 23:13, marc marc wrote:
> > https://upload.wikimedia.org/wikipedia/commons/thumb/2/22/
> Rehbrunnen_04.jpg/800px-Rehbrunnen_04.jpg
>
> Based on this picture, the current mapping is clearly incorrect. This
> basin doesn't qualify as a barrier=retaining_wall even if we allow for a
> very generous reading of the tag's definition.
>
> For most use cases, I believe it would be entirely sufficient to draw an
> area for the fountain, and add subtags as desired. For map users who are
> interested in how the fountain looks, the image and wikimedia_commons
> tags are already available.
>
> The mapper seems to be interested in going beyond that and creating a
> relatively detailed model of the fountain, which is a legitimate goal
> and might be useful in some applications, e.g. 3D rendering. However,
> I'd argue that our editors and data model aren't really the right tools
> for that job. It would seem more practical to create a model of the
> fountain in Blender or SketchUp, which could then be uploaded to the 3D
> Model Repository and linked with OSM.
>
> If we to try to model the fountain using OSM ways and areas anyway,
> though, then I'd rather see specialized tags for fountain micromapping
> (nano-mapping?) introduced. Re-purposing existing tags for this use case
> isn't a good idea imo.
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Telecom local netwoks

[Lionel Giard]

In Belgium, we often call them "Local EXchange (LEX)", that's a simple name
change from the "telephone exchange" that at least indicate that it is not
only telephone in it !
The name vary but it always refer to the same "central office or telephone
exchange" and the difference is probably only cultural/historical.

2018-06-11 8:32 GMT+02:00 François Lacombe :

> Hi all
>
> Le lun. 11 juin 2018 à 01:29, Paul Allen  a écrit :
>
>> It also states that in the UK, the switchgear is a telephone exchange and
>> the building the switches
>> are housed in is called a telephone exchange (we Brits aren't very
>> inventive where terminology is concerned).
>>
>
> Then we do have an issue here
>
> It's the same as calling this a "transformer"
> https://www.epcomediterranee.com/medias/fiches_produits/
> fiche/438-poste-de-transformation-couloir-de-
> manoeuvre-type-pac-4uf-5uf.JPG
>
> While it's a "power substation" (power=substation) building and the
> transformer (power=transformer) is actually inside
> http://www.infos-reseaux.com/photos/image/poste-de-
> distribution-transformateur-bt/48-24062008661.jpg
>
> Telephone exchange hosting buildings use to be tagged with man_made=MDF
> because the "Main Distribution Frame" is inside too. Moving from MDF to
> telephone exchange won't bring any benefit i'm affraid.
>
> I'm not focused on central_office anyway, but we need two different terms
> to distinguish buildings from hosted devices and central office is the best
> we found for buildings
>
> All the best
>
> François
>
> ___
> 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] Access=no for bus lanes

[Lionel Giard]

Yes the idea behind access=* is a general tag - it indicate for every other
transport types (except if another more specific tag is used) : so
access=private just say that for every type of transport it is a private
access, and if you add foot=yes, it became "private for everyone except
people on foot that can walk freely). There is a hierarchy as shown on the
wiki where a more specific access tag override restriction.

2018-06-08 11:25 GMT+02:00 marc marc :

> about "Bus-only roads"
>
> Le 08. 06. 18 à 11:00, François Lacombe a écrit :
> > highway=unclassified + access=designated + bus=yes + cycle=yes
>
> access=no + bus=designated (+ cycle=yes and/or taxi in some country)
> ___
> 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] The endless debate about "landcover" as a top-level tag

[Lionel Giard]

>
> Seriously, so much time wasted on discussing landuse=forestry and it has
> 9[sic!] uses.
>
I don't see the main argument as good. Any new tag is by definition not
used that much ! And most new mappers follow litteraly the rules of "we
should use the accepted tags in wiki...".


But whatever, as said before, we could take a step by step approach(and
test it) :
- first, add landcover=trees in the renderer (putting it the same as
landuse=forest probably), just to make a get a better tagging in area that
are not a forest (in other landuse especially). It will gradually help to
reduce the quantity of "misuse" of the other tags "natural=wood" and
"landuse=forest" ;
- Then, discuss if we need to add a forestry tag and maybe make a proposal
for it. It could probably just be to create a *new *tag, and still use
"landuse=forest" when it is *unknown* (like for highway=road when we don't
know the type or usage of a road). This would have the advantage of being
backward compatible, just introducing a more precise tags for are with know
forestry use for example.

And most importantly, it would advance the discussion, as most people are
probably just looking for the first steps (having landcover=trees in an
renderer and presets, while the second part interest probably a smaller
fraction of the community (which are more into forest tagging - and i know
that some people are interested in Belgium).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging