Re: [Tagging] site relations for city walls?

[Yves]

Le 15 juillet 2020 23:10:52 GMT+02:00, Martin Koppenhoefer 
 a écrit :

>Generally I would agree with Paul, maxstay of a few minutes isn’t actually a 
>„parking“ 

I doesn't agree.
Yves 

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

Re: [Tagging] Intermittent highways?

[Warin]

On 15/7/20 5:07 pm, Martin Koppenhoefer wrote:



sent from a phone


On 15. Jul 2020, at 00:49, Justin Tracey  wrote:

If the festival is held at some date expressible using the opening 
hours syntax, you could use the "open hours" tag[0] or add conditions 
to the "access" tags



I would not use opening_hours tag to represent the temporary existence 
of ways if this should mean that the ways are only there some weeks of 
the year.


If the thing is permanently scheduled event then it is not a temporary 
event.


Temporary: Lasting for only a limited period of time; not permanent. 
Source - Oxford Dictionary.


Opening hours have no restriction to being more or less than some 
proportion of a year.



Similarly, access is about legal access and not physical existence. 
With the established schemes, you could use conditional on the 
highway, like highway:conditional=footway/service/path @ Time

it is not common, but someone else already had this idea as well:
https://taginfo.openstreetmap.org/keys/highway%3Aconditional



As you say - not common and probably not rendered/used by any application.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] site relations for city walls?

[Martin Koppenhoefer]

sent from a phone

> On 15. Jul 2020, at 16:17, Matthew Woehlke  wrote:
> 
> On 15/07/2020 03.33, Martin Koppenhoefer wrote:
>> Also you should not have 2 objects amenity=parking which cover the same
>> area (regardless of additional tags).
> 
> Do you mean having that on both the relation and the areas?


yes, you should have it only on the relation 


> 
>>> two parkings operated by the same
>> business, not one parking spread over 2 areas.
> 
> Okay, I'm curious now, how would you treat 
> https://www.openstreetmap.org/way/117565094 and 
> https://www.openstreetmap.org/way/117565096. IMO those are both part of "the 
> same lot", split across a road, or at least they are parking for the same 
> place (SPAC)


they are both parkings for the same place, but you can see them as 2 different 
parkings, one east, the other west of the road.


> 
> Of course, now that I've mentioned it, how do you note that 2 out of 20 
> spaces are maxstay=15? (I've seen that...)


if there are tags for stating this on the whole parking, I am pretty sure almo  
nobody will be evaluating it ;)
you could map the 2 individual spaces with the parking_space tag and the 
maxstay.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

Generally I would agree with Paul, maxstay of a few minutes isn’t actually a 
„parking“ 

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 15/07/2020 05.43, Paul Allen wrote:

On Wed, 15 Jul 2020 at 08:35, Martin Koppenhoefer wrote:

there is the "maxstay" tag which can be used with a value like 5 or 15
minutes.
https://taginfo.openstreetmap.org/keys/maxstay#values


That works semantically, but the rendering is (on many cartos) misleading.
If it looks like a car park on the map, people assume it's a car park.  Few
will go to the trouble of querying the tags to find there's a max stay.


...which is IMHO dumb, because time-limited parking is extremely common 
in some instances (especially metered parking in cities). Granted, the 
maximum stay is usually hours, not minutes. OTOH...



The label would help avoid confusion but to me it doesn't feel like a
car park as I understand the term.
...15-minute parking for a store in which you usually don't spend a lot 
of time doesn't really make it "not parking" either.


--
Matthew

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 15/07/2020 03.33, Martin Koppenhoefer wrote:

Also you should not have 2 objects amenity=parking which cover the same
area (regardless of additional tags).


Do you mean having that on both the relation and the areas?


Am Mi., 15. Juli 2020 um 01:40 Uhr schrieb Paul Allen :

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.


Okay, I'm curious now, how would you treat 
https://www.openstreetmap.org/way/117565094 and 
https://www.openstreetmap.org/way/117565096. IMO those are both part of 
"the same lot", split across a road, or at least they are parking for 
the same place (SPAC). For that matter, I think most people would 
consider my original example, or certainly Delmonico’s next door (west) 
as a single lot.



(BTW, is there any accepted way to tag a 'carry-out only' space?)


there is the "maxstay" tag which can be used with a value like 5 or 15
minutes.
https://taginfo.openstreetmap.org/keys/maxstay#values


