Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[stevea]

See, data always have a backstory.  Thinking you know what it is, or that you 
can improve upon OSM by erasing existing data that has a backstory, hmmm, give 
that one a good, long think first before you do anything.  Discuss with others, 
research, think about past, present and even future data/tagging schemes that 
might truly improve what you attempt to improve.  Doing this is complex and 
deserves complex treatment, not a gloss-over and quick action.

SteveA

> On Mar 17, 2020, at 4:38 PM, stevea  wrote:
> 
> I would like to stress once again how easily it is for intended semantics of 
> what is meant to be tagged, "improve-tagged" or "tag-modernized so that 
> people understand the historical context of this tag" to diverge from the 
> semantics that OTHER volunteers / contributors to OSM glean from these.  It 
> is SO easy for these to be far apart and people to misunderstand one another.
> 
> This entire endeavor is fraught with peril and is one of the most slippery 
> and dangerous (in the sense of hurt feelings due to misunderstandings, 
> usually unintentional) in any scheme that has to do with "tagging," as in OSM 
> with our tags (and their meant-to-be-static, though actually change through 
> time) semantics.
> 
> Please, let's better understand the very wide aspects of what's going on 
> here:  people invent a tag to mean "something" and perhaps it does for a 
> while, but it might get stretched with time and might morph to something 
> else.  And/or other tags emerge that better or "more newly" describe a scheme 
> to tag.  Meantime, there are rendering issues (some positive, some negative) 
> happening in parallel.  Even as people are mostly well-intentioned, this 
> process (especially as the project gets more mature and stretches across 
> generations of this happening, each cycle might be years or a decade) really 
> is complex and gives rise to all kinds of tangly, snarly misunderstandings.  
> Tread lightly, be cautious, try to be open-minded, have both a historical 
> understanding of how "meanings change over time" (even as we wish they 
> didn't" and "renderers change over time" (not always exactly in-line with 
> tagging schemes) as well as a willingness to expand context to the future.
> 
> And perhaps several other things I'm forgetting to mention... and we MIGHT be 
> able to better solve these issues.  We can solve them, we have to be smart, 
> patient and knowledgable about our past, looking to the future and aware of 
> how things drift and evolve.  That's tough, but doable.
> 
> Whew!
> SteveA
> 
>> On Mar 17, 2020, at 4:17 PM, Joseph Eisenberg  
>> wrote:
>> 
>> Unlike some of those who responded, I was not intending this status to
>> be a "mark of shame", but rather informative.
>> 
>> As mentioned, some imported tags like "gnis:feature_id=*" are useful
>> to keep the Openstreetmap database object directly linked to an object
>> in an external database.
>> 
>> That's why I am not suggesting the use of "deprecated" or "obsolete",
>> since these tags should not necessarily be removed.
>> 
>> The main reason to mark them is so that mappers and database users
>> will understand where the tag came from, and it may suggest that
>> mappers will not want to add these tags to objects in the future,
>> unless they are also importing features from the same source.
>> 
>> Besides the tags mentioned above, I was thinking about tags like
>> "object:postcode=" and "object:housenumber" - this tag is only used in
>> Germany on "highway=street_lamp" features which appear to have been
>> imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object
>> and see taghistory:
>> https://taghistory.raifer.tech/#***/object:postcode/ and
>> 
>> So, though the usage numbers are moderately high, it is helpful to
>> know that these tags are not really being used, except in that
>> particular context. Apparently it makes sense in the context of the
>> addressing system there, at least according to the mappers who
>> imported the objects.
>> 
>> If a tag which was first used in an imported then becomes popular and
>> used frequently by. mappers for new or updated features, then it could
>> change to "in use" or even "de facto", just like a "draft" or
>> "proposed" tag can change status due to usage over time.
>> 
>> So, just like the status "draft", the status "import" would be a hint
>> for mappers and database users, but would not suggest that the tag
>> needs to be removed, and it might change status in the future based on
>> use by mappers.
>> 
>> -- Joseph Eisenberg
>> 
>> On 3/18/20, Jmapb  wrote:
>>> On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote:
 However, among your examples you cite "gnis:feature_id=*" The wiki
 page for this key notes:
 "Unlike other imported tags such as gnis:created=* and
 gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import.
 In fact, some mappers actively add gnis:feature_id=* to features to
 cite a verifiable 

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Joseph Eisenberg]

> I don't think that swiching from addr:* to object:* on these objects is 
> correctly described by the term "mechanical edit".

Yes it was a mechanic/automated edit, because you switched all the tags at once

Not all mechanical edits are bad:
https://wiki.openstreetmap.org/wiki/What%27s_the_problem_with_mechanical_edits%3F

It sounds like you followed the Automated Edits code of conduct by
discussing the change with the local community first, and you mainly
edited objects that you had personally helped to map, so that is a
good example of an automated edit which was done according to best
practices:
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

-- Joseph Eisenberg

On 3/18/20, Harald Schwarz  wrote:
> Hello,
>
> the creation of the object:* tagging was the result of many remarks and
> disscussions. Most people agreed that the addr:* tag should be used
> only for buildings, shps, offices, etc.
>
> I thought that there was a need for an alternative addresing scheme that
> could be used without conflicting with the addr:* scheme.
> That was when I starteted to use the object:* scheme for the things I tagged
> in OSM.
>
> As I'm not only interrested in gas lamps but also in history culture and art
> I started to use this scheme for memorials and urban artwork.
> I conviced some people in my community to switch to this scheme and now more
> and more people use this scheme.
>
> I added a lot of Stolpersteine (memorial:type=stolperstein) and urban
> artwork (tourism=artwork) to the OSM database. All of them I visited
> personly and photos of this objects can be found on wikimedia commons.
>
> I have a very personal relation to these obects, visiting them in real
> world, during hot or cold weather, storing information about them
> to OSM in long concentrated sessions. I don't think that swiching from
> addr:* to object:* on these objects is correctly described by the
> term "mechanical edit".
>
> Mechanical edits are problematic in OSM as there might be change on
> something that doesn't exist anymore or needs a new survey at the place in
> real world.
> As I walk all this object from time to time, veryfing they still exist, I
> think that it is not ok to call my changes mechanical edits in the normal
> OSM sense.
>
> Friendly Greetings
>   Harald Schwarz
>   black_bike
>
>
>> Gesendet: Mittwoch, 18. März 2020 um 02:03 Uhr
>> Von: "Joseph Eisenberg" 
>> An: "Harald Schwarz" 
>> Betreff: Re: Re: [OSM-talk] Proposed new status for tags in the wiki:
>> "import" for undiscussed tags that were only used by an import
>>
>> Thank you for the information, Harald.
>>
>> > The peak in the graph, that you think indicates an import, is the result
>> > of switching fom the addr:*-style to the object:*-style.
>>
>> So it was not an import, but rather a mechanical edit. I will update
>> the object: page with this info.
>>
>> Do you know if a mechanical edit was also done for historic=memorial
>> features (with object:housenumber etc) around that time?
>>
>> -- Joseph Eisenberg
>>
>> On 3/18/20, Harald Schwarz  wrote:
>> > Dear Joseph, dear readers of this list,
>> >
>> > as you mention the street lamps of Düsseldorf here and thinking that
>> > they
>> > were an import to the OSM-database,
>> > I can tell you that this was not the case.
>> >
>> > Many of he streets of Düsseldorf, city of about 600_000 inhabitants,
>> > capital
>> > of Northrhine-Westfalia, Germany are lit by gaslight.
>> > About 15_000 gas lamps spent their glooming light every night. Each of
>> > this
>> > lamps has found it's way into the OSM database
>> > and even the status of streets lit by gaslight can be found in OSM.
>> >
>> > But this was not done by an import. It was a process, lasting many
>> > years,
>> > walking all the streets, stopping at every
>> > single gas lamp, taking photos and gps coordinates, later manualy
>> > storing
>> > the data to osm.
>> > The peak in the graph, that you think indicates an import, is the result
>> > of
>> > switching fom the addr:*-style to the object:*-style.
>> >
>> > Infos about the Düsseldorf Gaslight you can find in the OSM-Wiki under:
>> > https://wiki.openstreetmap.org/wiki/D%C3%BCsseldorf/Projekte/Gaslaternen
>> > You can watch the talk I gave at FOSSGIS 2019, Dresden :
>> > https://media.ccc.de/v/fossgis2019-556-erfassung-der-dsseldorfer-gasbeleuchtung
>> > .
>> >
>> > Mapping the gas lamps with OSM helped a lot to reach the status of
>> > national
>> > techical heritage.
>> > For this purpose maps and lists of all gas lamps in a suburb, in a
>> > street
>> > were created.
>> > This would not have been possible without the object:street tag.
>> >
>> > The object:* tag is not only useful for street lamps but can be used
>> > for
>> > memorials, urban artwork, technical infrastructure and many other
>> > things.
>> > Take a close look and see that other mappers started to use this tag
>> > for
>> > their own needs.
>> >
>> > With friendly greetings
>> >Harald Schwarz
>> >

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Harald Schwarz]

Hello,

the creation of the object:* tagging was the result of many remarks and 
disscussions. Most people agreed that the addr:* tag should be used
only for buildings, shps, offices, etc. 

I thought that there was a need for an alternative addresing scheme that could 
be used without conflicting with the addr:* scheme.
That was when I starteted to use the object:* scheme for the things I tagged in 
OSM.

As I'm not only interrested in gas lamps but also in history culture and art I 
started to use this scheme for memorials and urban artwork.
I conviced some people in my community to switch to this scheme and now more 
and more people use this scheme.

I added a lot of Stolpersteine (memorial:type=stolperstein) and urban artwork 
(tourism=artwork) to the OSM database. All of them I visited
personly and photos of this objects can be found on wikimedia commons. 

I have a very personal relation to these obects, visiting them in real world, 
during hot or cold weather, storing information about them
to OSM in long concentrated sessions. I don't think that swiching from addr:* 
to object:* on these objects is correctly described by the 
term "mechanical edit". 

Mechanical edits are problematic in OSM as there might be change on something 
that doesn't exist anymore or needs a new survey at the place in real world.
As I walk all this object from time to time, veryfing they still exist, I think 
that it is not ok to call my changes mechanical edits in the normal OSM sense.

Friendly Greetings
  Harald Schwarz
  black_bike 


