Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Jarek Piórkowski]

On Fri, 24 Jul 2020 at 21:28, Jmapb  wrote:
> On 7/24/2020 7:12 PM, Cj Malone wrote:
> >> OSM does not store edit timestamps for individual tags, only for the
> >> object as a whole. Finding out when a tag was changed requires a
> >> review of the entire history. I had to do this once when I saw a
> >> clear highway=motorway_link tagged as highway=motorway, with me as
> >> the last user to edit that road segment. Turns out the original
> >> mapper was the one to make the tagging mistake, not yours truly, but
> >> I only found this once reviewing the history.
> >
> > Yeah, that option would require a new API and work done on the OSM
> > server to both calculate the last time a tag was edited, serve it and
> > store the timestamp when "touched" or updated. But once that's done
> > it's done for multiple clients, not just StreetComplete.
> >
> > Otherwise StreetComplete would need to use the History API one each
> > individual nwr and try to calculate the age of a tag.
>
> It sounds to me like what you're describing would require not just a new
> API but a change to the database schema to add a datetime field to each
> tag. Otherwise there would be no way to encode the timestamp of the
> confirmation of an existing tag that does not need changing.

That would be essentially the same thing as what's being proposed with
check_date-like tags, except at a lower level of abstraction. Might be
faster and available to more apps/for more purposes. But on the flip
side, of course new API versions and database fields are a much more
major change than a new tag scheme.

> The history API will only tell you when tags change.

Well, a new API endpoint _could_ automatically read through the entire
history of a node and note which tags changed when. It would
essentially be doing what I do when I open the node history in JOSM
and look when tags changed - only automated. That might well be faster
in the API, where database accesses and data processing is faster. It
would be slower than a dedicated database field, but would not require
the database migration.

--Jarek

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Jmapb]

On 7/24/2020 7:12 PM, Cj Malone wrote:




OSM does not store edit timestamps for individual tags, only for the
object as a whole. Finding out when a tag was changed requires a
review of the entire history. I had to do this once when I saw a
clear highway=motorway_link tagged as highway=motorway, with me as
the last user to edit that road segment. Turns out the original
mapper was the one to make the tagging mistake, not yours truly, but
I only found this once reviewing the history.


Yeah, that option would require a new API and work done on the OSM
server to both calculate the last time a tag was edited, serve it and
store the timestamp when "touched" or updated. But once that's done
it's done for multiple clients, not just StreetComplete.

Otherwise StreetComplete would need to use the History API one each
individual nwr and try to calculate the age of a tag.


It sounds to me like what you're describing would require not just a new
API but a change to the database schema to add a datetime field to each
tag. Otherwise there would be no way to encode the timestamp of the
confirmation of an existing tag that does not need changing. The history
API will only tell you when tags change. The tag validation from the
wizard you described two posts above -- there's no way to record that
validation. Except maybe to shoehorn it into the info tags on the
changeset itself.

My preference is to avoid updating a element if all info is complete and
nothing has changed. I suppose a single datetime field for last survey
might be workable, but I fear it will lead to giant bogus "survey"
changesets changing nothing but the "last survey" field. I don't think
the field would ultimately be trustworthy because it isn't verifiable.

Jason

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Cj Malone]

On Fri, 2020-07-24 at 17:48 -0500, Shawn K. Quinn wrote:
> On 7/24/20 17:20, Cj Malone wrote:
> > Alternatively if each storing when each tag has been validated is a
> > direction OSM wants to go, maybe it should be in the API. A client
> > like
> > StreetComplete could "touch" a tag to rev it's edited timestamp
> > without
> > actually changing the value.
> 
> OSM does not store edit timestamps for individual tags, only for the
> object as a whole. Finding out when a tag was changed requires a
> review of the entire history. I had to do this once when I saw a
> clear highway=motorway_link tagged as highway=motorway, with me as
> the last user to edit that road segment. Turns out the original
> mapper was the one to make the tagging mistake, not yours truly, but
> I only found this once reviewing the history.


Yeah, that option would require a new API and work done on the OSM
server to both calculate the last time a tag was edited, serve it and
store the timestamp when "touched" or updated. But once that's done
it's done for multiple clients, not just StreetComplete.

Otherwise StreetComplete would need to use the History API one each
individual nwr and try to calculate the age of a tag.


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Shawn K. Quinn]

On 7/24/20 17:20, Cj Malone wrote:
> Alternatively if each storing when each tag has been validated is a
> direction OSM wants to go, maybe it should be in the API. A client like
> StreetComplete could "touch" a tag to rev it's edited timestamp without
> actually changing the value.

OSM does not store edit timestamps for individual tags, only for the
object as a whole. Finding out when a tag was changed requires a review
of the entire history. I had to do this once when I saw a clear
highway=motorway_link tagged as highway=motorway, with me as the last
user to edit that road segment. Turns out the original mapper was the
one to make the tagging mistake, not yours truly, but I only found this
once reviewing the history.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Cj Malone]

On Fri, 2020-07-24 at 16:13 +0100, Jez Nicholson wrote:
> There must have been a long discussion on this, and I don't want to
> rehash it, but i'm surprised there was a positive response to adding
> check_date for individual attributesI can understand a check_date
> for a whole feature (as with the construction site), so for example a
> bus stop, I might be asked to check all the attributes (is there a
> seat? is there a bin? is there still a shelter?) and flag the whole
> bus stop as 'checked'.
> Could StreetComplete quests be built for confirming all attributes of
> an object, or are they limited to one (and hence your need to flag
> individual attribute checked dates)?

+1

Doubling (or near enough) the amount of tags on a given nwr seems a bit
excessive. StreetComplete could do a kind of wizard where is shows each
tag and asks the user to validate it, and only once all the tags are
shown to the user is an nwr considered confirmed, and adds a tag to say
it was surveyed or checked.

Alternatively if each storing when each tag has been validated is a
direction OSM wants to go, maybe it should be in the API. A client like
StreetComplete could "touch" a tag to rev it's edited timestamp without
actually changing the value.


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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[bkil]

OpenStreetMap is a shared database - you generally shouldn’t annotate
POI with tags for your own use.

Tags should correspond to ground truth - hence they need to pass the
verifiability. If I resurvey the POI, will I conclude the same future
todo_check_date=* that you have previously added? What if the
tolerance between the two of us don’t match, and I conclude that it
needs to be resurveyed in 1 year, while you would be sure that it
needs to be resurveyed in 1 month?

This sounds a bit like if we started adding fixme=update on
everything, and that is something that we should avoid at all cost
(everything is fixme and needs updating on OSM by definition).

I think everyone should maintain their own todo list on their own
devices and/or in some critical cases in the form of map notes if they
need help from the community.

Viewing from a different perspective: the choice of survey priority
should be decided in situ locally by the mapper who has capacity to do
regular verification. If people adding new POI overburden maintainers
with too short deadlines, all POI will show up as expired. However,
maintainers only have a finite amount of free time, so they will need
to prioritize their mapping activities by the cost to benefit ratio.
Hence they will probably sort by when a POI was last surveyed,
rendering todo_check_date=* redundant at best.

By the way, if a proper amount of people were actually using OSM data
and their applications supported an easy feedback mechanism, such
legwork would be obsolete. For example, if one navigates to a POI that
they find closed, why couldn't they just report it? Or even better,
couldn't we use data mining to get this information from their
location and interaction traces as others do (subject to consent)?

And on the positive side: when a user checks into a venue with their
social application of choice (be it Diaspora or Friendica) or if the
respective wifi network name shows up on a scan nearby, couldn't we
consider these as affirming signs?

