Dear All,
I hope this note is not too off topic.
In order to maintain/improve the data quality for our mobile application, I
have been thinking about ways we can efficiently verify data for refill
points for drinking water at fountains participating refill cafes, bars and
other establishments. On
Hello Stuart,
may I suggest that you choose a personal email address for participating
in mailing lists. It feels really strange to address a message to
"europeanwaterproject". I don't want to talk with "a project", I want to
talk with a person.
On 06.04.20 09:31, European Water Project wrote:
>
On Mon, 6 Apr 2020 at 10:14, Frederik Ramm wrote:
> Dear Frederick,
>
> may I suggest that you choose a personal email address for participating
> in mailing lists. It feels really strange to address a message to
> "europeanwaterproject". I don't want to talk with "a project", I want to
> talk wi
Le 05.04.20 à 17:06, Ty Stockman a écrit :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care
> The urgent care tag is used at, for example, clinics, that offer walk-in
> service
isn't "walk-in" already included in reservation=no ?
and/or with emergency=yes ?
Am Mo., 6. Apr. 2020 um 10:13 Uhr schrieb Frederik Ramm :
> Secondly, this is a problem shared by all the "last survey" approaches:
> You're standing the logic on its head. You're essentially saying: "If
> the object has NOT changed in reality, please DO change it in OSM" (by
> updating the last-c
Dear Martin,
A date uses 3-4 bytes of memory. Just for brainstorming purposes, what
would be the total database size inflation if all keys on all nodes, ways
and relations in OpenStreetMap had 4 extra bytes of date meta data ?
Best regards,
Stuart
On Mon, 6 Apr 2020 at 11:42, Martin Koppenhoefe
Hello,
Le 06.04.20 à 09:31, European Water Project a écrit :
> I have been thinking about ways we can efficiently verify data
here's my workflow :
- once a year, I query all poi (bar, restaurant, shop) within my comfort
zone, and check all tag again.
if nothing change, I update the tag survey:dat
Hi Marc,
I am convinced survey:date is not the solution for maintaining large
swathes of OpenStreetMap data. Nor do I think putting a survey date at a
per tag level is realistic or workable.
Best regards,
Stuart
On Mon, 6 Apr 2020 at 12:24, Marc M. wrote:
> Hello,
>
> Le 06.04.20 à 09:31,
On 6/4/20 9:23 am, Joseph Eisenberg wrote:
The only thing that the proposal page still needs is a couple more
detailed definitions for some of the tags.
Maybe not. A quick read finds this statement:
protect_class=2 will be tagged as boundary=national_park (de facto)
This is a problem because
Dear all,
Thank you Joseph and Stuart for your very valuable comments, these exchanges are very constructive and personally I learn a lot about how OSM database works.
I agree with both of you, it seems more appropriate to use a nod
Honestly, reservation is definitely the wrong wording here, and so is emergency
(see talk page of proposal) however, tag as you wish.
From: Marc M.
Sent: Monday, April 6, 2020 2:27 AM
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Feature Proposal - RFC - U
> QUESTION : Oukasz was wondering if the tag refugee_site=yes does necessarily
> have to be associated with place or landuse?
As mentioned, it would be fine to use a new "key" like "refugee_site"
for a feature that is only mapped as nodes, but if it is going to be
used on areas it's important to
Andrew, would you please repeat this analysis with all features tagged
"protect_class=2" which have a wikidata tag?
I suspect that many of those will not match according to Wikidata.
On 4/6/20, Andrew Davidson wrote:
> On 6/4/20 9:23 am, Joseph Eisenberg wrote:
>> The only thing that the proposa
On Mon, Apr 6, 2020 at 6:37 AM Andrew Davidson wrote:
>
> On 6/4/20 9:23 am, Joseph Eisenberg wrote:
> > The only thing that the proposal page still needs is a couple more
> > detailed definitions for some of the tags.
>
> Maybe not. A quick read finds this statement:
>
> protect_class=2 will be t
I copied the draft note to a wiki page ... to facilitate the discussion
regarding per key last update date meta data.
https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap
Best regards,
Stuart
On Mon, 6 Apr 2020 at 11:56, European Water Project <
It's true that not all "National Parks" are IUCN level 2, though most
IUCN level 2 features appear to be National Parks, and of the 1700
boundary=national_park features which are also tagged with
protect_class, 3/4 are protect_class=2, only 1 out of 4 has a
different number. See http://overpass-tur
Am Mo., 6. Apr. 2020 um 14:00 Uhr schrieb Kevin Kenny <
kevin.b.ke...@gmail.com>:
> That would also allow us to address Joseph Eisenberg's objection (in
> the talk page on the WIki) that the proposal violates the 'one object,
> one tag' principle.
there is no such principle (AFAIK a principle l
On Mon, 6 Apr 2020 at 08:33, European Water Project <
europeanwaterproj...@gmail.com> wrote:
>
> In order to maintain/improve the data quality for our mobile application,
> I have been thinking about ways we can efficiently verify data for refill
> points for drinking water at fountains participat
Hi Paul,
Thank you for your comments.
You may well be right in your analysis Recording a fountain out of
order through the app is possible. I already count each fountain/refill
cafe click per fountain in a server side mysql database (yes, I know osm
numbers are mutable). .
This being said,
Le 06.04.20 à 15:09, Paul Allen a écrit :
> in your own app
so every app 'll have it's own lascheck database ?
so when I do my annual check-up of all the POIs in my comfort zone,
It 'll need going into the different related quality monitoring
applications them to mark that it's up to date so that
On Mon, 6 Apr 2020 at 15:17, Marc M. wrote:
> Le 06.04.20 à 15:09, Paul Allen a écrit :
> > in your own app
>
> so every app 'll have it's own lascheck database ?
>
Those that want to know about last check dates.
so when I do my annual check-up of all the POIs in my comfort zone,
> It 'll need
Hi Paul,
Yep. Because, as others have pointed out, implementing such a scheme
in OSM is hard. Not just technically hard, but "overcoming all the
people
who insist OSM MUST NOT do this" hard.
Can we focus our discussions to the technical aspects of different
solutions for storing
> one tag is supported for displaying "one kind of thing"
That's not at all the same as "One feature, one OSM element".
The basic principle is that you don't create 2 different database
objects for the same thing: you don't map a single school as a node
and as an area (closed way) around the node
On Mon, 6 Apr 2020 at 16:10, European Water Project <
europeanwaterproj...@gmail.com> wrote:
>
> Yep. Because, as others have pointed out, implementing such a scheme
> in OSM is hard. Not just technically hard, but "overcoming all the
> people
> who insist OSM MUST NOT do this" h
Hi Paul,
Maybe together we can come up with something new ... maybe not ... based on
my admittedly limited knowledge of OpenStreetMap, the issue of stale data
seems to be endemic for some types of data ... and not just a refill app
issue. Adding a couple of extra bytes to the data structure for s
For the record (though I understand that English track meaning doesn't fit
well)
leisure=track can be used with highway=*, 5% of them
highway=path wiki page says :
«This includes walking and hiking trails, bike trails and paths, horse and
stock trails, mountain bike trails as well as combinations
Hi,
On 06.04.20 17:25, Paul Allen wrote:
> Expecting mappers to wander around checking refill points
> is expecting far too much. Expecting people looking for refill points
> to tap a "this place still does refills" is expecting far too much.
Only way I would see this working is a "gamification"
I don't think we want or need an mtb= tag.
Even though we don't need a path=mtb tag, I'd be OK with it. It would
be a shortcut instead of adding some of the other tags. I don't think
routers for cycle touring should rely on this though.
I live in a popular mtb location (Colorado, USA), and I d
Hi Frederik,
I agree 100%.
The proposal thesis is that "Key level last updated date meta data" within
OSM, might be a useful ingredient for facilitating better data quality
maintenance on data which tends to go stale.
Best regards,
Stuart
On Mon, 6 Apr 2020 at 18:24, Frederik Ramm wrote:
>
the wording is one issue but I was more interested in meaning.
is it the same meaning ? if not please explain the difference
telling me "tag as you wis" is not an interesting answer for the quality
Le 06.04.20 à 13:11, Ty S a écrit :
> Honestly, reservation is definitely the wrong wording here,
Le 06.04.20 à 18:13, Florimond Berthoux a écrit :
> If a path can only be used by mtb I think access=no mtb=designated can
> be used (I understand that goes against path multi usage definition,
> but why access tags exist if we cannot use it ?)
I never see sutch sign. but if it exist, why not.
bu
Le 06.04.20 à 18:23, Frederik Ramm a écrit :
> Only way I would see this working is a "gamification" thing
QA tools can also warn "this poi hasn't been changed in a long time,
maybe you wish to review/resurvey it"
Some ppl like to have an "up-to-date area", and not rely
on luck to systematically d
On 6/4/20 9:59 pm, Kevin Kenny wrote:
Can we work around the problem simply by allowing 'protection_class'
to apply to 'boundary=national_park' as well as
'boundary=protected_area' and asserting that the default value of
'protection_class' for 'national_park' shall be assumed to be 2
(surely the
sent from a phone
> On 6. Apr 2020, at 16:51, Paul Allen wrote:
>
>> or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID
>
> I didn't even know that existed. I'm not sure I trust such IDs to survive
> intensive editing by newbies who can delete an object then add it
> with q
Dear Martin,
Yes, using external tables unioned to objects by opaque keys is not a very
KISS solution. A more KISS solution would be to keep tag meta data close to
or even better within the element itself.
Assuming all tag values are stored in zero based arrays, could we not add a
2 byte last upd
35 matches
Mail list logo