> Gesendet: Mittwoch, 18. März 2020 um 02:03 Uhr
> Von: "Joseph Eisenberg" 
> An: "Harald Schwarz" 
> Betreff: Re: Re: [OSM-talk] Proposed new status for tags in the wiki: 
> "import" for undiscussed tags that were only used by an import
>
> Thank you for the information, Harald.
> 
> > The peak in the graph, that you think indicates an import, is the result of 
> > switching fom the addr:*-style to the object:*-style.
> 
> So it was not an import, but rather a mechanical edit. I will update
> the object: page with this info.
> 
> Do you know if a mechanical edit was also done for historic=memorial
> features (with object:housenumber etc) around that time?
> 
> -- Joseph Eisenberg
> 
> On 3/18/20, Harald Schwarz  wrote:
> > Dear Joseph, dear readers of this list,
> >
> > as you mention the street lamps of Düsseldorf here and thinking that they
> > were an import to the OSM-database,
> > I can tell you that this was not the case.
> >
> > Many of he streets of Düsseldorf, city of about 600_000 inhabitants, capital
> > of Northrhine-Westfalia, Germany are lit by gaslight.
> > About 15_000 gas lamps spent their glooming light every night. Each of this
> > lamps has found it's way into the OSM database
> > and even the status of streets lit by gaslight can be found in OSM.
> >
> > But this was not done by an import. It was a process, lasting many years,
> > walking all the streets, stopping at every
> > single gas lamp, taking photos and gps coordinates, later manualy storing
> > the data to osm.
> > The peak in the graph, that you think indicates an import, is the result of
> > switching fom the addr:*-style to the object:*-style.
> >
> > Infos about the Düsseldorf Gaslight you can find in the OSM-Wiki under:
> > https://wiki.openstreetmap.org/wiki/D%C3%BCsseldorf/Projekte/Gaslaternen
> > You can watch the talk I gave at FOSSGIS 2019, Dresden :
> > https://media.ccc.de/v/fossgis2019-556-erfassung-der-dsseldorfer-gasbeleuchtung
> > .
> >
> > Mapping the gas lamps with OSM helped a lot to reach the status of national
> > techical heritage.
> > For this purpose maps and lists of all gas lamps in a suburb, in a street
> > were created.
> > This would not have been possible without the object:street tag.
> >
> > The object:* tag is not only useful for street lamps but can be used for
> > memorials, urban artwork, technical infrastructure and many other things.
> > Take a close look and see that other mappers started to use this tag for
> > their own needs.
> >
> > With friendly greetings
> >Harald Schwarz
> >black_bike
> >
> >> Gesendet: Mittwoch, 18. März 2020 um 00:17 Uhr
> >> Von: "Joseph Eisenberg" 
> >> An: talk@openstreetmap.org
> >> Betreff: Re: [OSM-talk] Proposed new status for tags in the wiki: "import"
> >> for undiscussed tags that were only used by an import
> > 
> >>
> >> Besides the tags mentioned above, I was thinking about tags like
> >> "object:postcode=" and "object:housenumber" - this tag is only used in
> >> Germany on "highway=street_lamp" features which appear to have been
> >> imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object
> >> and see taghistory:
> >> https://taghistory.raifer.tech/#***/object:postcode/ and
> >>
> >> So, though the usage numbers are moderately high, it is helpful to
> >> know that these tags are not really being used, except in that
> >> particular context. Apparently it makes sense in the context of the
> >> addressing 

Re: [Talk-bo] Tramo El Sillar en Carretera F4 Colomi-Villa Tunari, Cochabamba

[Juan Jose Iglesias]

Excelente Trabajo Marco Antonio. Yo asumo q como en esa zona hay una población 
llamada Abra del Sillar, pues todo el área tomo ese nombre o viceversa.

Ciertamente No hay NADA que indique claramente de donde a dónde va la zona pues 
ni en la Cartografía del IGM sale algo concreto. 

En todo caso lindo trabajo. Felicitaciones

Abrazos y todo el mundo a Cuidarse del SARS-Cov-2 

JJ

-Original Message-
From: Marco Antonio Frias [mailto:marcoantoniofr...@gmail.com] 
Sent: Tuesday, March 17, 2020 7:09 PM
To: OSM Bolivia 
Subject: [Talk-bo] Tramo El Sillar en Carretera F4 Colomi-Villa Tunari, 
Cochabamba

Hola,

Después de años de pasar y repasar la carretera de Colomi a Villa Tunari o 
viceversa, nunca supe dónde estaba el dichoso tramo "El Sillar" que tanto 
hablaban, tampoco vi un mapa que mostraba gráficamente de dónde a dónde, claro 
que si sabía más o menos las fallas geológicas y deslizamientos que ocurrían...

https://overpass-turbo.eu/s/RFI

Después de años de colectar y anotar los deslizamientos, ya puse en el mapa las 
zonas de fallas geológicas, las áreas deslizadas, las superficies de la 
carretera que no son asfalto, por cierto hay tramos de hormigón, empedrado, 
asfalto sobre empedrado que se ve, ripio, y combinaciones 
concreto-asfalto-empedrado en pequeños tramos...

la ruta para auto =>
https://www.openstreetmap.org/directions?engine=graphhopper_car=-17.1855%2C-65.7462%3B-17.0293%2C-65.6570#map=12/-17.1018/-65.6842

Por las imágenes aún no se ven los trabajos de la nueva carretera y túneles del 
tramo que se construye, solo unos pilares de puentes

luego pondré en la wiki como mapee los deslizamientos, las fallas geológicas

Abrazos,

Marco Antonio

___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo


--
This email has been checked for viruses by AVG.
https://www.avg.com


___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Harald Schwarz via talk]

Dear Joseph, dear readers of this list,

as you mention the street lamps of Düsseldorf here and thinking that they were 
an import to the OSM-database,
I can tell you that this was not the case.

Many of he streets of Düsseldorf, city of about 600_000 inhabitants, capital of 
Northrhine-Westfalia, Germany are lit by gaslight.
About 15_000 gas lamps spent their glooming light every night. Each of this 
lamps has found it's way into the OSM database
and even the status of streets lit by gaslight can be found in OSM.

But this was not done by an import. It was a process, lasting many years, 
walking all the streets, stopping at every 
single gas lamp, taking photos and gps coordinates, later manualy storing the 
data to osm.
The peak in the graph, that you think indicates an import, is the result of 
switching fom the addr:*-style to the object:*-style.

Infos about the Düsseldorf Gaslight you can find in the OSM-Wiki under: 
https://wiki.openstreetmap.org/wiki/D%C3%BCsseldorf/Projekte/Gaslaternen
You can watch the talk I gave at FOSSGIS 2019, Dresden : 
https://media.ccc.de/v/fossgis2019-556-erfassung-der-dsseldorfer-gasbeleuchtung 
.

Mapping the gas lamps with OSM helped a lot to reach the status of national 
techical heritage. 
For this purpose maps and lists of all gas lamps in a suburb, in a street were 
created. 
This would not have been possible without the object:street tag.

The object:* tag is not only useful for street lamps but can be used for 
memorials, urban artwork, technical infrastructure and many other things.
Take a close look and see that other mappers started to use this tag for their 
own needs.

With friendly greetings
   Harald Schwarz
   black_bike

> Gesendet: Mittwoch, 18. März 2020 um 00:17 Uhr
> Von: "Joseph Eisenberg" 
> An: talk@openstreetmap.org
> Betreff: Re: [OSM-talk] Proposed new status for tags in the wiki: "import" 
> for undiscussed tags that were only used by an import

> 
> Besides the tags mentioned above, I was thinking about tags like
> "object:postcode=" and "object:housenumber" - this tag is only used in
> Germany on "highway=street_lamp" features which appear to have been
> imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object
> and see taghistory:
> https://taghistory.raifer.tech/#***/object:postcode/ and
> 
> So, though the usage numbers are moderately high, it is helpful to
> know that these tags are not really being used, except in that
> particular context. Apparently it makes sense in the context of the
> addressing system there, at least according to the mappers who
> imported the objects.

> 
> -- Joseph Eisenberg
> 


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

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[stevea]

I would like to stress once again how easily it is for intended semantics of 
what is meant to be tagged, "improve-tagged" or "tag-modernized so that people 
understand the historical context of this tag" to diverge from the semantics 
that OTHER volunteers / contributors to OSM glean from these.  It is SO easy 
for these to be far apart and people to misunderstand one another.

This entire endeavor is fraught with peril and is one of the most slippery and 
dangerous (in the sense of hurt feelings due to misunderstandings, usually 
unintentional) in any scheme that has to do with "tagging," as in OSM with our 
tags (and their meant-to-be-static, though actually change through time) 
semantics.

Please, let's better understand the very wide aspects of what's going on here:  
people invent a tag to mean "something" and perhaps it does for a while, but it 
might get stretched with time and might morph to something else.  And/or other 
tags emerge that better or "more newly" describe a scheme to tag.  Meantime, 
there are rendering issues (some positive, some negative) happening in 
parallel.  Even as people are mostly well-intentioned, this process (especially 
as the project gets more mature and stretches across generations of this 
happening, each cycle might be years or a decade) really is complex and gives 
rise to all kinds of tangly, snarly misunderstandings.  Tread lightly, be 
cautious, try to be open-minded, have both a historical understanding of how 
"meanings change over time" (even as we wish they didn't" and "renderers change 
over time" (not always exactly in-line with tagging schemes) as well as a 
willingness to expand context to the future.

And perhaps several other things I'm forgetting to mention... and we MIGHT be 
able to better solve these issues.  We can solve them, we have to be smart, 
patient and knowledgable about our past, looking to the future and aware of how 
things drift and evolve.  That's tough, but doable.

Whew!
SteveA

> On Mar 17, 2020, at 4:17 PM, Joseph Eisenberg  
> wrote:
> 
> Unlike some of those who responded, I was not intending this status to
> be a "mark of shame", but rather informative.
> 
> As mentioned, some imported tags like "gnis:feature_id=*" are useful
> to keep the Openstreetmap database object directly linked to an object
> in an external database.
> 
> That's why I am not suggesting the use of "deprecated" or "obsolete",
> since these tags should not necessarily be removed.
> 
> The main reason to mark them is so that mappers and database users
> will understand where the tag came from, and it may suggest that
> mappers will not want to add these tags to objects in the future,
> unless they are also importing features from the same source.
> 
> Besides the tags mentioned above, I was thinking about tags like
> "object:postcode=" and "object:housenumber" - this tag is only used in
> Germany on "highway=street_lamp" features which appear to have been
> imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object
> and see taghistory:
> https://taghistory.raifer.tech/#***/object:postcode/ and
> 
> So, though the usage numbers are moderately high, it is helpful to
> know that these tags are not really being used, except in that
> particular context. Apparently it makes sense in the context of the
> addressing system there, at least according to the mappers who
> imported the objects.
> 
> If a tag which was first used in an imported then becomes popular and
> used frequently by. mappers for new or updated features, then it could
> change to "in use" or even "de facto", just like a "draft" or
> "proposed" tag can change status due to usage over time.
> 
> So, just like the status "draft", the status "import" would be a hint
> for mappers and database users, but would not suggest that the tag
> needs to be removed, and it might change status in the future based on
> use by mappers.
> 
> -- Joseph Eisenberg
> 
> On 3/18/20, Jmapb  wrote:
>> On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote:
>>> However, among your examples you cite "gnis:feature_id=*" The wiki
>>> page for this key notes:
>>> "Unlike other imported tags such as gnis:created=* and
>>> gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import.
>>> In fact, some mappers actively add gnis:feature_id=* to features to
>>> cite a verifiable source for the POI's existence or its name."
>> 
>> Agree with clemency for gnis:feature_id -- it's handy to be able to
>> crossreference features with the GNIS database, which you can search by
>> feature id here: https://geonames.usgs.gov/apex/f?p=138:1:0:
>> 
>> J
>> 
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


___
talk 

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Joseph Eisenberg]

Unlike some of those who responded, I was not intending this status to
be a "mark of shame", but rather informative.

As mentioned, some imported tags like "gnis:feature_id=*" are useful
to keep the Openstreetmap database object directly linked to an object
in an external database.

That's why I am not suggesting the use of "deprecated" or "obsolete",
since these tags should not necessarily be removed.

The main reason to mark them is so that mappers and database users
will understand where the tag came from, and it may suggest that
mappers will not want to add these tags to objects in the future,
unless they are also importing features from the same source.

Besides the tags mentioned above, I was thinking about tags like
"object:postcode=" and "object:housenumber" - this tag is only used in
Germany on "highway=street_lamp" features which appear to have been
imported mostly in 2015: http://wiki.openstreetmap.org/wiki/Key:object
and see taghistory:
https://taghistory.raifer.tech/#***/object:postcode/ and

So, though the usage numbers are moderately high, it is helpful to
know that these tags are not really being used, except in that
particular context. Apparently it makes sense in the context of the
addressing system there, at least according to the mappers who
imported the objects.

If a tag which was first used in an imported then becomes popular and
used frequently by. mappers for new or updated features, then it could
change to "in use" or even "de facto", just like a "draft" or
"proposed" tag can change status due to usage over time.

So, just like the status "draft", the status "import" would be a hint
for mappers and database users, but would not suggest that the tag
needs to be removed, and it might change status in the future based on
use by mappers.

-- Joseph Eisenberg

On 3/18/20, Jmapb  wrote:
> On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote:
>> However, among your examples you cite "gnis:feature_id=*" The wiki
>> page for this key notes:
>> "Unlike other imported tags such as gnis:created=* and
>> gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import.
>> In fact, some mappers actively add gnis:feature_id=* to features to
>> cite a verifiable source for the POI's existence or its name."
>
> Agree with clemency for gnis:feature_id -- it's handy to be able to
> crossreference features with the GNIS database, which you can search by
> feature id here: https://geonames.usgs.gov/apex/f?p=138:1:0:
>
> J
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

[Talk-bo] Tramo El Sillar en Carretera F4 Colomi-Villa Tunari, Cochabamba

[Marco Antonio Frias]

Hola,

Después de años de pasar y repasar la carretera de Colomi a Villa
Tunari o viceversa, nunca supe dónde estaba el dichoso tramo "El
Sillar" que tanto hablaban, tampoco vi un mapa que mostraba
gráficamente de dónde a dónde, claro que si sabía más o menos las
fallas geológicas y deslizamientos que ocurrían...

https://overpass-turbo.eu/s/RFI

Después de años de colectar y anotar los deslizamientos, ya puse en el
mapa las zonas de fallas geológicas, las áreas deslizadas, las
superficies de la carretera que no son asfalto, por cierto hay tramos
de hormigón, empedrado, asfalto sobre empedrado que se ve, ripio, y
combinaciones concreto-asfalto-empedrado en pequeños tramos...

la ruta para auto =>
https://www.openstreetmap.org/directions?engine=graphhopper_car=-17.1855%2C-65.7462%3B-17.0293%2C-65.6570#map=12/-17.1018/-65.6842

Por las imágenes aún no se ven los trabajos de la nueva carretera y
túneles del tramo que se construye, solo unos pilares de puentes

luego pondré en la wiki como mapee los deslizamientos, las fallas geológicas

Abrazos,

Marco Antonio

___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo

Re: [Talk-at] serice=alley am Lande

[Stefan Tauner]

On Tue, 17 Mar 2020 20:59:38 +0100
Patrick Strasser-Mikhail  wrote:

> Das gleiche gilt für service=driveway (das wäre eine Auffahrt im Sinne 
> der amerikanischen Suburbs, also eine kurze Einfahrt auf privatem Grund, 
> die quasi Parkplatz ist). Öfters sehe ich das als Teil einer 
> highway=service für die Strecke ab der letzten Kreuzung, auch längere 
> Strecken statt ein paar Meter. Auch sehe ich es in der falschen 
> Interpretation von "Fahrweg".

Der Name Driveway ist viel viel älter als dessen (eigentümliche)
Verwendung bei den Amis... siehe z.B.:
 - https://en.wikipedia.org/wiki/Driveway
 - https://www.youtube.com/watch?v=Eu1XTrk5i0s
Es ist deshalb vollkommen korrekt die Zufahrten innerhalb einzelner
Grundstücke unabhängig von ihrer Länge als solche zu taggen IMHO.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] serice=alley am Lande

[Friedrich Volkmann]

On 17.03.20 20:59, Patrick Strasser-Mikhail wrote:
In ganz Österreich gibt es viele highway=service (Haus- und Hofzufahrten 
ohne weiter Verbindungsfunktion), die zusätzlich service=alley (also "Enge 
Gasse, Versorgungssgasse") haben[...]

Also, wo kommt es her und was macht man damit?


Wer oft englische Texte liest, denkt auf Englisch anders als auf Deutsch. 
Weniger Geübte übersetzen jeden Englischen Satz Wort für Wort auf Deutsch um 
ihn zu verstehen (und umgekehrt um etwas auf Englisch von sich zu geben). 
Wenn eine Bedeutung scheinbar klar ist, weil es ein ganz ähnlich aussehendes 
deutsches Wort gibt, neigt man dazu, sich das Nachschlagen im Wörterbuch zu 
ersparen. Darum fallen Ungeübte auf viele "falschen Freunde" herein, z.B. 
kam mir in verschiedenen Firmen unter, dass "aktuell" konsequent mit 
"actual" übersetzt wurde oder "muss nicht" mit "must not" und "darf nicht" 
mit "may not". Berühmt ist der Fall, wo ein Journalist Brian Ferry gegenüber 
dessen Songs als "pathetic" lobte und der dann eingeschnappt war.


Solche "falschen Freunde" sind auch "alley" und "Allee". Ich glaube, dass 
die Existenz von Bäumen neben einer Straße manche Mapper dazu bewegt, die 
Straße als "alley" zu taggen.


Wo ich falschen service=alley begegnet bin, war meistens auch 
highway=service schon dubios. Das sollte nur für unmittelbare Zufahrten zu 
einem oder sehr wenigen Objekten verwendet werden. Wenn eine Zufahrt länger 
ist, ist sie nicht mehr nur eine Zufahrt zum Gehöft, sondern auch zu den 
Feldern/Wiesen/Wäldern neben der Straße. Oft zweigen sogar Feldwege ab, 
womit sich ein Wegenetz ergibt. Solche vermeintlichen Zufahrten sollten 
besser als highway=track (oder evtl. unclassified bzw. residential) getaggt 
werden, nicht als service.


Was man damit macht? Umtaggen halt. Aber noch besser ist es, den jeweiligen 
Mapper anzuschreiben, damit er den Fehler nicht immer wieder macht.


Aber wenn du jemanden anschreibst, dann warte erst mal seine Antwort ab, 
bevor du alles von ihm umtaggst. Jemanden vor vollendete Tatsachen zu 
stellen und dann so zu tun, als wär man zu einer Diskussion bereit, ist 
Heuchelei und kommt entsprechend schlecht an.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] serice=alley am Lande

[Patrick Strasser-Mikhail]

Hallo!

Ich bin über seltsames Tagging gestoßen:

In ganz Österreich gibt es viele highway=service (Haus- und Hofzufahrten 
ohne weiter Verbindungsfunktion), die zusätzlich service=alley (also 
"Enge Gasse, Versorgungssgasse") haben. In städtischen Gebieten oder wo 
Häuser dicht stehen oder wo es sowas wie in UK üblich hinter den Gärten 
ein Fußweg für Hintereingänge besteht, verstehe ich das voll und ganz. 
Aber dieser zweite Tag taucht vor allem in ländlichem Gebiet auf, auf 
weiter Flur also, ohne ersichtlichen Grund.


Das gleiche gilt für service=driveway (das wäre eine Auffahrt im Sinne 
der amerikanischen Suburbs, also eine kurze Einfahrt auf privatem Grund, 
die quasi Parkplatz ist). Öfters sehe ich das als Teil einer 
highway=service für die Strecke ab der letzten Kreuzung, auch längere 
Strecken statt ein paar Meter. Auch sehe ich es in der falschen 
Interpretation von "Fahrweg".


Ich hab mir das mit Overpass Turbo angeschaut, aber bin nicht ganz 
schlau draus geworden. Es gibt Gegenden in denen es verbreitet ist, und 
dann aber nicht alle Straßen, aber zusammenhängende Wege.


Es scheint mir aber so, dass es eine verbreitete Meinung (aus einer 
Anleitung oder Dokumentation), eine Praxis (abgeschaut) oder einen 
Mechanismus (Tool, das bei highway=service nach service= fragt und dann 
halt das genommen wird, das irgendwie vernünftig ausschaut) gibt, die 
das einmal ausgelöst hat.


Für mich ist es sowohl aus dem definierten Gebrauch der Tags als auch 
aus der "natürlichen" Semantik falsch. Es sind aber Unmengen davon 
verstreut. Automatische Erkennung scheint nicht ganz trivial: 
service=alley ist für enge Gassen, zwar hautpsächlich in städischem 
Gebiet, aber das kann überall auftreten wo Gebäude dicht stehen. 
service=driveway für alles was länger als ein paar Meter ist scheint 
erkennbar zu sein.


Also, wo kommt es her und was macht man damit?

LG Patrick/trapicki


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-be] Bunkers

[Marc Gemis]

are you sure it's not

building=bunker
abandoned:military=bunker

?

my reasoning is:  it's still a building, but no longer a military installation.

m.

On Tue, Mar 17, 2020 at 5:16 PM Lionel Giard  wrote:
>
> For abandonned (historic) military bunker, the correct mapping is :
> - abandonned:building=bunker
> - military=bunker
> - bunker_type=* (most of them are pillbox for those defensive belt around our 
> big cities)
> - historic=yes
> ...
>
> So that you get all the information that it is no longer in use ! ^_^
> Look on the wiki for more detailed tagging:  
> https://wiki.openstreetmap.org/wiki/Tag:military%3Dbunker
>
> Kind Regards,
> Lionel
>
> Le mar. 17 mars 2020 à 16:51, Marc M.  a écrit :
>>
>> Hello,
>>
>> Le 17.03.20 à 16:26, rodeo .be a écrit :
>> > I assume they were not visible because the tags were deprecated
>>
>> military=bunker isn't deprecated, it's the correct tag for a bunker
>> still in military use.
>>
>> I found at least one currently visible mapped with a node
>> https://www.openstreetmap.org/node/29049422
>> another mapped with an area https://www.openstreetmap.org/way/25586752
>>
>> Regards,
>> Marc
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[European Water Project]

Salut Marc,

On est bien d'accord qu'une photo d'un point d'eau qui n'est autre qu'un
simple robinet sur un mur n'a pas beaucoup d’intérêt.

Tes pistes de solutions avec OpenStreetCam, Mapillary et autre me semble
très bien à creuser.

Le fait de répondre à la question de Pic4Review très souvent ne mérite dans
mes yeux l'ajout de la photo Mapillary dans OSM pour les raisons déjà
énumérées.  C'est dommage que c'est fait automatiquement.

Avoir des photos bien centrées et avec un bon éclairage des bornes de
recharge pour voiture me semble utile pour une application mobile.

Bien cordialement,

Stuart



On Tue, 17 Mar 2020 at 18:11, Marc M.  wrote:

> Le 17.03.20 à 14:57, European Water Project a écrit :
> > Par rapport à l’intérêt de mettre des photos des points d'eau, je donne
> > deux exemples. Je viens d'ajouter des photos pour presque toutes les
> > Fontaines Wallace à Paris.
>
> les fontaines c'est autre chose, il y a un côté artistique.
> je parlais des points d'eau, parfois un bête robinet quelconque
> comme il en existe dans n'importe quel magasin de bricolage.
> je doute qu'avoir une photo de cette pièce de quincaillerie
> soie un facteur décisif provoquant le déclic chez quelqu'un pour se dire
> "j'arrête le plastique à usage unique parce que j'ai vu le robinet"
> je suis persuadé par cette cause et j'ajoute autant de point que
> possible. mais la photo est à mes yeux anecdotique.
>
> Idem pour les bornes. hormis "prouver" son existence (ce que
> source=mapillary sur le changeset fait tout aussi bien),
> je ne suis pas sur qu'une ribambelle de photo aide à la cause.
> En tout cas de ceux que j'en connais, il y a ceux qui sont convaincu et
> qui n'ont pas besoin de photo mais d'info (genre quel poi a-t-il une
> borne en cas de trajet très longue distance ?)
> et il y a ceux qui regardent les photos mais ne les utiliseront pas
> parce que toujours une excuse pour dire que cela ne convient pas.
>
> > Il y a maintenant qq cafés
>
> pour un café, je conçois qu'avoir une image de la façade est sympa
> pour une app qui l'utilise.
> mais je persiste à croire qu'il y a une erreur de cible avec Mapillary.
> Mapillary est fait pour prendre des séquences (servant principalement à
> entraîner une IA produisant des données secondaires)
> fatalement les séquences ne sont généralement pas adaptées pour avoir
> une belle photo parfaite de chaque objet rencontré.
> ou alors il faut des séquences "serrées" et avec une très bon
> positionnement gps, voir un lissage. c'est pas le cas par défaut.
>
> si on souhaite un "workflow" facile pour "capturer un objet précis à
> mettre dans osm" et que wikimedia common ne convient pas (parce que trop
> commun), je me demande s'il ne faudrait pas resortir le projet de poc
> mapillary-like dont nous avons parlé dans l'entourage de l'association
> osm-fr cad faire un endroit ou le contributeur envoi ses photos de
> manière unique, et ce serveur renvoi à différent service (nous avions
> évoqué à l'époque Mapillary et openstreetcam) et/ou rend disponible cela
> directement (comme le fait StreetComplete avec les notes+photo)
> on peux techniquement imaginer que le serveur retourne une url
> temporaire (à ajouter dans osm), envoi à Mapillary, attend X temps
> pour traitement côté Mapillary, puis fasse une requête Mapillary
> pour trouver l'id de la photo chez mapillary.
> D'ailleurs il n'y a pas besoin du projet de poc.
> je pense que n'importe quel appli qui enverrait un photo à Mapillary
> peux sans soucis faire une requête api pour retrouver l'id de la photo
> envoyée à telle position. surtout si c'est une photo unique et non
> une photo dans une séquence dense.
>
> > Ce qui me dérange plus que la manque de bonnes photos dans OSM et le
> > fait que pic4review ajoute quasl-automatiquement des photos dans OSM qui
> > n'ont quasiment rien avec l'objet.
>
> si j'ai bien compris la logique, Pic4review ajoute le tag de la photo
> si tu as pu répondre à la question en restant sur cette photo.
> donc au minimum l'objet concerné est bien visible sur cette photo.
>
> > Merci de le faire pour le fun si tu n'es pas convaincu ...
>
> je ne suis uniquement pas convaincu qu'il faille une photo
> d'un robinet pour se passer de plastique à usage unique :)
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] +++Nuovo modello autocertificazione (17/3/2020)+++

[Lorenzo Rolla]

Un bravo anche a questo giovane...

https://autocertificazionespostamenti.it


Il giorno mar 17 mar 2020 alle 15:37 Cascafico Giovanni 
ha scritto:

> Un bel form pdf online non sarebbe male: é piuttosto difficile scrivere il
> comune di residenza in un centimetro.
>
> Il mar 17 mar 2020, 12:23 Lorenzo Rolla  ha scritto:
>
>> Magari a qualcuno interessa... Il link al modello non funziona. Buona
>> giornata
>>
>> https://www.interno.gov.it/it/notizie/nuovo-modello-autodichiarazioni
>> --
>> Lorenzo Rolla
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
-- 
Lorenzo Rolla
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-es] Mapaton Humanitario 2020 - tarde del 21 de Abril

[Carlos Guallart]

Bueno, otra vez será.
Cuídate!
Un abrazo

El mar., 17 mar. 2020 a las 16:19, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Hola Carlos, Cómo van la Vida?
> Nunca te respondi a esto y ahora limpiando correo te comento que visto
> cómo están las cosas no se que pasará al respecto pero es.posible que no
> haya mapaton nisiquiera cambio de fecha.
> Habrá que olvidarse hasta 2021... si acaso.
> Espero que estés bien.
> Saludos desde Peñaflor.
> Miguel
>
> On Sat, 7 Mar 2020, 13:51 Carlos Guallart,  wrote:
>
>> Hola, Miguel:
>> si necesitas ayuda para la de Zaragoza (21 abril), creo que podré echarte
>> una mano.
>> Ya dirás
>> Un abrazo
>>
>> El sáb., 7 mar. 2020 a las 13:12, Miguel Sevilla-Callejo (<
>> msevill...@gmail.com>) escribió:
>>
>>> Hola a todos,
>>>
>>> Como ya he ido avisando por otros mensajes (disculpad la duplicidad) el
>>> próximo 21 de abril vamos a promover desde Zaragoza y de la mano del
>>> Colegio de Geógrafos y Cruz Roja la realización de un mapatón humanitario
>>> coordinado, al modo de lo que hicimos el año pasado y en otras ocasiones
>>> [1].
>>>
>>> Si alguien está interesado en unirse a alguna de las iniciativas que ya
>>> están saliendo o ayudar en organizar un evento en su localidad que se ponga
>>> en contacto conmigo para la coordinación.
>>>
>>> Un saludo
>>>
>>> Miguel
>>>
>>> [1] https://mapcolabora.org/project/mapaton-humanitario/
>>>
>>> --
>>> *Miguel Sevilla-Callejo*
>>> Doctor en Geografía
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>
>>
>> --
>> Carlos Guallart
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>


-- 
Carlos Guallart
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[Marc M.]

Le 17.03.20 à 14:57, European Water Project a écrit :
> Par rapport à l’intérêt de mettre des photos des points d'eau, je donne
> deux exemples. Je viens d'ajouter des photos pour presque toutes les
> Fontaines Wallace à Paris.

les fontaines c'est autre chose, il y a un côté artistique.
je parlais des points d'eau, parfois un bête robinet quelconque
comme il en existe dans n'importe quel magasin de bricolage.
je doute qu'avoir une photo de cette pièce de quincaillerie
soie un facteur décisif provoquant le déclic chez quelqu'un pour se dire
"j'arrête le plastique à usage unique parce que j'ai vu le robinet"
je suis persuadé par cette cause et j'ajoute autant de point que
possible. mais la photo est à mes yeux anecdotique.

Idem pour les bornes. hormis "prouver" son existence (ce que
source=mapillary sur le changeset fait tout aussi bien),
je ne suis pas sur qu'une ribambelle de photo aide à la cause.
En tout cas de ceux que j'en connais, il y a ceux qui sont convaincu et
qui n'ont pas besoin de photo mais d'info (genre quel poi a-t-il une
borne en cas de trajet très longue distance ?)
et il y a ceux qui regardent les photos mais ne les utiliseront pas
parce que toujours une excuse pour dire que cela ne convient pas.