On Fri, Jul 24, 2020 at 11:39 PM Peter Elderson  wrote:
>
> Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr :
>>
>> On 24.07.20 14:13, Peter Elderson wrote:
>> > In comparable cases (non-OSM, but comparible checking schemes), I do not
>> > record the date it has been checked, I record the future date when it
>> > should be checked (again).
>>
>> When it should be checked is opinion-based, though.
>
>
> True, and the opinion is the user's opinion at the time of the survey. You 
> can suggest a default re-check date for the type of feature (might also be 
> empty) and leave it up to the user to accept or change that.
>
>
>>
>> The date when you last checked a shop's opening hours it is a fact. But
>> opinions on how often one should revisit a shop to check the opening
>> hours again may vary a lot between mappers. So I think the former is
>> more suitable to be added to the OSM database.
>
>
> It's a historic fact, but it doesn't drive any plan.
>
>>
>> There are some comparatively rare cases where you know in advance that
>> something will change (e.g. with construction that is scheduled to be
>> finished by a particular date), but imo that's more the domain of
>> opening_date or temporary tags.
>>
>> > The routine is then, ask if check_date is absent OR when the current
>> > date is past the check_date.
>>
>> I don't think this is a big benefit compared to "... OR when the current
>> date is X months past the check_date".
>
>
> I think you are thinking code in the app, not maintaining a bunch of features 
> such as 35000 routes or all the Stolpersteine in the area
>
> The difference is the determination of X. It's feature and opinion-dependent. 
> Checking/displaying due checks is very simple, and doesn't have to know 
> anything, just compare the tag with the date, and all pop up.
>
>>
>> Also, I tend to prefer making software a little more complicated if it
>> lightens mappers' manual workload, so making at least some use of
>> history (e.g. so that no check_date needs to be set when a tag is first
>> added) seems reasonable to me.
>
>
> As a maintaining mapper, I would set the future check_date at entry time.
>
> Your plan sounds fine, but it will not be of much use to me. I still have to 
> maintain an agenda and listst for checks in the future. If a future check 
> mechanism were in place, I'd simply display a check map, just like a map 
> showing all notes or all fixme's.
>>
>>
>> ___
>> 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] Map maintenance with StreetComplete - Preferred tagging

[Martin Koppenhoefer]

sent from a phone

> On 24. Jul 2020, at 22:53, Tobias Knerr  wrote:
> 
> The date when you last checked a shop's opening hours it is a fact. But
> opinions on how often one should revisit a shop to check the opening
> hours again may vary a lot between mappers.



on the other hand the check date is already implicit (more or less) in the 
changeset timestamp. you probably wouldn’t add this kind of information months 
after the survey...

adding check timestamps as string tags for every single tag seems a lot of 
bloat. One tag per object for me would be acceptable because it is indeed a 
valuable information when something was last verified and no changes were 
necessary.
It could still lead to history bloat, imagine people verifying their 
housenumber every day. Technically it would be better to keep it separate (e.g. 
an additional table in the db without versions).
I can’t see an issue with splits, as the newly created objects would have a 
more current date anyway.

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Shawn K. Quinn]

On 7/24/20 15:51, Tobias Knerr wrote:
> The date when you last checked a shop's opening hours it is a fact. But
> opinions on how often one should revisit a shop to check the opening
> hours again may vary a lot between mappers. So I think the former is
> more suitable to be added to the OSM database.

There are places that change their hours seasonally, and remove all
traces of the off-season hours when they do. Laser Quest comes to mind;
as I remember it they tied it to about when the local school year starts
and ends, something not easy to do with opening_hours syntax as we now
have it.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Peter Elderson]

Op vr 24 jul. 2020 om 22:53 schreef Tobias Knerr :

> On 24.07.20 14:13, Peter Elderson wrote:
> > In comparable cases (non-OSM, but comparible checking schemes), I do not
> > record the date it has been checked, I record the future date when it
> > should be checked (again).
>
> When it should be checked is opinion-based, though.
>

True, and the opinion is the user's opinion at the time of the survey. You
can suggest a default re-check date for the type of feature (might also be
empty) and leave it up to the user to accept or change that.



> The date when you last checked a shop's opening hours it is a fact. But
> opinions on how often one should revisit a shop to check the opening
> hours again may vary a lot between mappers. So I think the former is
> more suitable to be added to the OSM database.
>

It's a historic fact, but it doesn't drive any plan.


> There are some comparatively rare cases where you know in advance that
> something will change (e.g. with construction that is scheduled to be
> finished by a particular date), but imo that's more the domain of
> opening_date or temporary tags.
>
> > The routine is then, ask if check_date is absent OR when the current
> > date is past the check_date.
>
> I don't think this is a big benefit compared to "... OR when the current
> date is X months past the check_date".
>

I think you are thinking code in the app, not maintaining a bunch of
features such as 35000 routes or all the Stolpersteine in the area

The difference is the determination of X. It's feature and
opinion-dependent. Checking/displaying due checks is very simple, and
doesn't have to know anything, just compare the tag with the date, and all
pop up.


> Also, I tend to prefer making software a little more complicated if it
> lightens mappers' manual workload, so making at least some use of
> history (e.g. so that no check_date needs to be set when a tag is first
> added) seems reasonable to me.
>

As a maintaining mapper, I would set the future check_date at entry time.

Your plan sounds fine, but it will not be of much use to me. I still have
to maintain an agenda and listst for checks in the future. If a
future check mechanism were in place, I'd simply display a check map, just
like a map showing all notes or all fixme's.

>
> ___
> 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] Map maintenance with StreetComplete - Preferred tagging

[Tobias Knerr]

Hi Tobias,

congratulations on your successful microgrant proposal! :) Maintenance
of existing data is a growing concern as OSM matures, so it's important
that we explore workflows for it.

On 23.07.20 18:06, Tobias Zwick wrote:
> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?

I think it would help with community acceptance of a potentially large
number of meta tags if you're somewhat frugal when it comes to adding
new ones. There is some cost in mappers feeling obligated to update a
"companion tag" every time they update a regular tag, as well as in
visual clutter. These downsides will both be lessened with better
tooling, but as of today that isn't widely available yet.

In practice, this could mean ...

* ... not adding key:check_date when the key is first added, or when the
value is changed as opposed to confirmed. (But update check_date tags
that already exist on the object, of course.)
* ... only using check_date where regular re-survey is plausible and
useful. This ties in with your observations on re-check intervals. For
example, there should be an opening_hours:check_date, but probably no
building:levels:check_date.

I don't have any strong opinions on this, and you seem to have given
this a lot of thought already. Just adding my gut feeling to the wisdom
of the crowd here.

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Tobias Knerr]

On 24.07.20 14:13, Peter Elderson wrote:
> In comparable cases (non-OSM, but comparible checking schemes), I do not
> record the date it has been checked, I record the future date when it
> should be checked (again).

When it should be checked is opinion-based, though.

The date when you last checked a shop's opening hours it is a fact. But
opinions on how often one should revisit a shop to check the opening
hours again may vary a lot between mappers. So I think the former is
more suitable to be added to the OSM database.

There are some comparatively rare cases where you know in advance that
something will change (e.g. with construction that is scheduled to be
finished by a particular date), but imo that's more the domain of
opening_date or temporary tags.

> The routine is then, ask if check_date is absent OR when the current
> date is past the check_date.

I don't think this is a big benefit compared to "... OR when the current
date is X months past the check_date".

Also, I tend to prefer making software a little more complicated if it
lightens mappers' manual workload, so making at least some use of
history (e.g. so that no check_date needs to be set when a tag is first
added) seems reasonable to me.

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

Re: [Tagging] TRAVEL_DIR (and other fields) in shapefile?

[Paul Allen]

On Fri, 24 Jul 2020 at 19:22, Matthew Woehlke 
wrote:


> I have a shapefile I obtained from a county's GIS¹. In addition to road
> names (sometimes) and speed limits (yay!), there is an attribute
> TRAVEL_DIR, which seems to have the possible values (at least) 1, 2 and
> 3. Does anyone know what this field means? (I was hoping there might be
> some indication what roads are one-way, but I have not been able to
> determine a definite relation.)
>

>From some googling, it appears to be an arcgis/esri thing.  Maybe if
you have more patience than I do delving through arcgis documentation
you might find out.  Or play with one of the editors that comes up
when you search for "arcgis travel_dir" and see if you can figure it
oiut.

My guess, given the values you've seen: forwards, backwards and
sideways. :)

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

Re: [Tagging] TRAVEL_DIR (and other fields) in shapefile?

[Clifford Snow]

According to the metadata, Travel direction is a representation where
addresses increase. For intertate travel direction is a representation
where mile post markers increase.

https://www.arcgis.com/sharing/rest/content/items/6339aa3ce01e4d249bd611917f86c0e7/info/metadata/metadata.xml?format=default=html

Best,
Clifford

On Fri, Jul 24, 2020 at 11:21 AM Matthew Woehlke 
wrote:

> This might be somewhat OT, but it's OSM-related, so...
>
> I have a shapefile I obtained from a county's GIS¹. In addition to road
> names (sometimes) and speed limits (yay!), there is an attribute
> TRAVEL_DIR, which seems to have the possible values (at least) 1, 2 and
> 3. Does anyone know what this field means? (I was hoping there might be
> some indication what roads are one-way, but I have not been able to
> determine a definite relation.)
>
> For that matter, is there other useful information I might be able to
> extract? (For example, I wonder what TYPE_CODE means...)
>
> I'm sort-of hoping these might be using some US standard system and not
> something the county made up. There seem to be some indications of that
> from trying to search the internet for information, but I was unable to
> find any sort of legend.
>
> (¹ https://gisdata-pwcgov.opendata.arcgis.com/datasets/roads)
>
> --
> Matthew
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] TRAVEL_DIR (and other fields) in shapefile?

[Matthew Woehlke]

This might be somewhat OT, but it's OSM-related, so...

I have a shapefile I obtained from a county's GIS¹. In addition to road 
names (sometimes) and speed limits (yay!), there is an attribute 
TRAVEL_DIR, which seems to have the possible values (at least) 1, 2 and 
3. Does anyone know what this field means? (I was hoping there might be 
some indication what roads are one-way, but I have not been able to 
determine a definite relation.)


For that matter, is there other useful information I might be able to 
extract? (For example, I wonder what TYPE_CODE means...)


I'm sort-of hoping these might be using some US standard system and not 
something the county made up. There seem to be some indications of that 
from trying to search the internet for information, but I was unable to 
find any sort of legend.


(¹ https://gisdata-pwcgov.opendata.arcgis.com/datasets/roads)

--
Matthew

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Jez Nicholson]

There must have been a long discussion on this, and I don't want to rehash
it, but i'm surprised there was a positive response to adding check_date
for individual attributesI can understand a check_date for a whole
feature (as with the construction site), so for example a bus stop, I
might be asked to check all the attributes (is there a seat? is there a
bin? is there still a shelter?) and flag the whole bus stop as 'checked'.
Could StreetComplete quests be built for confirming all attributes of an
object, or are they limited to one (and hence your need to flag individual
attribute checked dates)?

On Fri, Jul 24, 2020 at 1:16 PM Peter Elderson  wrote:

> Firstly, I think this kind of application is very important for the
> maintenance of the map. The thing has become too complicated for regular
> people. So, kudo's!
>
> Secondly, I think having to evaluate the history is a challenge. But do
> you have to?
> In comparable cases (non-OSM, but comparible checking schemes), I do not
> record the date it has been checked, I record the future date when it
> should be checked (again).
>
> The routine is then, ask if check_date is absent OR when the current date
> is past the check_date.
>
> You can vary check_date according to the feature. You could ask the user
> to confirm the suggested future check_date or enter a better one.
>
> Easy overpass queries can find objects past the check_date. Easy maps can
> show objects past the check_date. It's all much simpler than searching
> possibly complex history.
>
> Vr gr Peter Elderson
>
>
> Op do 23 jul. 2020 om 18:08 schreef Tobias Zwick :
>
>> Hello everyone
>>
>> As you may or may not know, my microgrant proposal "Map maintenance with
>> StreetComplete" [1] was selected to be funded by the OSMF. So, I am
>> happy to have the oppurtunity to invest the time  extending the app,
>> hoping that it will help to keep the map up-to-date and unburden people
>> and communities invested in that topic.
>>
>> I am pitching this here because there are three details on which I would
>> like to hear your input. Two of these are about tagging.
>>
>> But first, how will it work?
>> 
>>
>> So, what StreetComplete will do is to scan the map for whether certain
>> properties (tags) of map features haven't been surveyed for a certain
>> time. If this is the case, users will be prompted to answer the question
>> for that property again. For example, if the app ascertained that the
>> smoothness of a road hasn't been changed for 5 years, it would ask users
>> again about the smoothness of the road.
>>
>> Challenges
>> --
>>
>> Now, you might imagine that this is not so straightforward to implement,
>> and you would be right, for several reasons:
>>
>> Firstly, the OSM API has no notion about when a particular property of
>> an element has last been changed, only for when the whole element has
>> last been changed. But elements are changed all the time for various
>> reasons. Roads for example tend to be changed especially often, splitted
>> up to accomodate bus routes, turn restrictions, when detailing
>> intersections, etc.
>>
>> Secondly, there is only the date of the last change, but that doesn't
>> mean that is the date of the last survey. Even though that would be the
>> information we are interested in: when has the element last been checked
>> on-site?
>>
>> Thirdly, the OSM API does not offer users to record solely that they
>> checked something and that it is still up to date. Any new record in OSM
>> must always come with a tagging change.
>>
>> Solutions
>> -
>>
>> In the absence of direct API support, fortunately the community came up
>> with a solution: Add the check_date tag to the element that has been
>> checked on a survey - or with the namespace if it concerns only a
>> certain tag of a map feature.
>>
>> This works well and is actually already used by Streetcomplete in the
>> "Is this construction site finished?"-quest:
>> If the element as a whole hasn't been changed for 6 months *or* the
>> check_date key is present and its value is older than 6 months, the
>> quest is eligible to be asked again. When the user answers the question,
>> the check_date is set to current date.
>>
>> Your input
>> ==
>>
>> Now here is where I would like your input:
>>
>> 1. Use check_date:smoothness or smoothness:check_date?
>> --
>> check_date with a namespace isn't used all that often yet, both variants
>> are used and thus there is no real winner yet. What variant do you
>> prefer and why? And most importantly, which variant would be most
>> consistent with existing tagging practices?
>>
>> 2. Always record check_date or avoid tagging it where not absolutely
>> necessary?
>>
>> ---
>> If something is resurveyed and it is acknowledged that nothing changed,
>> it is absolutely necessary to tag check_date. 

Re: [Tagging] Two side-of-road parking questions

[Kevin Kenny]

For what it's worth, ordinarily I will map a stretch of road with parallel
or diagonal parking by drawing a parking area that shares nodes with the
road centre-line. The routers find it when asked to find parking, it
doesn't render badly, and I think it expresses the intention.  If there is
parallel or diagonal parking on both sides of the road, it looks like a
road going through a parking field, but if it's `highway=residential` (or
`unclassified` or `tertiary` or whatever) the routers don't appear to care.

On Fri, Jul 24, 2020 at 10:54 AM Paul Allen  wrote:

> On Fri, 24 Jul 2020 at 15:26, Matthew Woehlke 
> wrote:
>
>> On 24/07/2020 10.18, Paul Allen wrote:
>> >
>> > Sounds like the same thing,  Near enough.  Especially if some streets
>> > have signs saying "no parking at any time."
>>
>> Right; I didn't mean "we don't have on-street parking", I meant we don't
>> mark it like that.
>>
>
> Tomato/tomahto. :)
>
>>
>> Relatedly: I would call that "on-street parking". To me, a "parking
>> lane" is actually more like the NYC video I linked, i.e. a space that is
>> dedicated to *parking* and not intended to be used by through traffic.
>>
>
> That's my take on it, too.
>
> This is probably a large part of the confusion, as it seems that what
>> OSM calls a "parking lane" is what I would call "on-street parking", and
>> what I call a "parking lane", OSM considers a parking lot.
>>
>
> A lot of the documentation was written by people who don't have British
> English as a first language.  You have to look at the pictures, too.
>
>>
>> >> BTW, this is what NYC apparently considers a "parking lane":
>> >> https://www.youtube.com/watch?v=RJv4oleZAhQ
>> >
>> > That's a "floating parking lane," according to the video.
>>
>> Yeah, I don't know what "floating" means there.
>>
>
> You don't?  It even explained it in the video.  Or the description.
> Somewhere.
> The parking spaces are detached from the sidewalk because there's a
> bicycle lane between the two.
>
>>
>> > Looks to me like a parking lot adjoining a road at one side and
>> > adjoining a cycle lane at the other.  I say this because of what is
>> > visible at the left of that "floating parking lane" - an obstacle.
>> > Even with no vehicles parked there, through traffic would be
>> > obstructed.  Difficult to be sure, from the video, though.  I'm glad
>> > I don't have anything like that around here, otherwise I'd have to
>> > figure out how to map it.
>>
>> It's pretty typical of what I'm dealing with in Quantico, though. We
>> seem to have come to an agreement to map this as a "lot".
>>
>
> It's how I'd handle the one in the video.  But that's just me, bringing my
> own cultural assumptions and idiosyncrasies with me.  And I'm
> very idiosyncratic.
>
>>
>> > Was there through traffic in the parking lane itself in the above video?
>>
>> I can state with some confidence that there isn't *intended* to be.
>>
>
> I don't recall seeing any.  I don't want to use up more of my
> download limit checking, so I'm relying on my increasingly-
> defective memory.
>
> Again, I think we've agreed to treat that as a "lot". (Which I believe
>> is what I was trying to say, admittedly very badly, with the above.)
>>
>
> I think it's a floating parking lot not a floating parking lane. :)
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 10.52, Paul Allen wrote:

