Re: [Tagging] Feature Proposal - RFC - UPRN & USRN

[Jarek Piórkowski]

On Sun, 26 Jul 2020 at 15:58, Rob Nickerson  wrote:
> Mappers in the United Kingdom are looking to agree two tags for mapping 
> 'Unique Property Reference Numbers' and 'Unique Street Reference Numbers'. To 
> support this effort I volunteered to create the relevant proposal pages on 
> the wiki.
>
> To view and comment on these please see:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn
> https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn
>
> These pages have already been posted to talk-gb and talk-ie (for Northern 
> Ireland) a few days ago. As long as there are no major blockers here, we will 
> move to the voting stage shortly.

Are these reference numbers verifiable in the field? If not, is there
anything to distinguish this initiative from an import?

--Jarek

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

Re: [Tagging] Feature Proposal - RFC - UPRN & USRN

[Warin]

On 27/7/20 5:58 am, Rob Nickerson wrote:

Hi all,

Mappers in the United Kingdom are looking to agree two tags for 
mapping 'Unique Property Reference Numbers' and 'Unique Street 
Reference Numbers'. To support this effort I volunteered to create the 
relevant proposal pages on the wiki.


To view and comment on these please see:

https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn
https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn

These pages have already been posted to talk-gb and talk-ie (for 
Northern Ireland) a few days ago. As long as there are no major 
blockers here, we will move to the voting stage shortly.




1) minimum time for comments is 2 weeks... don't be in  hurry.


See  https://wiki.openstreetmap.org/wiki/Key:ref In particular the wide 
use of *ref:** as a namespace 
 prefix.


The namespace prefix is crowed with country specific uses so I would see 
any objection here to this new use should also address the proliferation 
of country specfic existing uses too.



Record hottest temperature for attic place.
_
_
/According to scientific study, global warming in the Arctic is 
happening twice as fast as for the rest of the planet./

/
/
/For the second day in a row, the archipelago registered 21.2 degrees 
Celsius in the afternoon, just under the 21.3 degrees recorded in 1979, 
meteorologist Kristen Gislefoss told AFP./

/
/
//
/Later in the afternoon, however, at around 6pm local time, it recorded 
21.7 degrees, setting a new all-time record./

/
/
/The island group, dominated by Spitzbergen the only inhabited isle in 
the northern Norway archipelago, sits 1,000 kilometres from the North Pole./


https://timesofmalta.com/articles/view/highest-ever-temperature-recorded-in-norwegian-arctic-archipelago.807546
Record hottest temperature for attic place.
_
_
/According to scientific study, global warming in the Arctic is 
happening twice as fast as for the rest of the planet./

/
/
/For the second day in a row, the archipelago registered 21.2 degrees 
Celsius in the afternoon, just under the 21.3 degrees recorded in 1979, 
meteorologist Kristen Gislefoss told AFP./

/
/
//
/Later in the afternoon, however, at around 6pm local time, it recorded 
21.7 degrees, setting a new all-time record./

/
/
/The island group, dominated by Spitzbergen the only inhabited isle in 
the northern Norway archipelago, sits 1,000 kilometres from the North Pole./


https://timesofmalta.com/articles/view/highest-ever-temperature-recorded-in-norwegian-arctic-archipelago.807546


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

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

[ael]

On Sun, Jul 26, 2020 at 10:03:17PM +0100, Cj Malone wrote:
> On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote:
> > 
> > So in a nutshell, the topic of how to find things based on old
> > sources is also very relevant for remote mappers.
> 
> Technically there is survey:date and source:date that may be on the
> object, or (preferred now?) the changeset. So a quality assurance tool

Adding such source tags to a changeset seldom makes sense.
Most of my changesets are a mixture of local knowledge, surveys, gps,
photographic and video. I even occasionally use satellite imagery...
So the source data needs to be fine grained on the elements themselves.

Furthermore, when updating an element, I can see any source tags right
there. I am not normally going to all the faff of looking up the
history, finding the changesets and consulting those except for unusual
cases.

Of course, changesets need to have some overall source infomation, but
that is necessarily coarse except for small cahnges perhaps.

ael


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

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

[Cj Malone]

On Sat, 2020-07-25 at 16:42 +0200, Tobias Zwick wrote:
> If the date + *source* of the last change made on (the geometry of
> an) element was readily available, through the API or another meta-
> tag (source=bing, anyone? ;-) ), this would help to identify areas
> that should be updated because a new more current and/or detailed
> source became available.
> 
> In Hamburg, we are lucky that the public authority provides us with
> really detailed up-to-date satellite imagery that are far beyond bing
> but there is no easy way to see which buildings and road geometries
> have still been mapped on the basis of bing and which are already
> using the better source.
> 
> So in a nutshell, the topic of how to find things based on old
> sources is also very relevant for remote mappers.

Technically there is survey:date and source:date that may be on the
object, or (preferred now?) the changeset. So a quality assurance tool
could check that, however in practice they aren't nearly in use enough,
(editors using them by default would help), and there often isn't a
date attached to satellite imagery.

I also think they'd have to do multiple api calls to work it out, so it
could definitely be streamlined with a new api endpoint.

Cj


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

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

[Jmapb]

Hi Tobias, I've been giving this some thought. My conclusion is that
user validation of tags shouldn't be stored in the same database table
as the tags themselves. It's clear that as the map data ages, tag
validation is going to be a task with parallel and equal importance to
tagging itself, but with its own workflows and complexities. The
validation will have its own history separate from the tagging history,
and I believe it would be best to design the data model accordingly.

Using nodes as an example for the moment, I'd like to consider the
creation of a new table alongside node_tags, perhaps called
node_tag_validation. I imagine the fields would be:
 - node_id
 - user_id
 - tag key
 - current node version (to identify the current tag value being
validated -- or maybe just a copy of the current tag value, if that's
too cumbersome)
 - validation result (valid/invalid/unsure)
 - optional comment
 - timestamp

This would allow a map validator to:
 - confirm a tag or subset of tags, rather than the state of the entire
element
 - record agreement without updating the element
 - record unverifiability/disagreement/skepticism without changing or
deleting a tag (since sometimes there's middle ground between confirming
a certain tag and knowing that it's incorrect.)
 - weigh in on the validity/invalidity of the *absence* of a particular
tag, which can be just as important as evaluating the tags that are there.

It would also allow easy query of various users' judgement of a
particular tag over time, which would allow for more informed survey and QA.

This design would eliminate some of the potential problems that have
come up in this thread:
 - check date tags getting out of sync with tag values
 - overcrowding elements with check date tags, and the verifiability of
these tags (the validation history can have looser verifiability
requirements than the map data)
 - resistance to changesets that make no actual changes but simply
update a timestamp (and increment the version) to indicate new validation
 - debate over correct implementation of namespaces (eg
check_date:smoothness or smoothness:check_date)

Note that this table (or these tables, presuming one each for
node/way/relation) would not actually need to reside in the OSM database
itself, although that would make it easier if the goal were to share
among multiple QA projects, not just StreetComplete.

Thanks for your work!
Jason


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

[Tagging] Feature Proposal - RFC - UPRN & USRN

[Rob Nickerson]

Hi all,

Mappers in the United Kingdom are looking to agree two tags for mapping
'Unique Property Reference Numbers' and 'Unique Street Reference Numbers'.
To support this effort I volunteered to create the relevant proposal pages
on the wiki.

To view and comment on these please see:

https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn
https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn

These pages have already been posted to talk-gb and talk-ie (for Northern
Ireland) a few days ago. As long as there are no major blockers here, we
will move to the voting stage shortly.

Thank you,
*Rob*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging