Re: [Tagging] All European Union countries use E5/E10/B7 instead of gasoline 98/95, Diesel 10S respectively

[PanierAvide]

Hello,

Same in France, fuel stations have to display new naming (and most do), 
but old names "SP95", "SP95-E10", "SP98" and "Diesel" are still shown 
and will stay for many years at least.


Regards,

Adrien P.

Le 25/01/2020 à 09:38, Frederik Ramm a écrit :

Hi,

On 1/25/20 08:26, Thibault Molleman wrote:

Back in 2018 all countries in the European Union were forced to switch
their naming scheme

That may well be but the fuel stations in my vicinity still advertise
"Diesel" and not "e10", so at least for the part of Germany where I
live, "fuel:b7" would be definitely wrong.

Bye
Frederik



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

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

[PanierAvide]

Well this specific case is quite easy to detect : if a parking space is 
contained in a wider parking, you subtract the amount of places in 
parking space from larger parking. And it would be easier to handle if 
capacity tags are using same naming on both instead of being different 
and needing to check access tags.


Regards,

Adrien P.

Le 17/01/2020 à 10:38, Joseph Eisenberg a écrit :

According to the wiki documentations, amenity=parking_space was
intended to be used inside of a larger amenity=parking feature.

So if there larger amenity=parking has capacity:disabled=4, you would
expect to find 4 amenity=parking_space features inside of it which are
available for disabled people.

If you use capacity:disabled on both features, this might lead to
double-counting.

- Joseph Eisenberg

On 1/17/20, PanierAvide  wrote:

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 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] Question about capacity:*=* on parking_space

[PanierAvide]

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 list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Indoor] is indoor=level walled ?

[PanierAvide]

Thanks for this feedback. In these examples, I would say that there is 
still a clear delimitation of what outside and what is inside, so can be 
addressed with Simple 3D buildings modelling. My question is oriented in 
a particular case where you don't have a very precise delimitation of 
inside/outside, like this parking lot :


https://commons.wikimedia.org/wiki/File:Parking_Building_(41640900211).jpg

As level 0 doesn't have wall, if you are near the building "limit" you 
can consider being outside, but at the center of this level you are 
clearly inside (covered, maybe warmer). So how can we represent this 
lack of walls, but looking more like something inside ?


Best regards,

Adrien P.

Le 26/07/2019 à 13:39, Martin Koppenhoefer a écrit :
Am Fr., 26. Juli 2019 um 13:18 Uhr schrieb Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>>:


no, I would put it like this: the ground floor is still part of
the building, but it is outside. Like a balcony for example. Would
you say a balcony is "inside"?



I guess this was too short, here's a more exhaustive take on the 
typical situations:


1. iconic building by le Corbu: 
https://upload.wikimedia.org/wikipedia/de/a/af/Villa_Savoye_2015.jpg 
This is a typical example for a raised modernist building.
the space where you can see chairs is IMHO clearly not "indoor", I 
would tend to accept it is part of the building (because it is 
"created"/delimited by the building and intended as usuable space), 
but you could also argue it is part of the garden, the architect even 
emphasizes this by using the same pavement as for the driveway (at 
least it looks like this on the picture).


These are typically cases where the building is raised above the 
ground in order to make use of a covered outdoor space, e.g. to use it 
as part of the garden, or to park a car, or as common space for the 
residents.



2. reconstruction of prehistoric raised buildings inside the Lake of 
Constance: 
https://upload.wikimedia.org/wikipedia/commons/2/2e/Pfahlbaumuseum_Unteruhldingen_Steinzeith%C3%A4user_Riedschachen_2010_04_10.jpg
I would tend to count the outdoor space below the "house" as not being 
part of the building (conceptually, the building is standing on legs, 
and while the legs are part of it, the area where they stand could be 
considered as not part of it). The area not being usable/accessible 
contributes to this judgement.
There are similar examples all over the world, e.g. here: 
http://bilder.net/bild-h%c3%bctte-urwald-orinoco-2335.jpg or here 
http://www.amliebstenreisen.at/bilder/2015/02/junglebay-2-660x330.jpg
These are generally cases where the building is raised above a 
"hostile" environment, e.g. to protect it from water, wild animals, 
enemies, or to create a level surface in an inclined surrounding. 
Typically the space below is not used in these cases. I would not 
consider the (unmodified / unaltered) ground below the building to be 
part of the building.



In all cases, I would not consider these indoor spaces, because they 
can not be heated or cooled, while you may be protected from the sun 
and precipitation you will still feel more outside than inside, typically.


I acknowledge there are many different situations and you will have to 
assess these individually, there will surely be a lot of edge cases. 
How you see them may also depend on the climate in the area in 
general, e.g. there are also lots of houses that are neither cooled 
nor heated, and some may have openings that cannot be closed rather 
than windows.


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] [Indoor] is indoor=level walled ?

[PanierAvide]

Thanks for your two answers.

Le 26/07/2019 à 13:02, Martin Koppenhoefer a écrit :

are they “indoor” if there is no wall? What makes them be inside rather than 
outside?

Are covered open spaces inside or outside? I would tend to “outside”
as the climate will be similar to the climate around the structure, rather than 
comparable to the room climate of a completely enclosed space.


They are still indoors (at least conceptually) because the building 
footprint is still there. Having ground floor unwalled doesn't mean that 
upper levels can't have wall. So, in that case, you suggest that 
building for example start at level 1 (with min_level=1) and everything 
on ground floor is outside ? Then, how can I map for example a very 
small room on this area ? Still with indoor=room, even if technically 
not inside a building ?


I like the suggestion of Tobias to add wall=no on indoor=level, it seems 
to break less thing and make explicit the exception of one particular 
level being unwalled.


Best regards,

Adrien.


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

Re: [Tagging] [Indoor] is indoor=level walled ?

[PanierAvide]

Hello,

Thanks for your answer. The use case I have in mind is a parking 
building, where ground floor hasn't really any wall around it. As I use 
indoor=level to add information about the floor (name in particular), I 
was asking this to make sure this indoor=level object doesn't create any 
implicit wall. If so, I can model rest of this floor using 
indoor=area/room without having a wall closing the whole level.


I also use level=* as defined in Simple Indoor Tagging, and I'm aware of 
level:ref=*. But level:ref=* is made for saying "this feature belongs 
the level named XYZ", which is another use case.


Best regards,

Adrien P.

Le 24/07/2019 à 03:18, Warin a écrit :
I'd use indoor=room for an area that is enclosed by a wall, after all 
that is a room.


indoor=wall to me is a free standing barrier within a room.

A pillar? Humm you could model it as a wall.

If the building has multiple levels then using the level=* tag says 
what level the thing is on. A wall could be only on one level, or a 
few .. I'd want to tag that . A pillar could flow from bottom level to 
top level.


I don't use indoor=level, I do use level=* and level:ref=*.

See https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging

And I'd look at  some tagging examples on level up
https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging#Tagging_Examples_.28alphabetical.29 



___
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] [Indoor] is indoor=level walled ?

[PanierAvide]

Hello,

I'm currently working on a project involving editing of indoor features. 
Regarding Simple Indoor Tagging scheme :


"indoor=level is optional and not intended for rendering purposes, but 
for having a place to add additional information like a floor name"


So according to wiki, indoor=level doesn't involve having a implicit 
wall following the geometry. Is it something we agree on ?


In that case, if I need to create an explicit wall following the contour 
of the indoor=level feature, I should create another way with 
indoor=wall tag. According to wiki, indoor=wall can only be used on 
lines, so if I create a closed line, it should not render as an area 
(same behaviour as footways). Is it also something we agree on ?


Last question, if I want to create a wall as an area (imagine for 
example a wide pillar where no one can enter), should I just use 
indoor=wall + area=yes ?


Best regards,

--
Adrien P.


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

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

[PanierAvide]

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 list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wheelchair designated parking space tagging?

[PanierAvide]

Le 10/01/2019 à 00:19, Warin a écrit :


No - that is a terrible page.


and the work in progress at
https://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel


Much better .. but unordered.


Hopefully we are using a wiki, this could be improved by anyone for sure ;-)

Regards,

Adrien.


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

Re: [Tagging] wheelchair designated parking space tagging?

[PanierAvide]

Hello,

The french community has started months ago creating this page in order 
to list tags around disabilities, and how to practically map associated 
features (and referencing "concurrent" tags when multiple schemes exists) :


https://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel

This is still a work in progress, but can give some ideas for creating 
such an entry page in english.


Regards,

Adrien.


Le 04/01/2019 à 23:22, Warin a écrit :
Possibly there needs to be a main wiki page for 'disabled' features 
tagging, toilets, tactile paving, parking, access.


On 05/01/19 07:58, Paul Allen wrote:
On Fri, 4 Jan 2019 at 20:44, Richard > wrote:


looking through the wiki can't find how parking space designated
for wheelchair/disabled users should be tagged?

See https://wiki.openstreetmap.org/wiki/Tag:amenity=parking or 
capacity:disabled.  Note
carefully the definition of capacity: it is the TOTAL number of 
spaces INCLUDING disabled
spaces because an armchair mapper may be able to count parking bays 
but not discern

which (if any) are for disabled parking.

If you intend to mark actual parking spaces rather than just denote 
the car park as a whole,
see https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space 
and associated

proposal.

--
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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 3d-tagging

[PanierAvide]

Hello,

This one is the common way to do 3D tagging on OSM :
https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

It is already used by several renderers (F4Map, OSM2World...), all 
supported software is listed in the page.


Regards,

Adrien.

Le 24/05/2018 à 11:01, Stefan K. a écrit :
I found a wiki for 3d-tagging, is that a proposal? Can i tag using 
theses suggestet tags?
Unfortunately i could not find a 3d-mailinglist so i thought i mayb 
try it here. The 3d section in the forum seems not to populated 
unfortunately, i would prefer it over the mailing-list :(


Greetings


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



--
PanierAvide
Géomaticien & développeur


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

Re: [Tagging] Feature Proposal - RFC - CoreIndoor

[PanierAvide]

Hello,

Thanks for this work and this proposal. As an indoor mapper, I find 
these edits to the Simple Indoor Tagging full of sense. They document 
some local practices (level:ref is already used in France for complex 
buildings) and also makes clearer how to consume data (repeat_on + 
decimal values for example). Also something good is that it is fully 
compatible with previous way of tagging, just refining it. In my 
opinion, it is a good proposal :-)