On Fri, 24 Jul 2020 at 15:26, Matthew Woehlke wrote:

Yeah, I don't know what "floating" means there.


You don't?  It even explained it in the video.  Or the description.
Somewhere.
The parking spaces are detached from the sidewalk because there's a
bicycle lane between the two.


Ah, yes, it's in the description (which I didn't read :P).


It's pretty typical of what I'm dealing with in Quantico, though. We
seem to have come to an agreement to map this as a "lot".


It's how I'd handle the one in the video.  But that's just me, bringing my
own cultural assumptions and idiosyncrasies with me.  And I'm
very idiosyncratic.


That's okay, I've decided I can very much live with that idiosyncrasy 
:-). (Did I mention that it's much easier to map lots than use 
parking:lane? ;-) ...that's rhetorical, BTW.)


--
Matthew

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

Re: [Tagging] Tagging motorcycle parking

[Matthew Woehlke]

On 24/07/2020 10.44, Paul Allen wrote:

On Fri, 24 Jul 2020 at 15:20, Matthew Woehlke wrote:

For example, https://www.openstreetmap.org/way/828934579 and
https://www.openstreetmap.org/way/828934591, or (even better)
https://www.openstreetmap.org/way/828934580 and
https://www.openstreetmap.org/way/828934583. To wit, in both cases,
dividing the "separate lots" from each other requires drawing an
absolutely arbitrary line on the pavement.


That second pair of examples.  Ugh!

I think I'd try mapping them as a single parking lot and add parking
spaces.  Even though we don't currently have a way of tagging
motorcycle spaces, the relative sizes would give a clue.


Yeah, I'm probably going to rework it that way... and I am very 
seriously thinking about proposing capacity:motorcycle (and 
capacity:carry_out!) and parking_space={motorcycle,carry_out}.


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Paul Allen]

On Fri, 24 Jul 2020 at 15:26, Matthew Woehlke 
wrote:

> On 24/07/2020 10.18, Paul Allen wrote:
> >
> > Sounds like the same thing,  Near enough.  Especially if some streets
> > have signs saying "no parking at any time."
>
> Right; I didn't mean "we don't have on-street parking", I meant we don't
> mark it like that.
>

Tomato/tomahto. :)

>
> Relatedly: I would call that "on-street parking". To me, a "parking
> lane" is actually more like the NYC video I linked, i.e. a space that is
> dedicated to *parking* and not intended to be used by through traffic.
>

That's my take on it, too.

This is probably a large part of the confusion, as it seems that what
> OSM calls a "parking lane" is what I would call "on-street parking", and
> what I call a "parking lane", OSM considers a parking lot.
>

A lot of the documentation was written by people who don't have British
English as a first language.  You have to look at the pictures, too.

>
> >> BTW, this is what NYC apparently considers a "parking lane":
> >> https://www.youtube.com/watch?v=RJv4oleZAhQ
> >
> > That's a "floating parking lane," according to the video.
>
> Yeah, I don't know what "floating" means there.
>

You don't?  It even explained it in the video.  Or the description.
Somewhere.
The parking spaces are detached from the sidewalk because there's a
bicycle lane between the two.

>
> > Looks to me like a parking lot adjoining a road at one side and
> > adjoining a cycle lane at the other.  I say this because of what is
> > visible at the left of that "floating parking lane" - an obstacle.
> > Even with no vehicles parked there, through traffic would be
> > obstructed.  Difficult to be sure, from the video, though.  I'm glad
> > I don't have anything like that around here, otherwise I'd have to
> > figure out how to map it.
>
> It's pretty typical of what I'm dealing with in Quantico, though. We
> seem to have come to an agreement to map this as a "lot".
>

It's how I'd handle the one in the video.  But that's just me, bringing my
own cultural assumptions and idiosyncrasies with me.  And I'm
very idiosyncratic.

>
> > Was there through traffic in the parking lane itself in the above video?
>
> I can state with some confidence that there isn't *intended* to be.
>

I don't recall seeing any.  I don't want to use up more of my
download limit checking, so I'm relying on my increasingly-
defective memory.

Again, I think we've agreed to treat that as a "lot". (Which I believe
> is what I was trying to say, admittedly very badly, with the above.)
>

I think it's a floating parking lot not a floating parking lane. :)

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

Re: [Tagging] Tagging motorcycle parking

[Paul Allen]

On Fri, 24 Jul 2020 at 15:20, Matthew Woehlke 
wrote:

>
> For example, https://www.openstreetmap.org/way/828934579 and
> https://www.openstreetmap.org/way/828934591, or (even better)
> https://www.openstreetmap.org/way/828934580 and
> https://www.openstreetmap.org/way/828934583. To wit, in both cases,
> dividing the "separate lots" from each other requires drawing an
> absolutely arbitrary line on the pavement.
>

That second pair of examples.  Ugh!

I think I'd try mapping them as a single parking lot and add parking
spaces.  Even though we don't currently have a way of tagging
motorcycle spaces, the relative sizes would give a clue.

Alternatively, two separate parking lots combined as a multipolygon.
In this case I'd alter the outline of the motorcycle lot so that it shared
a common way segment with the main lot rather than having that
peculiar shape.  I'd put that arbitrary line sort of equidistant from
motorcycle spaces and car spaces, adjusted may so it delineates
where cars can't (or wouldn't) go.

Tricky.

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

Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Christoph Hormann]

On Friday 24 July 2020, Paul Allen wrote:
>
> I take it that means you're not in favour of my idea of rendering all
> parts of the world not covered by a tagged area with the label "Here
> there be dragons."  I think that would be cool, especially if
> somebody comes up with a good dragon icon.

You can pick one of the following two answers:

1) We already render them in a distinct color:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/style/style.mss

Rendering features with a distinct symbol or pattern in addition if that 
symbol does not transport any additional information is something we 
typically try to avoid.

2) There are no parts of the Earth that are not covered by a mapped area 
since the global coastline divides the Earth surface into land (on the 
left of the coastline) and ocean (on the right of the coastline).

;-)

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 10.18, Paul Allen wrote:

On Fri, 24 Jul 2020 at 15:00, Matthew Woehlke wrote:

On 24/07/2020 08.19, Paul Allen wrote:

The image in the wiki for parking lanes matches
what I expect of it.  As in this situation near me:
https://goo.gl/maps/WUZKmhQTDSRsgnDx7 on the right
of the road are double yellow lines, which mean "no parking
or waiting at any time" (but there are exceptions) and on
the left is a single yellow line which means "parking and
waiting permitted some of the time" (though there are
exceptions and provisions and it gets complicated).  The
left is a parking lane, as I understand it.  There are no
parking spaces marked.


AFAIK there is nothing exactly like that in the US. People do park on
streets (note 5th, 4th and 3rd Avenues, as previously mentioned), and
there is sometimes signage regulating this.


Sounds like the same thing,  Near enough.  Especially if some streets
have signs saying "no parking at any time."