> Il y a maintenant qq cafés

pour un café, je conçois qu'avoir une image de la façade est sympa
pour une app qui l'utilise.
mais je persiste à croire qu'il y a une erreur de cible avec Mapillary.
Mapillary est fait pour prendre des séquences (servant principalement à
entraîner une IA produisant des données secondaires)
fatalement les séquences ne sont généralement pas adaptées pour avoir
une belle photo parfaite de chaque objet rencontré.
ou alors il faut des séquences "serrées" et avec une très bon
positionnement gps, voir un lissage. c'est pas le cas par défaut.

si on souhaite un "workflow" facile pour "capturer un objet précis à
mettre dans osm" et que wikimedia common ne convient pas (parce que trop
commun), je me demande s'il ne faudrait pas resortir le projet de poc
mapillary-like dont nous avons parlé dans l'entourage de l'association
osm-fr cad faire un endroit ou le contributeur envoi ses photos de
manière unique, et ce serveur renvoi à différent service (nous avions
évoqué à l'époque Mapillary et openstreetcam) et/ou rend disponible cela
directement (comme le fait StreetComplete avec les notes+photo)
on peux techniquement imaginer que le serveur retourne une url
temporaire (à ajouter dans osm), envoi à Mapillary, attend X temps
pour traitement côté Mapillary, puis fasse une requête Mapillary
pour trouver l'id de la photo chez mapillary.
D'ailleurs il n'y a pas besoin du projet de poc.
je pense que n'importe quel appli qui enverrait un photo à Mapillary
peux sans soucis faire une requête api pour retrouver l'id de la photo
envoyée à telle position. surtout si c'est une photo unique et non
une photo dans une séquence dense.

> Ce qui me dérange plus que la manque de bonnes photos dans OSM et le
> fait que pic4review ajoute quasl-automatiquement des photos dans OSM qui
> n'ont quasiment rien avec l'objet.

si j'ai bien compris la logique, Pic4review ajoute le tag de la photo
si tu as pu répondre à la question en restant sur cette photo.
donc au minimum l'objet concerné est bien visible sur cette photo.

> Merci de le faire pour le fun si tu n'es pas convaincu ...

je ne suis uniquement pas convaincu qu'il faille une photo
d'un robinet pour se passer de plastique à usage unique :)

Cordialement,
Marc

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[European Water Project]

Bonjour Yves,

Merci pour ton email.

>
Le problème vient plutôt de la qualité des photos de Mapillary et de leur
positionnement.

C’est pour ça que je fais des photos « posées » et je les télécharge dans
Wikimedia Commons
(Dans Mapillary, la série n’est pas adaptée pour des photos « uniques ». De
plus la direction de prise de vue n’est pas fiable).

*exactement, c'est pour ça que ça serait top d'avoir cette nouvelle
fonctionnalité dans  Mapillary. J’ai reçu une réponse de Chris Beddow, qui
me disait qu’ils ont reçu plusieurs demandes semblables, mais
pour l’instant ce n’est pas une priorité
commerciale. 
https://forum.mapillary.com/t/trackable-photo-receipt-after-upload/3813
  *
*L'idée de la suggestion est justement pour créer un workflow dans
Mapiillary pour les photos uniques - jusqu'à présent quasi impossible. *

*>*
Pas sûr d’avoir tout compris :
Quel est l’intérêt de l’email ?
Une zone avec du texte libre, pourquoi pas un champ de saisie avec l’id
d’un objet OSM ??
Dans Commons, il est possible de saisir une ou plusieurs zones dans une
photo, et de mettre un lien vers un objet OSM.

*L’intérêt de l'email dans notre cas spécifique, est que nous avons
quelques volontaires dans plusieurs villes dans plusieurs pays qui sont
prêts à ajouter des cafés et des photos dans le réseau d'European Water
Project, mais qui ne sont pas hyper techniques et n'ont pas trop envie de
rentrer dans écosystème d'OSM. Avec un workflow épuré et une App adéquate,
ils peuvent prendre des photo des fontaines déjà existantes et nous envoyer
les lien des photo pour que nous les ajoutons d'une façon assez
efficace  ...  un texte libre, parce que peut-être l'objet OSM n'existe pas
encore au moment de la prise, et tu veux décrire juste un rappel. *

Bien cordialement,

Stuart

On Tue, 17 Mar 2020 at 17:28, Yves P.  wrote:

> le lien envoi vers la mission, du coup difficile de comprendre
> de quel exemple précis tu parles
>
> Je n’ai pas trouvé comment mettre un lien sur un objet OSM à contrôler.
> Adrien, peux-tu mettre ça dans l’URL ?
> Par exemple https://pic4review.pavie.info/#/mission/921/review/n5725980841
>
>
> Ce qui me dérange plus que la manque de bonnes photos dans OSM et le fait
> que pic4review ajoute quasi-automatiquement des photos dans OSM qui n'ont
> quasiment rien avec l’objet.
>
> Le problème vient plutôt de la qualité des photos de Mapillary et de leur
> positionnement.
>
> C’est pour ça que je fais des photos « posées » et je les télécharge dans
> Wikimedia Commons
> (Dans Mapillary, la série n’est pas adaptée pour des photos « uniques ».
> De plus la direction de prise de vue n’est pas fiable).
>
> Ça rejoint peut-être ta remarque ci-dessous ?
>
> Est-ce que nous pouvons rendre plus facile le workflow pour prendre des
> photos avec un téléphone mobile et les ajouter automatiquement (ou presque)
> dans OSM ? J'ai fait une demande pour une nouvelle fonctionnalité dans le
> forum de Mapillary.
>
> Pas sûr d’avoir tout compris :
> Quel est l’intérêt de l’email ?
> Une zone avec du texte libre, pourquoi pas un champ de saisie avec l’id
> d’un objet OSM ??
> Dans Commons, il est possible de saisir une ou plusieurs zones dans une
> photo, et de mettre un lien vers un objet OSM.
>
> Mais dans tous les cas, ça demande beaucoup de travail pour référencer des
> photos.
>
>   Pic4review me semble plus utile pour confirmer l’existence d'un objet ou
> ses caractéristiques que pour l'ajout des photos.
>
> Dire si un poteau incendie ou une borne de recharge est visible : OK.
> Dire combien de véhicules on peut recharger c’est plus difficile (surtout
> que souvent, on ne voit rien).
>
> Mieux ne pas avoir une photo dans OSM qu'une photo qui n'a rien avoir avec
> l’objet.
>
> Oui :)
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[Yves P.]

> le lien envoi vers la mission, du coup difficile de comprendre
> de quel exemple précis tu parles
Je n’ai pas trouvé comment mettre un lien sur un objet OSM à contrôler.
Adrien, peux-tu mettre ça dans l’URL ?
Par exemple https://pic4review.pavie.info/#/mission/921/review/n5725980841


> Ce qui me dérange plus que la manque de bonnes photos dans OSM et le fait que 
> pic4review ajoute quasi-automatiquement des photos dans OSM qui n'ont 
> quasiment rien avec l’objet.
Le problème vient plutôt de la qualité des photos de Mapillary et de leur 
positionnement.

C’est pour ça que je fais des photos « posées » et je les télécharge dans 
Wikimedia Commons
(Dans Mapillary, la série n’est pas adaptée pour des photos « uniques ». De 
plus la direction de prise de vue n’est pas fiable).

Ça rejoint peut-être ta remarque ci-dessous ?
> Est-ce que nous pouvons rendre plus facile le workflow pour prendre des 
> photos avec un téléphone mobile et les ajouter automatiquement (ou presque) 
> dans OSM ? J'ai fait une demande pour une nouvelle fonctionnalité dans le 
> forum de Mapillary. 
Pas sûr d’avoir tout compris :
Quel est l’intérêt de l’email ?
Une zone avec du texte libre, pourquoi pas un champ de saisie avec l’id d’un 
objet OSM ??
Dans Commons, il est possible de saisir une ou plusieurs zones dans une photo, 
et de mettre un lien vers un objet OSM.

Mais dans tous les cas, ça demande beaucoup de travail pour référencer des 
photos.

>   Pic4review me semble plus utile pour confirmer l’existence d'un objet ou 
> ses caractéristiques que pour l'ajout des photos.
Dire si un poteau incendie ou une borne de recharge est visible : OK.
Dire combien de véhicules on peut recharger c’est plus difficile (surtout que 
souvent, on ne voit rien).

> Mieux ne pas avoir une photo dans OSM qu'une photo qui n'a rien avoir avec 
> l’objet.
Oui :)

__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Bunkers

[Karel Adams]

excuus voor de mierenneukerij, maar het is relevant, denk ik:

s/abandonned/abandoned/g

;)


On 2020-03-17 16:15, Lionel Giard wrote:

For abandonned (historic) military bunker, the correct mapping is :
- abandonned:building=bunker
- military=bunker
- bunker_type=* (most of them are pillbox for those defensive belt 
around our big cities)

- historic=yes
...

So that you get all the information that it is no longer in use ! ^_^
Look on the wiki for more detailed tagging: 
https://wiki.openstreetmap.org/wiki/Tag:military%3Dbunker


Kind Regards,
Lionel

Le mar. 17 mars 2020 à 16:51, Marc M. > a écrit :


Hello,

Le 17.03.20 à 16:26, rodeo .be a écrit :
> I assume they were not visible because the tags were deprecated

military=bunker isn't deprecated, it's the correct tag for a bunker
still in military use.

I found at least one currently visible mapped with a node
https://www.openstreetmap.org/node/29049422
another mapped with an area https://www.openstreetmap.org/way/25586752

Regards,
Marc

___
Talk-be mailing list
Talk-be@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-be


___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Bunkers

[Marc M.]

Hello,

Le 17.03.20 à 16:26, rodeo .be a écrit :
> I assume they were not visible because the tags were deprecated

military=bunker isn't deprecated, it's the correct tag for a bunker
still in military use.

I found at least one currently visible mapped with a node
https://www.openstreetmap.org/node/29049422
another mapped with an area https://www.openstreetmap.org/way/25586752

Regards,
Marc

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Jmapb]

On 3/17/2020 10:52 AM, Wayne Emerson, Jr. via talk wrote:

However, among your examples you cite "gnis:feature_id=*" The wiki
page for this key notes:
"Unlike other imported tags such as gnis:created=* and
gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import.
In fact, some mappers actively add gnis:feature_id=* to features to
cite a verifiable source for the POI's existence or its name."


Agree with clemency for gnis:feature_id -- it's handy to be able to
crossreference features with the GNIS database, which you can search by
feature id here: https://geonames.usgs.gov/apex/f?p=138:1:0:

J


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

[OSM-talk-be] Bunkers

[rodeo .be]

Hey all,

I was driving around today, and saw some bunkers along the road that were
not visible on the map. But they were tagged on OSM ... already 11y ago
 ..

I assume they were not visible because the tags were deprecated. What are
the correct tags to give such a building? Are there other bunkers in
Belgium that were tagged 11y ago, but not visible because of "old tags"?

Kind regards
Maarten
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-fr] Connecteur type 2 compatible avec type E ??

[Yves P.]

Bonjour,

J'ai rajouté la borne de recharge 7302271646
 (photo sur Wikimedia Commons

).
Sur ses pages web, il est indiqué qu'il y a 2 prises type 2 (visibles sur
les photos) mais aussi 2 prises type E (que je ne vois pas).

Est-ce qu'on peut brancher un cordon secteur européen sur une prise type 2 ?

https://my.freshmile.com/charge/PAPE1
https://my.freshmile.com/charge/PAPE2

__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] Mappa diffusione CoVid-19

[Jeawrong]

Su FB ho trovato questa mappa interattiva [1], su una base OSM mostra i dati
del contagio in varie modalità, la trovo interessante.
Io non ne ho le capacità ma chi si diletta potrebbe riuscire a fare di
meglio, aggiungendo altri dati.

[1]  http://www.piersoft.it/covid19/?incidenza=0#6/41.838/13.881
  




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-es] Mapaton Humanitario 2020 - tarde del 21 de Abril

[Miguel Sevilla-Callejo]

Hola Carlos, Cómo van la Vida?
Nunca te respondi a esto y ahora limpiando correo te comento que visto cómo
están las cosas no se que pasará al respecto pero es.posible que no haya
mapaton nisiquiera cambio de fecha.
Habrá que olvidarse hasta 2021... si acaso.
Espero que estés bien.
Saludos desde Peñaflor.
Miguel

On Sat, 7 Mar 2020, 13:51 Carlos Guallart,  wrote:

> Hola, Miguel:
> si necesitas ayuda para la de Zaragoza (21 abril), creo que podré echarte
> una mano.
> Ya dirás
> Un abrazo
>
> El sáb., 7 mar. 2020 a las 13:12, Miguel Sevilla-Callejo (<
> msevill...@gmail.com>) escribió:
>
>> Hola a todos,
>>
>> Como ya he ido avisando por otros mensajes (disculpad la duplicidad) el
>> próximo 21 de abril vamos a promover desde Zaragoza y de la mano del
>> Colegio de Geógrafos y Cruz Roja la realización de un mapatón humanitario
>> coordinado, al modo de lo que hicimos el año pasado y en otras ocasiones
>> [1].
>>
>> Si alguien está interesado en unirse a alguna de las iniciativas que ya
>> están saliendo o ayudar en organizar un evento en su localidad que se ponga
>> en contacto conmigo para la coordinación.
>>
>> Un saludo
>>
>> Miguel
>>
>> [1] https://mapcolabora.org/project/mapaton-humanitario/
>>
>> --
>> *Miguel Sevilla-Callejo*
>> Doctor en Geografía
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
>
> --
> Carlos Guallart
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Greg Troxel]

I think it's reasonable to mark something as

  this was used by an import long ago, isn't used by mappers now, and
  the existence of it shouldn't be taken as a clue that it's current
  good practice

but I think this should also be done in a way that is not unkind to or
judgemental about long-ago importers.  That was a different time, with
different norms, and reasonable people were doing what they thought was
a good thing.  (In my view, mostly it was good, and the issues are
minor, but that's not really the point.)

So something like

  historical_import

to basically say "people used these tags in imports long ago, but there
is no present use, import or otherwise".




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

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Wayne Emerson, Jr. via talk]

Some other possible values:

undesirable
unnecessary
unwanted
unneeded
undiscussed
disapproved
clutter

However, among your examples you cite "gnis:feature_id=*" The wiki page 
for this key notes:
"Unlike other imported tags such as gnis:created=* and 
gnis:import_uuid=*, gnis:feature_id=* is meaningful beyond the import. 
In fact, some mappers actively add gnis:feature_id=* to features to cite 
a verifiable source for the POI's existence or its name."


But yes there are a lot of unnecessary gnis tags
gnis:County=*
gnis:County_num=*
gnis:ST_alpha=*
gnis:ST_num=*


On 3/17/2020 5:52 AM, Warin wrote:

On 17/3/20 8:22 pm, Marc M. wrote:

Hello Joseph,

it may give the impression that this is the way it should be done.
I agree to identify these "Noise" or poor quality tags, but with a
keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
it would be necessary to find a word that is not as strong as error,
but which nevertheless clearly indicates that this is not an example to
follow.



Agree with both.
Possible values?
obsolete
abandoned
discarded
  
archaic
passe
stale





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



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

Re: [Talk-GB] Ficticious embankments? Vandalism.

[ael]

On Tue, Mar 17, 2020 at 11:25:24AM +, Devonshire wrote:
> On Tue, Mar 17, 2020, at 2:08 AM, Warin wrote:
> > On 17/3/20 8:02 am, ael wrote:
> 
> The inability to mark an object's location as "authorititive" has always 
> seemed like a massive shortcoming of the project to me. Stopping people 
> re-aligning things based on a bad phone GPS or badly aligned aerial imagery 
> is impossible and even realising that things have been incorrectly moved is 
> random at best.

I agree entirely and have often wished for exactly that. I sometimes use
source=gps_surveys  (plural) to try to convey that this is not just one
random gps trace.

In this case, I just had source=gps_survey.

I too regret the awful smartphone (and satnav) gps traces which suggest
all gps is rubbish. I try not to upload any gps which is not reasonably
accurate. And add a note if the gps quality is poor when it still has
value, perhaps because there are no other traces in the area.

I suppose that we ought to start a discussion on the tagging list to
suggest
  source:accuracy = low|medium|high|differential
or some such.

ael


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] +++Nuovo modello autocertificazione (17/3/2020)+++

[Cascafico Giovanni]

Un bel form pdf online non sarebbe male: é piuttosto difficile scrivere il
comune di residenza in un centimetro.

Il mar 17 mar 2020, 12:23 Lorenzo Rolla  ha scritto:

> Magari a qualcuno interessa... Il link al modello non funziona. Buona
> giornata
>
> https://www.interno.gov.it/it/notizie/nuovo-modello-autodichiarazioni
> --
> Lorenzo Rolla
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] Ficticious embankments? Vandalism.

[ael]

On Tue, Mar 17, 2020 at 11:25:24AM +, Devonshire wrote:
> On Tue, Mar 17, 2020, at 2:08 AM, Warin wrote:
> > On 17/3/20 8:02 am, ael wrote:
> 
> The inability to mark an object's location as "authorititive" has always 
> seemed like a massive shortcoming of the project to me. Stopping people 
> re-aligning things based on a bad phone GPS or badly aligned aerial imagery 
> is impossible and even realising that things have been incorrectly moved is 
> random at best.

I agree entirely and have often wished for exactly that. I sometimes use
source=gps_surveys  (plural) to try to convey that this is not just one
random gps trace.

In this case, I just had source=gps_survey.

I too regret the awful smartphone (and satnav) gps traces which suggest
all gps is rubbish. I try not to upload any gps which is not reasonably
accurate. And add a note if the gps quality is poor when it still has
value, perhaps because there are no other traces in the area.

I suppose that we ought to start a discussion on the tagging list to
suggest
  source:accuracy = low|medium|high|differential
or some such.

ael


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Ficticious embankments? Vandalism.

[ael]

On Tue, Mar 17, 2020 at 01:08:52PM +1100, Warin wrote:
> On 17/3/20 8:02 am, ael wrote:
> > 
> > I have only just got around to looking in more detail, and discovered
> > that it is much worse than I had realised: vandalism.
> > 
> > I have taken waypoints on nearly all of the individual stones, and then
> > refined those positions with waypoint averaging on multiple visits.
> 
> 
> In cases like this I would use the source tag on the way so that others have 
> a very good chance of seeing it and respecting the previous work rather than 
> simply changing it to what they think it should be.

Indeed. I nearly always include a source tag for those sorts of reasons.
In this case the user did not just move the points, but deleted them,
source tag and all. So destroying the history.

> It is too easy to over look hard work that may have gone into establishing 
> data.
> A single GPS trace is fine if that is all there is, better to average many 
> GPS traces, in some locations I have 50+.

In this case, I used a "waypoint averaging" function on my Garmin. That
collects fixes over long periods and applies statistical algorithms to
refine the coordinates. And this can be done on many occasions to refine
the position even further. I had done this on many visits, and each 
averaging took considerable time. Often in pretty nasty weather.
So my coordinates should have been very accurate. Hence my anger that
they should have been deleted.

ael


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Ficticious embankments? Vandalism.

[ael]

On Tue, Mar 17, 2020 at 09:53:07AM +, John Aldridge wrote:
> On 17-Mar-20 02:08, Warin wrote:
> > A single GPS trace is fine if that is all there is, better to average many 
> > GPS traces, in some locations I have 50+.
> 
> Though, AIUI, once you've reached this level of precision, remaining errors
> are likely to be systematic (e.g. satellites in a particular direction being
> generally received via a -- delaying -- reflection rather than directly). No
> amount of averaging will help with that.

Well, the Garmin averaging goes some way to improve on that. That is one
of the reasons that waypoint averaging can be done over several visits:
it gives some sort of averaging over reflections, atmospheric changes
even satellite calibration.  Not up to professional differential GPS, of
course, but potentially accurate to maybe a meter. Certainly way better
then using imagery with the poor resolution, parallax errors and all the
rest, which is probably what the user used.

ael


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[European Water Project]

Salut Marc,

Par rapport à l’intérêt de mettre des photos des points d'eau, je donne
deux exemples. Je viens d'ajouter des photos pour presque toutes les
Fontaines Wallace à Paris.  Il y'en a 103 grandes fontaines Wallace, et il
n'en manque plus que quelques uns.   Nous avons des photos de quasi toutes
les fontaines de Zurich. J'ai écrit à Eau de Paris pour voir s'il voulait
travailler avec nous pour ajouter des photos de toutes les fontaines d'eau
potable qui ont une valeur artistique.