Regards,

PanierAvide (creator of OpenLevelUp).


Le 08/02/2017 à 09:09, Pavel Zbytovský a écrit :

Hello,

I have some points about indoor mapping. There is already an 
established tagging scheme - the Simple Indoor Tagging - but I think 
it could be refined a little. Especially it doesn't allow for easy 
corridors placement, and also some definitions could be more rigorous. 
Last year I finished my thesis on the topic of Indoor mapping and also 
submited a pull request for iD editor (see zby.cz/thesis 
<http://zby.cz/thesis>), now I created a proposal to move us little 
bit further:


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


I would be glad for comments, and I hope we could make OSM the best 
indoor map ever :-)


Pavel Zbytovský
zby.cz <http://zby.cz>
openstreetmap.cz <http://openstreetmap.cz>


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



--
PanierAvide
Géomaticien & développeur

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

Re: [Tagging] Artworks inside the Louvre

[PanierAvide]

In my opinion, adding indoor=yes on every single indoor object doesn't 
make sense, as we know they are indoors because they are inside a 
building area and possibly have some indoor tags like level=*.



Le 24/07/2016 à 00:42, Daniel Koć a écrit :
We are on the way to render artworks on osm-carto (default map layer 
on main website), but during testing phase I've found that in Louvre 
they are tagged not only on the exterior, but also some of them are 
inside the building (as part of the permanent exposition, I guess).


This made me think if - and how - should we tag such features? Current 
definition is laconic and does not help in this case ("A tag for 
public pieces of art"). Should we just add "indoor=yes" (currently 
67k+ uses), find new tagging scheme or just introduce a policy which 
doesn't let tagging them?


It is important for a rendering strategy - we're not able to recognize 
which are visible outside and which are not and it creates a visual mess:


https://github.com/gravitystorm/openstreetmap-carto/pull/2236#issuecomment-234687333 






--
PanierAvide
Géomaticien & développeur


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

Re: [Tagging] Opening hours specification

[PanierAvide]

The interest of this overly complicated specification is that it makes 
developers life easy ;) Obviously, it has to stay in phase with the way 
opening_hours is really used. So if the separator is not used, it will 
be removed from YoHours. Note that this optional separator is also 
readable by opening_hours evaluation tool [1], which seems to be a 
reference.


[1] http://openingh.openstreetmap.de/evaluation_tool/


Le 21/08/2015 12:36, Ruben Maes a écrit :

I opened an issue[1] on this GitHub project, because it puts a colon after 
week, month and monthday selectors.
PanierAvide replied that the specification allows an optional separator for 
readability[2]. Indeed, when you read the overly complicated and totally not 
mapper-focused specification, you can see
[ year_selector ] [ month_or_monthday_selector ] [ week_selector ] [ 
separator_for_readability ]

Whose idea was this? It's already complicated enough that you don't have to add 
*optional* separators for supposed readability.
IMO it's just fine without them.

PS: I always follow the time domains proposal[3]. It's clear and it's 
compatible with the other specification AFAIK.

[1] https://github.com/PanierAvide/panieravide.github.io/issues/1
[2] 
https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#separator_for_readability
[3] https://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains



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

Re: [Tagging] Feature Proposal - RFC - indoormark=beacon

[panieravide]

Hello,

Why don't you use the indoor key directly ?

Cordially.

Le 2015-07-30 11:36, Guillermo Amat a écrit :

Hello

My group is working on an indoor project and we have the necessity to 
place

indoor beacons inside a building. As we are using OSM, we need a way to
store all the data for any beacon in order to position the user and 
provide

navigation.

Our proposal is based on what we have found for labeling beacons for 
sea
https://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values and 
air
https://wiki.openstreetmap.org/wiki/DE:Tag:airmark%3Dbeacon 
transport.


https://wiki.openstreetmap.org/wiki/Proposed_features/indoormark%3Dbeacon

Regards



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

[Tagging] Water slide as waterway

[panierAvide]

Hi,

User RicoZ has launched a new discussion about water slides tags, in 
order to consider them also as waterways. It is an interesting question 
and we need more opinions about it. He wants to keep the discussion on 
the wiki so if you want to take part of it, you can go here : 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_water_slides


PanierAvide.

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

Re: [Tagging] Feature Proposal - RFC - playground:splash_pad

[panierAvide]

Le 19/07/2011 13:30, Matt a écrit :

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

Please comment.

Thanks,
Matt
This proposal seems good in my opinion. Just why don't you recommend to 
tag it as area ? We sometime see some smaller buildings tagged as area, 
if a precise source exists I don't see why it couldn't be tagged as an 
area too.
Otherwise, could also be a good idea list tags that can be added to 
define more precisely the object (width=* if it's a node, when the 
splash pad is open/works, age restriction if there's one...).


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