Right; I didn't mean "we don't have on-street parking", I meant we don't 
mark it like that.


Relatedly: I would call that "on-street parking". To me, a "parking 
lane" is actually more like the NYC video I linked, i.e. a space that is 
dedicated to *parking* and not intended to be used by through traffic. 
This is probably a large part of the confusion, as it seems that what 
OSM calls a "parking lane" is what I would call "on-street parking", and 
what I call a "parking lane", OSM considers a parking lot.



BTW, this is what NYC apparently considers a "parking lane":
https://www.youtube.com/watch?v=RJv4oleZAhQ


That's a "floating parking lane," according to the video.


Yeah, I don't know what "floating" means there.


Looks to me like a parking lot adjoining a road at one side and
adjoining a cycle lane at the other.  I say this because of what is
visible at the left of that "floating parking lane" - an obstacle.
Even with no vehicles parked there, through traffic would be
obstructed.  Difficult to be sure, from the video, though.  I'm glad
I don't have anything like that around here, otherwise I'd have to
figure out how to map it.


It's pretty typical of what I'm dealing with in Quantico, though. We 
seem to have come to an agreement to map this as a "lot".



That said, I think the US definition may be "a lane which is for
parking, rather than through traffic, and which may be intermittently
present" (e.g. the above video). However, I am much *less* convinced
that it is useful to model them that way, at least in the current state
of things.


Was there through traffic in the parking lane itself in the above video?


I can state with some confidence that there isn't *intended* to be. 
Again, I think we've agreed to treat that as a "lot". (Which I believe 
is what I was trying to say, admittedly very badly, with the above.)


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Paul Allen]

On Fri, 24 Jul 2020 at 15:00, Matthew Woehlke 
wrote:

> On 24/07/2020 08.19, Paul Allen wrote:
>
> > The image in the wiki for parking lanes matches
> > what I expect of it.  As in this situation near me:
> > https://goo.gl/maps/WUZKmhQTDSRsgnDx7 on the right
> > of the road are double yellow lines, which mean "no parking
> > or waiting at any time" (but there are exceptions) and on
> > the left is a single yellow line which means "parking and
> > waiting permitted some of the time" (though there are
> > exceptions and provisions and it gets complicated).  The
> > left is a parking lane, as I understand it.  There are no
> > parking spaces marked.
>
> AFAIK there is nothing exactly like that in the US. People do park on
> streets (note 5th, 4th and 3rd Avenues, as previously mentioned), and
> there is sometimes signage regulating this.
>

Sounds like the same thing,  Near enough.  Especially if some streets
have signs saying "no parking at any time."

>
> Actually, this might answer one of my prior questions; is =marked
> supposed to be used for stretches that alternate between parking allowed
> and parking forbidden?
>

The wiki is a little unclear, but I take it to mean whether or not there are
road markings for each parking space.  But if there are markings, I'd
say it was a parking lot. Depends on context, though.  If it's a little
paint
on the kerb, parking lane.  If it's a road marking, parking lot.  That's
my rule of thumb, not a solid rule I'd apply in all cases.

>
> BTW, this is what NYC apparently considers a "parking lane":
> https://www.youtube.com/watch?v=RJv4oleZAhQ
>

That's a "floating parking lane," according to the video.  Looks to me like
a parking lot adjoining a road at one side and adjoining a cycle lane at
the other.  I say this because of what is visible at the left of that
"floating parking lane" - an obstacle.  Even with no vehicles parked
there, through traffic would be obstructed.  Difficult to be sure, from the
video, though.  I'm glad I don't have anything like that around here,
otherwise I'd have to figure out how to map it.

>
> Based on this discussion, it seems to me that that is *not* a "parking
> lane" as OSM uses it.
>

That's not a parking lane how I'd use it.  I don't speak for OSM.  Other
mappers may (and almost certainly will) interpret it differently.

>
> That said, I think the US definition may be "a lane which is for
> parking, rather than through traffic, and which may be intermittently
> present" (e.g. the above video). However, I am much *less* convinced
> that it is useful to model them that way, at least in the current state
> of things.
>

Was there through traffic in the parking lane itself in the above video?

>
> > Yeah, but the spaces don't render.  Oh wow!  I just checked one of your
> > later examples and parking spaces now render.  I'd given up on hoping
> that
> > they would render.  Doesn't fix the example I'm thinking of, though -
> it's
> > clearly a pregnant bulge that is for parking, but no spaces are marked.
>
> Ah, yes, that would be an issue. Not sure what was with the not
> rendering, unless you happened to look at it soon enough after I
> uploaded the changes. There does seem to be a variable delay between the
> database changing and the rendered tiles being regenerated.
>

I'm used to delays.  Last weekend the delay was several hours.  I'm talking
about parking spaces not rendering ever, as far as I could tell.  Looks like
carto implemented it when I wasn't looking.

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

Re: [Tagging] Tagging motorcycle parking

[Matthew Woehlke]

On 24/07/2020 02.19, Martin Koppenhoefer wrote:

On 23. Jul 2020, at 21:31, Matthew Woehlke  wrote:
...and what if we're mapping spaces? I'm not sure I'm on board with
dividing things which are logically "one parking lot"


if there is no name, what makes a parking space logically one lot?


Consisting of one contiguous surface? Clearly associated with the same 
building?


For example, https://www.openstreetmap.org/way/828934579 and 
https://www.openstreetmap.org/way/828934591, or (even better) 
https://www.openstreetmap.org/way/828934580 and 
https://www.openstreetmap.org/way/828934583. To wit, in both cases, 
dividing the "separate lots" from each other requires drawing an 
absolutely arbitrary line on the pavement.


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 04.29, Mateusz Konieczny via Tagging wrote:

Jul 23, 2020, 20:42 by mwoehlke.fl...@gmail.com:

I'm trying to tag a whole bunch of side-of-road parking, and I have two 
questions.

First, what is the correct way to tag marked parking spaces? There
is parking:lane:*=marked which would seem to apply, but then it
isn't clear how to indicate the direction (parallel vs. diagonal
vs. perpendicular)?


Depending on their direction? Can you link photos of case that is unclear for 
you?


Diagonal vs. perpendicular vs. parallel is clear. What I mean is it s 
unclear how to tag e.g. marked, diagonal parking.


...or am I overthinking this? =marked;diagonal?


  It's also not entirely clear when I am or am not supposed to use 'marked'...


"There are only some parking spaces available that are individually marked."
so it seems to be used for example in case where there is a single parking 
space,
20m of no parking then other parking space (possibly in other direction),
tree, parking space, 10m of no parking, 3 parking spaces and so on.


This makes me wonder if 'marked' shouldn't even be a type, and maybe 
there should be an 'intermittent' tag instead.



Second, at what point does "on street parking" become a parking lot?

There are examples of the first *all* over Quantico (at least the "downtown" 
part). For examples of the second, consider:

  https://www.openstreetmap.org/way/829371448
  https://www.openstreetmap.org/way/829371451
  https://www.openstreetmap.org/way/826561586

I am particularly struggling to decide what to do at places such as:

  38.52057/-77.29185
  38.52181/-77.29611
  38.52125/-77.29711


Can you link some photos?


Use your favorite satellite imagery. For example, use 
https://www.openstreetmap.org/edit#map=22/38.52057/-77.29185 and pull 
something up (the MapBox for this area is very high resolution).


--
Matthew

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

Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Paul Allen]

On Fri, 24 Jul 2020 at 14:50, Christoph Hormann  wrote:

> In OSM we generally think that using an open tagging system where the
> tags are narrowly defined in what the positively mean in a locally
> verifiable fashion is better for representing the global geography in
> all its diversity and to document local knowledge of people than a
> closed classification system that assigns the class with the lowest
> mismatch in a classification developed from a specific culturally
> narrow perspective to every point of the earth surface.
>

I take it that means you're not in favour of my idea of rendering all
parts of the world not covered by a tagged area with the label "Here
there be dragons."  I think that would be cool, especially if somebody
comes up with a good dragon icon.

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

Re: [Tagging] Two side-of-road parking questions

[Matthew Woehlke]

On 24/07/2020 08.19, Paul Allen wrote:

On Fri, 24 Jul 2020 at 00:06, Matthew Woehlke wrote:

Currently, I have the non-parallel spots marked as a lot. To my mind,
parallel parking and on-street parking are nearly synonymous.


I'm not entirely clear what you mean by those terms as you're
American.


That's okay; that makes two of us ;-).


The image in the wiki for parking lanes matches
what I expect of it.  As in this situation near me:
https://goo.gl/maps/WUZKmhQTDSRsgnDx7 on the right
of the road are double yellow lines, which mean "no parking
or waiting at any time" (but there are exceptions) and on
the left is a single yellow line which means "parking and
waiting permitted some of the time" (though there are
exceptions and provisions and it gets complicated).  The
left is a parking lane, as I understand it.  There are no
parking spaces marked.


AFAIK there is nothing exactly like that in the US. People do park on 
streets (note 5th, 4th and 3rd Avenues, as previously mentioned), and 
there is sometimes signage regulating this.


Actually, this might answer one of my prior questions; is =marked 
supposed to be used for stretches that alternate between parking allowed 
and parking forbidden?


BTW, this is what NYC apparently considers a "parking lane":
https://www.youtube.com/watch?v=RJv4oleZAhQ

Based on this discussion, it seems to me that that is *not* a "parking 
lane" as OSM uses it.


That said, I think the US definition may be "a lane which is for 
parking, rather than through traffic, and which may be intermittently 
present" (e.g. the above video). However, I am much *less* convinced 
that it is useful to model them that way, at least in the current state 
of things.



Well, there's an easy solution to that; map the spaces, also ;-)


Yeah, but the spaces don't render.  Oh wow!  I just checked one of your
later examples and parking spaces now render.  I'd given up on hoping that
they would render.  Doesn't fix the example I'm thinking of, though - it's
clearly a pregnant bulge that is for parking, but no spaces are marked.


Ah, yes, that would be an issue. Not sure what was with the not 
rendering, unless you happened to look at it soon enough after I 
uploaded the changes. There does seem to be a variable delay between the 
database changing and the rendered tiles being regenerated.



it's normal for a parking lot area to include at least parts of the
aisles.


In one sense it's correct.  At a level of highway modelling we don't do and
may never do.  In terms of what gets rendered (where the renderer draws
roads on a layer above parking lots), it's perfectly comprehensible.  Since
we don't have a better way of representing what's there, I ignored the
objection.


Agreed; if the road was mapped also as an area, it would make sense.


...and to be honest, another argument for modeling as lots is that the
parking_lane tagging is rather more obtuse...


There is that.  Which is why I tend not to bother with it.  Especially as it
means surveying and finding out the restrictions on times.


Meh, I'm happy to omit the restrictions :-).

--
Matthew

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

Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Christoph Hormann]

On Friday 24 July 2020, Michael Montani wrote:
>
> The voting for natural=bare_soil has begun and can be found
> hereing>. It will temptatively close August 7th, given enough support.

It is unfortunate that the suggestion to not aim for introducing an 
umbrella tag was not taken into account.

The proposal as is lacks clarity of what it actually suggests and how 
this new tag delienates against existing tags.  It also lacks 
comprehensive practical guidance for the mapper how to identify and 
delineate features with this tag based on real world on-the-ground 
examples.

What you essentially attempt to introduce here is a *residual* tag to 
turn the open OSM tagging system consisting of tags that positively 
identify specific real world features into a closed land cover 
classification system modeled after countless such systems (some of 
which you cited).  

In OSM we generally think that using an open tagging system where the 
tags are narrowly defined in what the positively mean in a locally 
verifiable fashion is better for representing the global geography in 
all its diversity and to document local knowledge of people than a 
closed classification system that assigns the class with the lowest 
mismatch in a classification developed from a specific culturally 
narrow perspective to every point of the earth surface.

Side note:  Measuring percentage of ground cover in an arid/semiarid 
context is usually not practically verifiable on the ground, in 
particular in areas with strong seasonality.  Examples:

https://commons.wikimedia.org/wiki/File:Somewhere_in_Kazakhstan_(20160402_072251_1PS)_(28754128301).jpg
https://commons.wikimedia.org/wiki/File:Lake_turkana.jpg
https://commons.wikimedia.org/wiki/File:Landschaft_AnysbergPICT1454.JPG

We definitely do not want such areas to be engrossed in some 
generic 'unvegetated or sparsely vegetated area' classification.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Two side-of-road parking questions

[Paul Allen]

On Fri, 24 Jul 2020 at 00:06, Matthew Woehlke 
wrote:

> On 23/07/2020 17.26, Paul Allen wrote:
>
> > From the geometry, I'd say that was a parking lot.
>
> Currently, I have the non-parallel spots marked as a lot. To my mind,
> parallel parking and on-street parking are nearly synonymous.


I'm not entirely clear what you mean by those terms as you're
American.  The image in the wiki for parking lanes matches
what I expect of it.  As in this situation near me:
https://goo.gl/maps/WUZKmhQTDSRsgnDx7 on the right
of the road are double yellow lines, which mean "no parking
or waiting at any time" (but there are exceptions) and on
the left is a single yellow line which means "parking and
waiting permitted some of the time" (though there are
exceptions and provisions and it gets complicated).  The
left is a parking lane, as I understand it.  There are no
parking spaces marked.


> > From the fact that parking spaces are marked, it's not a parking
> > lane, in my opinion.
>
> Well it's certainly not a parking *lane*; you clearly are not meant to
> possibly drive through it. I was thinking that the fact the parking
> spaces are arranged so as to not occlude traffic was what was inclining
> me to model it as a "lot".
>

I take the marked parking spaces as a very strong hint that it's a lot.
It still depends on surrounding circumstances and context, but if they're
marked as parking spaces the purpose of those areas of hard paving is
for parking.  That makes them a parking lot rather than roadside parking.
Others differ on this.

>
> Really, it's the notion of a parking lot for which the aisle is also a
> main road that's throwing me...
>

The main road is a WIDE parking aisle. :)  Alternatively, it's a parking lot
with a very wide entrance.  Yeah, it's a bit weird, but how else do you
represent the parking area in a way that indicates there isn't a narrow
entrance from which you then fan out into parking spaces but that
each parking space may be entered directly from the main road?

As far as I can determine, the closest way we have of representing
the situation is a parking lot that abuts the highway.  It renders in a
way that is reasonably interpreted.  The alternatives are

1) A detached parking lot with no indication of how the car "jumps"
from the highway into it.  One of those appeared on this list a few
days ago.  Helicopter parking?

2) A detached parking lot with an access service road (that doesn't
exist) linking it to the highway so it is connected?  That's not
really how it is.

3) A parking lot that joins the highway.  Seems to work.

>
> Yeah, that line of thinking is similar in effect to asking if it
> occludes normal traffic flow. Different questions, but likely to have
> the same answer.
>

Same question, different phrasing.

>
> > This is how I handled a similar one:
> >
> https://www.openstreetmap.org/?mlat=52.08562=-4.65829#map=19/52.08562/-4.65829
> >
> > Somebody objected that whilst that looked right when rendered, when
> > you examined it in the editor it misleadingly implied that you could
> > park with one end of your car blocking half of the street.
>


> Well, there's an easy solution to that; map the spaces, also ;-)


Yeah, but the spaces don't render.  Oh wow!  I just checked one of your
later examples and parking spaces now render.  I'd given up on hoping that
they would render.  Doesn't fix the example I'm thinking of, though - it's
clearly a pregnant bulge that is for parking, but no spaces are marked.


> . That said, I find that attitude slightly asinine; it's normal for a
> parking
> lot area to include at least parts of the aisles.
>

In one sense it's correct.  At a level of highway modelling we don't do and
may never do.  In terms of what gets rendered (where the renderer draws
roads on a layer above parking lots), it's perfectly comprehensible.  Since
we don't have a better way of representing what's there, I ignored the
objection.

>
> > I did one car park which attempted to deal with that complaint:
> >
> https://www.openstreetmap.org/?mlat=52.10572=-4.37367#map=19/52.10572/-4.37367
> > but it looks so ugly that I doubt I'll do that again.
>
> Agreed (on the 'looking ugly').


:)

>
> Anyway, your example would be much more sane if the entire road had a
> mapped area, rather than just the little piece by the parking lot.
>

Yeah, but that ugly bit is also a lowered sidewalk.  That car park has a
very,
very wide entrance (the width of the car park itself).  What I did was a
compromise, and it's ugly.  But without mapping (and rendering) sidewalks,
and mapping (and rendering) the true widths of roads, there's no good
way of handling it, just a variety of bad ways.

>
> ...and to be honest, another argument for modeling as lots is that the
> parking_lane tagging is rather more obtuse...
>

There is that.  Which is why I tend not to bother with it.  Especially as it
means surveying and finding out the restrictions on times.  And
re-surveying fairly frequently in case the 

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

[Peter Elderson]

Firstly, I think this kind of application is very important for the
maintenance of the map. The thing has become too complicated for regular
people. So, kudo's!

Secondly, I think having to evaluate the history is a challenge. But do you
have to?
In comparable cases (non-OSM, but comparible checking schemes), I do not
record the date it has been checked, I record the future date when it
should be checked (again).

The routine is then, ask if check_date is absent OR when the current date
is past the check_date.

You can vary check_date according to the feature. You could ask the user to
confirm the suggested future check_date or enter a better one.

Easy overpass queries can find objects past the check_date. Easy maps can
show objects past the check_date. It's all much simpler than searching
possibly complex history.

Vr gr Peter Elderson


Op do 23 jul. 2020 om 18:08 schreef Tobias Zwick :

> Hello everyone
>
> As you may or may not know, my microgrant proposal "Map maintenance with
> StreetComplete" [1] was selected to be funded by the OSMF. So, I am
> happy to have the oppurtunity to invest the time  extending the app,
> hoping that it will help to keep the map up-to-date and unburden people
> and communities invested in that topic.
>
> I am pitching this here because there are three details on which I would
> like to hear your input. Two of these are about tagging.
>
> But first, how will it work?
> 
>
> So, what StreetComplete will do is to scan the map for whether certain
> properties (tags) of map features haven't been surveyed for a certain
> time. If this is the case, users will be prompted to answer the question
> for that property again. For example, if the app ascertained that the
> smoothness of a road hasn't been changed for 5 years, it would ask users
> again about the smoothness of the road.
>
> Challenges
> --
>
> Now, you might imagine that this is not so straightforward to implement,
> and you would be right, for several reasons:
>
> Firstly, the OSM API has no notion about when a particular property of
> an element has last been changed, only for when the whole element has
> last been changed. But elements are changed all the time for various
> reasons. Roads for example tend to be changed especially often, splitted
> up to accomodate bus routes, turn restrictions, when detailing
> intersections, etc.
>
> Secondly, there is only the date of the last change, but that doesn't
> mean that is the date of the last survey. Even though that would be the
> information we are interested in: when has the element last been checked
> on-site?
>
> Thirdly, the OSM API does not offer users to record solely that they
> checked something and that it is still up to date. Any new record in OSM
> must always come with a tagging change.
>
> Solutions
> -
>
> In the absence of direct API support, fortunately the community came up
> with a solution: Add the check_date tag to the element that has been
> checked on a survey - or with the namespace if it concerns only a
> certain tag of a map feature.
>
> This works well and is actually already used by Streetcomplete in the
> "Is this construction site finished?"-quest:
> If the element as a whole hasn't been changed for 6 months *or* the
> check_date key is present and its value is older than 6 months, the
> quest is eligible to be asked again. When the user answers the question,
> the check_date is set to current date.
>
> Your input
> ==
>
> Now here is where I would like your input:
>
> 1. Use check_date:smoothness or smoothness:check_date?
> --
> check_date with a namespace isn't used all that often yet, both variants
> are used and thus there is no real winner yet. What variant do you
> prefer and why? And most importantly, which variant would be most
> consistent with existing tagging practices?
>
> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?
>
> ---
> If something is resurveyed and it is acknowledged that nothing changed,
> it is absolutely necessary to tag check_date. If something changed, it
> is not strictly necessary because that the element changed as a whole is
> itself also recorded.
> But as already mentioned, elements can and do change all the time. One
> can not assume that if an element has been changed that it has been
> checked on-site. And even if one could, maybe not all the things were
> checked but for example only the bus route relation, or maybe only the
> presence of a sidewalk, or someone made the way a little more detailed etc.
>
> The topic whether StreetComplete should only tag the minimum of what is
> necessary to ensure functionality or always tag check_date (at least for
> properties that are eligible for re-survey) was already subject to
> discussion in the issue tracker here:
> 

Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Mateusz Konieczny via Tagging]

https://wiki.openstreetmap.org/wiki/Proposed_features/Ground#Tagging
is listing multiple methods to map this, what is not a good idea. 
I am confused a bit as mailing list message mentioned single value. 
Maybe it is list of considered but rejected alternatives?


Jul 24, 2020, 09:52 by michael.mont...@un.org:

> After the fruitful discussions we had in > [Tagging] Are we mapping ground on 
> OSM? 
> >  
> and > [Tagging] Feature Proposal - RFC - (Ground) 
> >  , 
> I updated the >  wiki page for the proposal of natural=bare_soil 
> > .
>  
>  The voting for > natural=bare_soil>  has begun and can be found > here 
> > . It 
> will temptatively close > August 7th> , given enough support.
>  
>  Thanks,
>  
>
>
>
>
>
> --
>  > Michael Montani
>  > GIS Consultant> ,>  > Client Solutions Delivery Section
>  > Service for Geospatial Information and Telecommunications Technologies
>  > United Nations Global Service Centre
>  > United Nations Department of Operational Support
>  
>  > Brindisi>  > |>  > Phone: +39 0831 056985>  > |>  > Mobile: +39 
> 3297193455>  > |>  > Intermission: 158 6985>  
> E-mail:>  > michael.monta> ni@u> n.org >  > |>  > 
> www.ungsc.org 
>

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

Re: [Tagging] Waterway equivalent of noexit=yes?

[Alan Mackie]

This is specifically about how to label the end point where the waterway
doesn't drain into another waterbody, not how to label an intermittent
stream in general.

On Fri, 24 Jul 2020, 07:05 Graeme Fitzpatrick, 
wrote:

>
>
>
> On Thu, 23 Jul 2020 at 01:27, Tod Fitch  wrote:
>
>>
>> We are still left with the situation where an ephemeral waterway fans out
>> over the desert and disappears. We need some sort of tagging to indicate
>> this is not a mistake and I’ve not seen a tag or value come up in this
>> discussion that has any existing use or consensus in the list.
>>
>
> It would appear that =stream + intermittent=yes is the best option?
>
> https://wiki.openstreetmap.org/wiki/Key:intermittent
>
> Wadi https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwadi was
> previously used but deprecated in favour of intermittent
>
> Drystream could be an option?
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddrystream, but now
> also discouraged.
>
> Ephemeral was also proposed but apparently hasn't gone any further?
> https://wiki.openstreetmap.org/wiki/Proposed_features/ephemeral
>
> Don't know how any of them would go with OSMOSE though?
>
> 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] Map maintenance with StreetComplete - Preferred tagging

[Mateusz Konieczny via Tagging]

Jul 23, 2020, 18:06 by o...@westnordost.de:

> 1. Use check_date:smoothness or smoothness:check_date?
>
Both have some benefits, I am perfectly fine with both variants.

One gets check_date tags out of the way, one keeps tag and its
check date close to each other. In case of tie second seems
slightly preferable.

EDIT: surface:check_date would reduce risk of it getting out of sync,
it seems preferable to me, but check_date:surface also seems fine

> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?
>
Slight preference toward "avoid".
It is useful/necessary in some cases, but if it possible to avoid it then
it should be avoided.

In the same way as note/description is not used to record
note="this is perfectly normal segment of motorway, nothing special here"

> Maybe it is obvious that my opinion is that StreetComplete should always
> tag check_date as it also adds valuable information for other surveyors
> that do not use StreetComplete. Nevertheless, in the GitHub ticket
> linked above, I played a bit of a devils advocate for the other point of
> view - for being frugal with such meta-tags.
>
I see no big benefit, and it could double list of tags on objects.
In general, I imagine ideal StreetComplete behavior as mimicking 
what human would do, without requiring human to be aware of tags,
tagging schemes and how OSM data us structured.