Yes, but a) there is no explicit time limit (maxstay=carry-out?), and b) 
how do you apply that to only some spaces?


Of course, now that I've mentioned it, how do you note that 2 out of 20 
spaces are maxstay=15? (I've seen that...)


--
Matthew

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

Re: [Tagging] site relations for city walls?

[Matthew Woehlke]

On 14/07/2020 19.39, Paul Allen wrote:

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.


Oh, right, I keep forgetting about that. They're all notionally "the 
Chili's parking lot", but people use the back lot as overflow parking 
for other nearby locations (e.g. the office building to the immediate 
northeast). I'm sure they'd get annoyed at someone taking their "prime" 
spaces for that purpose, but I haven't observed them caring about folks 
in the far end of the back lot.


Maybe this is an argument for a site, instead?

OTOH, now we can rehash the access=destination discussion given that 
(most of¹) the lot isn't *explicitly* signed "customers only" and yet 
that's obviously the intent.


(¹ I would argue that the 'carry-out only' spaces qualify as 'customers 
only'.)



Even so, is a multipolygon giving any information that couldn't be had
by separate parking areas with the appropriate operator tag?


As I understand it, the operator tag is more of a legal thing (which I 
honestly wonder why or *how* we map) and not so much an "associated with 
such-and-such building" tag. Accordingly, it is clear as mud how I'm 
supposed to apply that tag.



(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.


Only specific parking spaces² are carry-out only. The lot as a whole — 
and I would expect most people to consider it *one* lot³ — contains a 
mix of several types of parking spaces, distinguished only by marking 
and/or signage. I think it would be odd to specifically carve out the 
carry-out-only spaces from the rest of the lot.


IMHO there should be a way to tag that a lot contains such spaces.

(² IMHO, any reasonable person is going to consider them parking spaces, 
even if they are implicitly limited to a very short time. On which note, 
'15 minute parking' spaces are also quite common, at least in my area.)


(³ Possibly, as I've drawn it, three lots, or anyway three clearly 
different 'sections' of something which conceptually is a single lot.)


--
Matthew

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

Re: [Tagging] site relations for city walls?

[Paul Allen]

On Wed, 15 Jul 2020 at 08:35, Martin Koppenhoefer 
wrote:

> Am Mi., 15. Juli 2020 um 01:40 Uhr schrieb Paul Allen  >:
>
> 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
>

That works semantically, but the rendering is (on many cartos) misleading.
If it looks like a car park on the map, people assume it's a car park.  Few
will go to the trouble of querying the tags to find there's a max stay.  The
label would help avoid confusion but to me it doesn't feel like a car park
as I understand the term.

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

Re: [Tagging] site relations for city walls?

[Martin Koppenhoefer]

Am Mi., 15. Juli 2020 um 10:03 Uhr schrieb Lionel Giard <
lionel.gi...@gmail.com>:

> 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 ^^).
>


yes, the site relation is useful when you have something that can be
considered a "site" and you have objects like nodes and lines that are not
inside the area. In theory it could also be useful if you want to have
specific roles (e.g. this is the ticket office for this site, or like in
your example, these are the vending machines for this parking). Or this is
the parking for this supermarket (if it is not adjacent/part of the area, I
have an example around here).

IMHO, a city wall around a city, fragmented or not, is not suitable as a
"site", because it is not "compact" (not sure about the right term).
Similarly, a university which is split across several, distant (relatively,
e.g. hundreds of meters or some kilometers apart) places, is not a "site",
it is rather several sites, and to draw them together, we usually employ
"tags". If you do not like to rely only on tags, a different kind of
relation would seem more appropriate. In the end it depends on scale what
is distant and what is close.



>
> 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 ? ^^*
>


you could have the parking as an underground area and the entrances part of
the perimeter, and you would not need a relation. I agree though that the
site relation seems appropriate for this case (underground structures are
generally a field of problems, e.g. because they are hard to survey and
they are confusing people because the rendering is often not appropriate.

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

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

[Martin Koppenhoefer]

Am Mi., 15. Juli 2020 um 09:45 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> If you are interested in reading some interesting thoughts about landcover
> classification, there is the FAO landcover classification system, thought
> to be useful globally:
> http://www.fao.org/3/X0596E/X0596e00.htm
>
>


there are only 8 main classes:
http://www.fao.org/3/X0596E/X0596e10.gif

and you can easily determine them through a decision matrix:
1. primarily vegetated or primarily non-vegetated?
2. terrestrial or aquatic/flooded regularly?
3. cultivated/man made/artificial or natural?

then they add additional properties like life forms, crops, leaf types,
climate, ...

>From the combination of these properties and classes, detailed land cover
classes are determined:


http://www.fao.org/3/x0596e/X0596e02a.htm#P1974_116516

E.g. here:

TABLE 3.4
*Example of the formation of land cover classes*

*EXAMPLE: "NATURAL AND SEMI-NATURAL TERRESTRIAL VEGETATION" (A12)*

*Classifiers used*

*Boolean formula*

*Standard class name*

*Code*

Life form and cover

A3A10

Closed forest

20005

Height

A3A10B2

High closed forest

20006

Spatial distribution

A3A10B2C1

Continuous closed forest

20007

Leaf type

A3A10B2C1D1

Broad-leaved closed forest

20095

Leaf phenology

A3A10B2C1D1E2

Broad-leaved deciduous forest

20097

2nd layer: LF, C, H

A3A10B2C1D1E2F2F5F7G2

Multi-layered broad-leaved deciduous forest

20628

3rd layer: LF, C, H

A3A10B2C1D1E2F2F5F7G2

Multi-layer broad-leaved deciduous forest with emergents

20630

Cheers,
Martin

PS: And the best: LCCS comes as a run time application, you do not need to
have virtual basic installed !!11!!!
___
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] Feature Proposal - RFC - (Ground)

[Martin Koppenhoefer]

Am Di., 14. Juli 2020 um 18:24 Uhr schrieb Volker Schmidt :

> I suggested this as a helpful guide when defining tag values. I don't
> think it can be used one-to-one for OSM.
> Bare ground, BTW, can be found also the area covered by CORINE, as it
> includes the Sahara for example)
>


right, but it still remains a system created for the automatic recognition
of features in 1:100.000 with generalized areas (min 25ha), for Europe. It
is not helpful for our purpose.
If you are interested in reading some interesting thoughts about landcover
classification, there is the FAO landcover classification system, thought
to be useful globally:
http://www.fao.org/3/X0596E/X0596e00.htm

One interesting find is the rejection of the term landcover for bare soil
for purists (and then admits they are usually contained) ;-)
http://www.fao.org/3/X0596E/x0596e01e.htm#p230_19485

> The definition of land cover is fundamental, because in many existing
> classifications and legends it is confused with land use. It is defined as:
>
> *Land cover is the observed (bio)physical cover on the earth's surface.*
>
> When considering land cover in a very pure and strict sense it should be
> confined to describe vegetation and man-made features. Consequently, areas
> where the surface consists of bare rock or bare soil are describing *land*
> itself rather than land *cover*. Also, it is disputable whether water
> surfaces are real land cover. However, in practise, the scientific
> community usually describes those aspects under the term land cover.
>

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

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

[mbranco2]

I found interesting the Corine definition for "3.3.3 Sparsely vegetated
areas" [1] : it refers to various scenarios, and specify a percentage
(10%-50%, or "less than 50%") for vegetation landcover.

In the similar American paper [2] mentioned in a previous post, we find for
barren land (page 18): "less than one-third of the area has vegetation or
other cover".

I think that using a vegetation percentage (less than ...) to define the
new tag should be the right choice; without this new tag, all is "scrub"...

[1]
https://land.copernicus.eu/user-corner/technical-library/corine-land-cover-nomenclature-guidelines/html/index-clc-333.html
[2] https://pubs.usgs.gov/pp/0964/report.pdf






Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] site relations for city walls?

[Martin Koppenhoefer]

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

Re: [Tagging] Intermittent highways?

[Martin Koppenhoefer]

sent from a phone

> On 15. Jul 2020, at 00:49, Justin Tracey  wrote:
> 
> If the festival is held at some date expressible using the opening hours 
> syntax, you could use the "open hours" tag[0] or add conditions to the 
> "access" tags


I would not use opening_hours tag to represent the temporary existence of ways 
if this should mean that the ways are only there some weeks of the year. 
Similarly, access is about legal access and not physical existence. With the 
established schemes, you could use conditional on the highway, like 
highway:conditional=footway/service/path @ Time
it is not common, but someone else already had this idea as well:
https://taginfo.openstreetmap.org/keys/highway%3Aconditional


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