Voici une capture d'une fontaine  App :
https://drive.google.com/open?id=1aL_RGig-XMZrhc1Dg7J629hCfhc2sFJZ

Et un café :
https://drive.google.com/open?id=1uSBC_FoVgocrKQmBnPNlF8wRGTt4ay55

Il y a maintenant qq cafés avec le nouveau tag : drinking_water:refill dans
le sud de la France, en Angleterre et dans le Pays de Galles et  en
Allemagne,  Le workflow pour ajouter des images dans wikimedia commons et
d'ajouter le lien dans OSM me semble lourd.

Ce qui me dérange plus que la manque de bonnes photos dans OSM et le fait
que pic4review ajoute quasl-automatiquement des photos dans OSM qui n'ont
quasiment rien avec l'objet.  Pic4review me semble plus utile pour
confirmer l’existence d'un objet ou ses caractéristiques que pour l'ajout
des photos. Mieux ne pas avoir une photo dans OSM qu'une photo qui n'a rien
avoir avec l'objet. Au pire, mieux les lier à une relation qui décrit la
route.

Merci de le faire pour le fun si tu n'es pas convaincu ... time will tell
if are efforts are for naught !

Bien cordialement,

Stuart



On Tue, 17 Mar 2020 at 13:54, Marc M.  wrote:

> Bonjour,
>
> Le 17.03.20 à 13:02, European Water Project a écrit :
> > revoir le workflow et reflechir à des meilleurs outils pour ajouter
> > des images Mapillary, Wikimedia Commons, et OpenStreetCam dans OSM.
>
> je pense que le soucis est dans l’énoncé de départ :
> si les gens ne capturent pas des photos à la base pour les rajouter
> dans osm sur chaque object précisement, le résultat d'une utilisation de
> ceux-ci pour illustrer osm n'est pas terrible.
> je vais prendre mon exemple, ayant contribuer à ChargeMap.com et osm
> sur la thématique du mois :
> à quoi servent les photos dans ChargeMap ? selon moi principalement à :
> - compenser une position approximative (le contributeur renseigne
> l'adresse et valide, au lieu d'ajuster la position de la borne).
> cela se résoud en ajustant la position
> - compenser le manque de détail dans GM (par exemple absence des voies
> de déserte du parking). du coup le contributeur ajoute un "itinéraire
> photo" jusqu'à la borne. cela se résoud en ayant les voies de déserte
> dans osm.
> - lever le doute (quand on n'a pas une mémoire infaillible ou un doute
> sur le type de prise, une photo, et on (soit-même ou quelqu’un d'autre)
> verra cela plus tard. Pic4review ou autre convient bien pour cela.
> - quand on n'est intéressé que par un type d'info (par ex ajout de la
> borne) tout en voulant fournir aux autres contributeurs les photos
> de l'endroit s'ils ont envie de compléter. là aussi Picçreview convient
> bien.
> Du coup pour ma part, je n'ai pas besoin de lier une image à un objet
> osm : la photo de la borne n'est peut-être pas la plus adaptée pour
> celui qui veux connaître le nombre de place, ou le type de prise.
>
> ceci sans compter sur les problèmes de qualité de positionnement gps,
> direction et qualité de la photo (je parle de qualité technique :
> luminosité, horizon, netteté, résolution).
> C'est même selon moi le pire défaut du Mapilalry actuel :
> dans les zones bien couverte, il faudrait pouvoir marquer "série trop
> mauvaise, série mal géo-positionnée, ..." pour garder la qualité.
>
> Pour en revenir à ton projet, les gens vont-il utiliser moins de
> plastique si il y a une photo de qualité du point d'eau potable
> ou s'il y a 2x plus de point d'eau potable renseigné dans osm  ?
> Le temps humain est hélas limité.
> J'ajouterai volontiers quelques photos des points d'eau dans les
> environs, mais c'est pour le fun, je ne suis pas convaincu de l'impact.
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[Marc M.]

Bonjour,

Le 17.03.20 à 13:02, European Water Project a écrit :
> revoir le workflow et reflechir à des meilleurs outils pour ajouter
> des images Mapillary, Wikimedia Commons, et OpenStreetCam dans OSM.

je pense que le soucis est dans l’énoncé de départ :
si les gens ne capturent pas des photos à la base pour les rajouter
dans osm sur chaque object précisement, le résultat d'une utilisation de
ceux-ci pour illustrer osm n'est pas terrible.
je vais prendre mon exemple, ayant contribuer à ChargeMap.com et osm
sur la thématique du mois :
à quoi servent les photos dans ChargeMap ? selon moi principalement à :
- compenser une position approximative (le contributeur renseigne
l'adresse et valide, au lieu d'ajuster la position de la borne).
cela se résoud en ajustant la position
- compenser le manque de détail dans GM (par exemple absence des voies
de déserte du parking). du coup le contributeur ajoute un "itinéraire
photo" jusqu'à la borne. cela se résoud en ayant les voies de déserte
dans osm.
- lever le doute (quand on n'a pas une mémoire infaillible ou un doute
sur le type de prise, une photo, et on (soit-même ou quelqu’un d'autre)
verra cela plus tard. Pic4review ou autre convient bien pour cela.
- quand on n'est intéressé que par un type d'info (par ex ajout de la
borne) tout en voulant fournir aux autres contributeurs les photos
de l'endroit s'ils ont envie de compléter. là aussi Picçreview convient
bien.
Du coup pour ma part, je n'ai pas besoin de lier une image à un objet
osm : la photo de la borne n'est peut-être pas la plus adaptée pour
celui qui veux connaître le nombre de place, ou le type de prise.

ceci sans compter sur les problèmes de qualité de positionnement gps,
direction et qualité de la photo (je parle de qualité technique :
luminosité, horizon, netteté, résolution).
C'est même selon moi le pire défaut du Mapilalry actuel :
dans les zones bien couverte, il faudrait pouvoir marquer "série trop
mauvaise, série mal géo-positionnée, ..." pour garder la qualité.

Pour en revenir à ton projet, les gens vont-il utiliser moins de
plastique si il y a une photo de qualité du point d'eau potable
ou s'il y a 2x plus de point d'eau potable renseigné dans osm  ?
Le temps humain est hélas limité.
J'ajouterai volontiers quelques photos des points d'eau dans les
environs, mais c'est pour le fun, je ne suis pas convaincu de l'impact.

Cordialement,
Marc

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[European Water Project]

Bonjour,

Peut-être nous pouvons utiliser un peu de temps pendant ce confinement pour
revoir le workflow et reflechir à des meilleurs outils pour ajouter des
images Mapillary, Wikimedia Commons, et OpenStreetCam dans OSM.

Il me semble que peu des photos Mapillary dans OSM décrivent bien l'objet
auquel elles sont liées. En tout cas, c'est souvent le cas pour les photos
Mapillary des fontaines d'eau potable.

Est-ce qu’une image dans lequel on voit une borne toute petite en haut à
droite avec une mauvaise résolution devrait être ajouter dans OSM ? Je
pense que non.

Est-ce que nous pouvons rendre plus facile le workflow pour prendre des
photos avec un téléphone mobile et les ajouter automatiquement (ou presque)
dans OSM ? J'ai fait une demande pour une nouvelle fonctionnalité dans le
forum de Mapillary. J’ai reçu une réponse de Chris Beddow, qui me disait
qu’ils ont reçu plusieurs demandes semblables, mais pour l’instant ce n’est
pas une priorité commerciale.
https://forum.mapillary.com/t/trackable-photo-receipt-after-upload/3813

Notre projet est un peu gelé en ce moment avec le coronavirus mais pour la
phase 2 quand nous ajouterons plus de cafés, il me semble plus approprié de
stocker les photos de vitrines de cafés, restaurants, bars, etc. dans
Mapillary que Wikimedia Commons. Et pour l'instant, je ne vois pas un
workflow facile pour ajouter des images individuelles de qualité avec
Mapillary et de les ajouter dans OSM. Et par qualité, je parle d’être bien
centré avec une bonne lumière pas de haute densité.

Bien cordialement,

Stuart









On Tue, 17 Mar 2020 at 10:39, Marc M.  wrote:

> Le 17.03.20 à 08:09, Yves P. a écrit :
> > Un petit coeur est affiché sur les photos associées aux bornes.
> > Ça serait pratique de le faire en cliquant sur une icône.
> > Exemple : https://pic4review.pavie.info/#/mission/921/review
>
> le lien envoi vers la mission, du coup difficile de comprendre
> de quel exemple précis tu parles
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Ficticious embankments? Vandalism.

[Devonshire]

On Tue, Mar 17, 2020, at 2:08 AM, Warin wrote:
> On 17/3/20 8:02 am, ael wrote:
>> In cases like this I would use the source tag on the way so that others have 
>> a very good chance of seeing it and respecting the previous work rather than 
>> simply changing it to what they think it should be. It is too easy to over 
>> look hard work that may have gone into establishing data. A single GPS trace 
>> is fine if that is all there is, better to average many GPS traces, in some 
>> locations I have 50+.

What would you put in the source tag in this case and does it make a difference?

The inability to mark an object's location as "authorititive" has always seemed 
like a massive shortcoming of the project to me. Stopping people re-aligning 
things based on a bad phone GPS or badly aligned aerial imagery is impossible 
and even realising that things have been incorrectly moved is random at best.

Kevin



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-it] +++Nuovo modello autocertificazione (17/3/2020)+++

[Lorenzo Rolla]

Magari a qualcuno interessa... Il link al modello non funziona. Buona
giornata

https://www.interno.gov.it/it/notizie/nuovo-modello-autodichiarazioni
-- 
Lorenzo Rolla
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-se] Ska adresser ha land, stad, postnummer och allt?

[Daniel Lublin]

pang...@riseup.net , 2019-11-28 20:20:33 (+0100):
> Därutöver håller Lantmäteriet på att utreda hurvidare dem ska kunna frige
> den resterande data dem i dag säljer dvs laserdata, fastighetskartan och
> adressnoder samt underlag som flygbilder och stereofoton.
> 
> Utredningen måste vara klar d. 17/1 och då kommer jag dela den här.

Hur gick det med den?

--
Daniel
lublin.se

___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-it] access=permit

[Martin Koppenhoefer]

aggiungerei un'altra osservazione: access=permit si riferisce a tutti i
mezzi, mentre per situazioni dove L'ingresso con la macchina al centro
storico è limitato a residenti (e forse ospiti di alberghi, altri
autorizzati, ecc.), e dove forse *=permit potrebbe avere senso
(generalmente sarebbe comunque "private" in questo caso, "permit" significa
che il permesso va chiesto ma lo può ottenere chiunque, se ricordo bene),
in questi casi la chiave non sarebbe "access", ma "motor_vehicle" oppure
"motorcar".

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] access=permit