Note that in case of changed tags other mappers can look at object history
and see when tag was changed (note, I use JOSM with great history window
- though in iD such extra tags would be hidden anyay).

Note that unlike changeset history such tags may get out of sync, for
example as result of iD mapper editing and not being aware of them.
So relying on object history seems preferable whenever possible.

> So, I'd like to collect what are the advantages and drawabacks of adding
> check_date to all the tags surveyed on-site, with your help.
>
advantages:
(1) survives way splits

disadvantages: 
(1) iD mappers will edits tags without updating check date,
JOSM/Vespuci mappers may decide to not update them
(2) more cruft in tag list
(3) StreetComplete behaves unusually, and produces unusual tagging

Adding *:check_date because something was resurveyed makes
sense and such resurvey is a great idea, but even that is unusual.

I think that *:check_date for every single added tag is an overkill.

> Long story short, not all quests [2] would be eligible for re-survey and
> those who are will have different intervals, partly also based on how
> they are tagged now. I could use your input on how long these intervals
> should be. The issue was already discussed in a GitHub ticket [3], but
> now prepared a wiki page here in which further discussion could take place:
>
> https://wiki.openstreetmap.org/wiki/User:Westnordost/Proposed_Resurvey_Intervals
>
I would convert it to sections, table is a bit confusing to edit.

And maybe move to talk page to make clear that random comments are welcomed.

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

Re: [Tagging] Two side-of-road parking questions

[Mateusz Konieczny via Tagging]

Jul 23, 2020, 20:42 by mwoehlke.fl...@gmail.com:

> I'm trying to tag a whole bunch of side-of-road parking, and I have two 
> questions.
>
> First, what is the correct way to tag marked parking spaces? There is 
> parking:lane:*=marked which would seem to apply, but then it isn't clear how 
> to indicate the direction (parallel vs. diagonal vs. perpendicular)?
>
Depending on their direction? Can you link photos of case that is unclear for 
you?

https://wiki.openstreetmap.org/wiki/Key:parking:lane#Parking_spaces 
seems clear to me

>
>  It's also not entirely clear when I am or am not supposed to use 'marked'...
>
"There are only some parking spaces available that are individually marked."
so it seems to be used for example in case where there is a single parking 
space,
20m of no parking then other parking space (possibly in other direction),
tree, parking space, 10m of no parking, 3 parking spaces and so on.

Splitting this on every change would be ridiculous, therefore "marked"
can be used.


> Second, at what point does "on street parking" become a parking lot?
>
> There are examples of the first *all* over Quantico (at least the "downtown" 
> part). For examples of the second, consider:
>
>  https://www.openstreetmap.org/way/829371448
>  https://www.openstreetmap.org/way/829371451
>  https://www.openstreetmap.org/way/826561586
>
> I am particularly struggling to decide what to do at places such as:
>
>  38.52057/-77.29185
>  38.52181/-77.29611
>  38.52125/-77.29711
>
Can you link some photos?

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

Re: [Tagging] Two side-of-road parking questions

[Mateusz Konieczny via Tagging]

Jul 23, 2020, 23:26 by pla16...@gmail.com:

> On Thu, 23 Jul 2020 at 21:00, Matthew Woehlke <> mwoehlke.fl...@gmail.com> > 
> wrote:
>
>>
>> Interesting. By that criteria, I would think that
>>  >> https://www.openstreetmap.org/way/826561593>>  has on-street parking,
>>
>
> Tough call.  In isolation it looks like a parking lane, but it has markings
> for car parking.  On-street parking (at least where I am) doesn't usually
> have that.
>
Note that locally it may be useful, but in Poland many roadside parkings
are signed with "parking" traffic signs.

> From the fact that parking spaces are marked, it's not a parking
> lane, in my opinion.
>
Maybe it is a good hint in this specific case but I would not generalize
it too much.

> That's a parking lot rather than on-street parking.  At least, that's how
> I'd map it.
>
What about roadside parking that is marked on sidewalk and/or 
interrupted by trees/other obstacles?

It is completely unusable for driving, even if empty, but
it seems clearly roadside parking

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Mateusz Konieczny via Tagging]

Jul 23, 2020, 23:30 by miketh...@gmail.com:

>
>
> On Thu, Jul 23, 2020 at 2:34 PM Matthew Woehlke <> mwoehlke.fl...@gmail.com> 
> > wrote:
> >
>
> >
> > ...but then your horse is a passenger in a vehicle. Otherwise that would
> > be like saying a human can't ride in a vehicle if foot=no.
> Exactly, foot=no doesn't mean that feet are not allowed, it means that using 
> a mode of transportation that primarily uses feet  ("foot 
> travel"/walking/running/hiking) isn't allowed.
> bicycle=no is consistent with this, it doesn't mean that bicycles are 
> prohibited, it means that a mode of transportation, (bicycle riding) is 
> prohibited.
> horse=no is apparently a  little different as you point out.  It seems to 
> refer not just to a mode of transportation, but to the possession of the 
> animal in general.
>
Not exactly, typical motorway is horse=no but you can still transport horses in 
a truck.

>   It is similar to dog=no. dog=no doesn't refer to whether you can use a dog 
> as a mode of transportation, it means you can't possess a dog at all on the 
> given way (even if you carry it).
>
>
> >
> > For similar reasons, I would assume that a way that allows vehicles but
> > not pushed bicycles allows a bicycle *in* a vehicle.
> Right, because it is no longer the mode of transportation.
>
> > FWIW, I'm sympathetic to the "no means no" camp and just declaring that
> > if you really meant "dismount", *fix it*.
> well, "no does mean no", it means "no bicycle riding", it means, no using a 
> bicycle as a mode of transportation. It doesn't say anything about possessing 
> a bicycle in general, or using it in another manner (pushing, carrying)
> "dismount" is not the complete solution, because, as the original question 
> implied, sometimes it is also illegal to carry a bicycle (although I have 
> never seen that), and as someone else pointed out, sometimes it is illegal to 
> even possess a bicycle at all, such as in a US Wilderness Area.
>
> Mike
>

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

[Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Michael Montani]

After the fruitful discussions we had in [Tagging] Are we mapping ground on 
OSM? 
and [Tagging] Feature Proposal - RFC - 
(Ground)
 , I updated the wiki page for the proposal of 
natural=bare_soil.

The voting for natural=bare_soil has begun and can be found 
here. It 
will temptatively close August 7th, given enough support.

Thanks,

--
Michael Montani
GIS Consultant, Client Solutions Delivery Section
Service for Geospatial Information and Telecommunications Technologies
United Nations Global Service Centre
United Nations Department of Operational Support

Brindisi | Phone: +39 0831 056985 | Mobile: +39 3297193455 | Intermission: 158 
6985
E-mail: michael.mont...@un.org | 
www.ungsc.org
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging motorcycle parking

[Martin Koppenhoefer]

sent from a phone

> On 23. Jul 2020, at 21:31, Matthew Woehlke  wrote:
> 
> ...and what if we're mapping spaces? I'm not sure I'm on board with dividing 
> things which are logically "one parking lot"


if there is no name, what makes a parking space logically one lot? 

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

Re: [Tagging] Waterway equivalent of noexit=yes?

[Graeme Fitzpatrick]

On Thu, 23 Jul 2020 at 01:27, Tod Fitch  wrote:

>
> We are still left with the situation where an ephemeral waterway fans out
> over the desert and disappears. We need some sort of tagging to indicate
> this is not a mistake and I’ve not seen a tag or value come up in this
> discussion that has any existing use or consensus in the list.
>

It would appear that =stream + intermittent=yes is the best option?

https://wiki.openstreetmap.org/wiki/Key:intermittent

Wadi https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwadi was previously
used but deprecated in favour of intermittent

Drystream could be an option?
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddrystream, but now also
discouraged.

Ephemeral was also proposed but apparently hasn't gone any further?
https://wiki.openstreetmap.org/wiki/Proposed_features/ephemeral

Don't know how any of them would go with OSMOSE though?

Thanks

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