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 Moll
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
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
parkin
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/o
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
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
impl
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=le
/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 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,
Adri
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%A9ren
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
--
PanierAvide
Géomaticien & développeur
___
Tagging mailing list
Tagging@openstreetmap.org
h
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
Hello,
I think as it is already widely used (+24000 objects), it would be best
to use a Taginfo template (like for [1]). But this imply to create a tag
page for each value. So two solutions : create a handmade template (for
this maybe you can use the name "Template:Map Features:support" as it
jmen
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
--
PanierAvide
Géomaticien & développeur
___
Tagging mailing list
Tagging@openstreetmap.o
dering 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
"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.
PanierAvi
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 be
Hello,
Maybe this can be included in the "events_centre" proposal [1], which
can be extended to cover places that hosts private events.
[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Events_centre
Le 05/03/2015 21:27, Andrew Guertin a écrit :
There are a number of places in my are
Hello,
Le 22/01/2015 17:50, Andreas Goss a écrit :
I just created the page, because the tag was used (TagInfo), but not
documented. See:
http://wiki.openstreetmap.org/wiki/Category:Undocumented_Tags
And I added some more explanations on it because it was marked as undocumented.
The added
://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_water_slides
PanierAvide.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Le 05/08/2012 11:49, Vincent Pottier a écrit :
But in my dictionnay, for the French "dossier", I find "back". No
backrest.
Backrest seems to be correct : "the back piece of a chair, used to
support the sitter's back" [1].
[1] http://en.wiktionary.org/wiki/backrest
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
22 matches
Mail list logo