[Martin Koppenhoefer]

Am Mo., 16. März 2020 um 19:04 Uhr schrieb Marcello :

> Considerando che le strade inserite mi sembrano assolutamente normali e
> che sono state inserite al primo o ai primi edit mi viene il sospetto
> che chi lo ha aggiunto lo abbia voluto usare per specificare che
> l'accesso è permesso (access=yes), probabilmente tratto in inganno dal
> preset di iD, che elenca solo le restrizioni. La proposta è di agosto
> 2016, guardando in tagInfo gli access=permit sono 14073, mi sembrano
> veramente molti per una proposta abbastanza recente e così specifica,
> sospetto che molti siano tratti in inganno. Cosa si può fare?



Tema un po' difficile. Se la cause è una traduzione in italiana, sarebbe da
fissare lì, se invece occorre anche in altre lingue, potresti cercare di
sollevare il problema con gli sviluppartori e vedere se sono disponibili a
fissare il problema. Altrimentri potresti aggiungere la cosa nella lunga
lista di problemi con iD:
https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions

per segnalare problemi: https://github.com/openstreetmap/iD

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Colin Smale]

"unmaintained"? 

On 17 March 2020 10:52:39 CET, Warin <61sundow...@gmail.com> wrote:
>On 17/3/20 8:22 pm, Marc M. wrote:
>> Hello Joseph,
>>
>> it may give the impression that this is the way it should be done.
>> I agree to identify these "Noise" or poor quality tags, but with a
>> keyword to show that it's a problem. e.g. status=bad, disputed,
>error, ...
>> it would be necessary to find a word that is not as strong as error,
>> but which nevertheless clearly indicates that this is not an example
>to
>> follow.
>>
>
>Agree with both.
>
>Possible values?
>
>obsolete
>
>abandoned
>
>discarded
>
>
>
>archaic
>
>passe
>
>stale
>
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Warin]

The one I am thinking of comes from HOT activity. There is no link to an 
import proposal, they just use 'any tag they like' .. and leave it there 
undocumented.


On 17/3/20 8:59 pm, François Lacombe wrote:

Hi all

My 2cts : "in use" status and statuslink to the import proposal would 
be enough, right?
Point is to determine where does the tag come from, and it's done by 
statuslink, not status which reflect the current state of use.


All the best

François

Le mar. 17 mars 2020 à 10:55, Warin <61sundow...@gmail.com 
> a écrit :


On 17/3/20 8:22 pm, Marc M. wrote:

Hello Joseph,

it may give the impression that this is the way it should be done.
I agree to identify these "Noise" or poor quality tags, but with a
keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
it would be necessary to find a word that is not as strong as error,
but which nevertheless clearly indicates that this is not an example to
follow.



Agree with both.

Possible values?

obsolete

abandoned

discarded

  

archaic

passe

stale



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

Re: [Talk-GB] Ficticious embankments? Vandalism.

[Warin]

On 17/3/20 8:53 pm, John Aldridge wrote:

On 17-Mar-20 02:08, Warin wrote:
A single GPS trace is fine if that is all there is, better to average 
many GPS traces, in some locations I have 50+.


Though, AIUI, once you've reached this level of precision, remaining 
errors are likely to be systematic (e.g. satellites in a particular 
direction being generally received via a -- delaying -- reflection 
rather than directly). No amount of averaging will help with that.



Yes, a source of error. When placed over some reasonable imagery any 
discrepancies can be seen, evaluated and if necessary compensated for. 
However most users will not be aware of the discrepancy as they would be 
using another GPS to 'see' it.


If the GPS tracks are separated by days, weeks and months then the 
satellites will have changed, and the satellite positions too. Usually 
there will be 'outliers' that are more than 2 standard deviations from 
the average. It is valid to delete these from computations.


I don't bother with the calculations and do it by eye, more satisfying 
than loading it all into a program, taking the result and entering it. 
And I like to see the raw data anyway.



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-gb-westmidlands] Meetings

[Brian Prangle]

I think we'll have to cancel our monthly meetings until further notice @Ian
I hope your rail trip is not too chaotic

Regards

Brian
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[François Lacombe]

Hi all

My 2cts : "in use" status and statuslink to the import proposal would be
enough, right?
Point is to determine where does the tag come from, and it's done by
statuslink, not status which reflect the current state of use.

All the best

François

Le mar. 17 mars 2020 à 10:55, Warin <61sundow...@gmail.com> a écrit :

> On 17/3/20 8:22 pm, Marc M. wrote:
>
> Hello Joseph,
>
> it may give the impression that this is the way it should be done.
> I agree to identify these "Noise" or poor quality tags, but with a
> keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
> it would be necessary to find a word that is not as strong as error,
> but which nevertheless clearly indicates that this is not an example to
> follow.
>
>
>
> Agree with both.
>
> Possible values?
>
> obsolete
>
> abandoned
>
> discarded
>
>  
>
> archaic
>
> passe
>
> stale
>
>
>
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Warin]

On 17/3/20 8:22 pm, Marc M. wrote:

Hello Joseph,

it may give the impression that this is the way it should be done.
I agree to identify these "Noise" or poor quality tags, but with a
keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
it would be necessary to find a word that is not as strong as error,
but which nevertheless clearly indicates that this is not an example to
follow.



Agree with both.

Possible values?

obsolete

abandoned

discarded

 

archaic

passe

stale




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

Re: [Talk-GB] Ficticious embankments? Vandalism.

[John Aldridge]

On 17-Mar-20 02:08, Warin wrote:

A single GPS trace is fine if that is all there is, better to average many GPS 
traces, in some locations I have 50+.


Though, AIUI, once you've reached this level of precision, remaining 
errors are likely to be systematic (e.g. satellites in a particular 
direction being generally received via a -- delaying -- reflection 
rather than directly). No amount of averaging will help with that.


John

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Projet du mois de mars - Pic4Review

[Marc M.]

Le 17.03.20 à 08:09, Yves P. a écrit :
> Un petit coeur est affiché sur les photos associées aux bornes.
> Ça serait pratique de le faire en cliquant sur une icône.
> Exemple : https://pic4review.pavie.info/#/mission/921/review

le lien envoi vers la mission, du coup difficile de comprendre
de quel exemple précis tu parles

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Marc M.]

Hello Joseph,

it may give the impression that this is the way it should be done.
I agree to identify these "Noise" or poor quality tags, but with a
keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
it would be necessary to find a word that is not as strong as error,
but which nevertheless clearly indicates that this is not an example to
follow.

Regards,
Marc

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

[OSM-talk] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[Joseph Eisenberg]

I would like to add a new status to
https://wiki.openstreetmap.org/wiki/Approval_status and to Tag and Key
pages in the wiki

The value "import" would be used for tags that were used in a large
import, but are no longer commonly being added.

These tags often have high numbers in the database but have not been
accepted by the community and rarely are being used by mappers (in
some cases they have never been added, except by the import), so they
should not have the status "in use", and they were never proposed in
most cases.

Using "import" as the status would make it clear that these tags are
not "de facto", "in use" or "approved", and would be more specific and
clear than "unspecified".

Examples:
https://wiki.openstreetmap.org/wiki/Key:tiger (tiger:county=*,
tiger:tlid=* and tiger:upload_uuid=* etc)
https://wiki.openstreetmap.org/wiki/Key:gnis:feature_id
https://wiki.openstreetmap.org/wiki/Item:Q1607 - nhd-shp:fdate
https://wiki.openstreetmap.org/wiki/Item:Q1606 - nhd-shp:fcode

-- Joseph Eisenberg

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

Re: [OSM-talk-fr] Osmose, voirie non connectée

[Stéphane Péneau]

Bonjour Jocelyn,

Je ne sais pas si c'est le même problème que le ticket que tu as créé, 
mais ici aussi j'ai corrigé l'erreur il y a 10 jours :

http://osmose.openstreetmap.fr/fr/error/daed4c07-1737-313c-98c2-816a2d1e5e1b

Stf

Le 16/03/2020 à 22:35, Jocelyn Jaubert a écrit :

Bonjour,

Le 16/03/2020 à 12:02, Stéphane Péneau a écrit :

J'ai l'impression que la BDD utilisée par Osmose cafouille un peu car je
vois des erreurs sur des choses que j'ai corrigées il y a presque 10 jours.

exemple :
http://osmose.openstreetmap.fr/fr/error/ba1e3dcb-6631-70b3-b2d1-30ca256913e2


le tag amenity = bus_station a été enlevé le 7 mars.

Merci pour avoir donné cette exemple précis.

J'ai ouvert un ticket sur le frontend, pour qu'on étudie le souci plus
précisément:

https://github.com/osm-fr/osmose-frontend/issues/225




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Projet du mois de mars - Pic4Review

[Yves P.]

> Et comme pour chaque mission, nous pouvons nous appuyer sur ces précieux 
> outils : MapContrib 
> ,
>  MapRoulette , Mapillary, 
> Pic4Review , NotesReview 
> ,
>  etc.
> 
Un petit essai avec Pic4Review :
Un petit coeur est affiché sur les photos associées aux bornes.
Ça serait pratique de le faire en cliquant sur une icône.
Exemple : https://pic4review.pavie.info/#/mission/921/review

Est-ce que les photos wikimedia commons associées sont affichées ?

J’ai rajouté des bornes de recharge ces derniers jours.
Je ne les vois pas sur la carte de Pic4Review : il n’y a pas de mise à jour de 
la requête overpass ?


—
Yves

Sinon, c’est assez difficile de se repérer sur les vues à 360°.
J’ai fini par trouver le lien pour voir la photo directement sur Mapillary. 
L’icône me semble trompeur : il me fait plutôt penser au bouton pour me 
géolocaliser.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr