[OSM-talk-fr] Pas de cadastre ce matin

[Yves P.]

Bonjour,

Le serveur https://tms.cadastre.openstreetmap.fr/*/tout/17/67603/46680.png ne 
répond plus.

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

Re: [Talk-it] facebook compra mapillary

[Manuel]

Se l'idea è quella di "riversare" le immagini di Mapillary su Commons, meglio 
evitare: rischierebbero probabilmente di essere cancellate (nella fattispecie 
c'è la linea guida 
https://commons.m.wikimedia.org/wiki/Special:MyLanguage/Commons:Project_scope/Summary,
 in particolare la sezione  "Must be realistically useful for an educational 
purpose"

⁣Manuel Tassi

Ottieni BlueMail per Android ​

Il giorno 19 giu 2020, 07:43, alle ore 07:43, Andrea Mazzoleni 
 ha scritto:
>C'è un posto consigliato dove mettere le foto da utilizzare in
>openstreetmap ? Che ne dite di Wikimedia commons ?
>
>Ciao,
>Andrea
>
>
>On Fri, Jun 19, 2020 at 1:24 AM Luca Delucchi 
>wrote:
>
>> On Thu, 18 Jun 2020 at 23:06, Martin Koppenhoefer
>>  wrote:
>> >
>> > la fonte:
>>
>https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html
>>
>> leggendo qui però non sembrerebbe male, ora si possono usare anche
>per
>> scopi commerciali (questo non toglie che una bella copia delle foto
>se
>> ci tenete le farei in qualsiasi caso)
>> Alla fine si lasciavano comunque ad un privato che poteva fare ciò
>che
>> voleva, ovviamente ora si è saliti di livello
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>>
>> ___
>> 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
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] facebook compra mapillary

[Andrea Mazzoleni]

C'è un posto consigliato dove mettere le foto da utilizzare in
openstreetmap ? Che ne dite di Wikimedia commons ?

Ciao,
Andrea


On Fri, Jun 19, 2020 at 1:24 AM Luca Delucchi  wrote:

> On Thu, 18 Jun 2020 at 23:06, Martin Koppenhoefer
>  wrote:
> >
> > la fonte:
> https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html
>
> leggendo qui però non sembrerebbe male, ora si possono usare anche per
> scopi commerciali (questo non toglie che una bella copia delle foto se
> ci tenete le farei in qualsiasi caso)
> Alla fine si lasciavano comunque ad un privato che poteva fare ciò che
> voleva, ovviamente ora si è saliti di livello
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
> ___
> 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-de] Fwd: [OSM-talk] Facebook kauft Crowdsourced Mapping Firma Mapillary

[Markus]

Danke Michael für diese Katastrophenmeldung...

Ist die OSMF oder sonstwer dabei, eine Alternative zu schaffen?

Was gibt es sonst noch für Ideen?

Mit herzlichem Gruss,
Markus

PS: wenn ein Proprietärer einen freien Dienst kauft:
- wie geht das?
- wer bekommt die Kohle?
- kann OSM auch gekauft werden?

Hier ein Text in deutsch:
https://www.googlewatchblog.de/2020/06/google-maps-streetview-konkurrenz/



Am 19.06.2020 um 01:13 schrieb Michael Kugelmann:
> FYI. (auch wenn die Seite auf Englisch ist)
>
>
>  Weitergeleitete Nachricht 
> Betreff: [OSM-talk] Facebook acquires crowdsourced mapping company
> Mapillary
> Datum: Thu, 18 Jun 2020 22:32:42 +
> Von: Sérgio V. 
> An: talk...@openstreetmap.org ,
> t...@openstreetmap.org 
>
>
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs

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

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[andreas wecer]

Am Do., 18. Juni 2020 um 23:52 Uhr schrieb Friedrich Volkmann :

> Eine Alternative zu Nominatim würden sicher viele begrüßen.
>

Photon, der Geocoder von komoot, funktioniert damit übrigens anscheinend
problemlos, auch wenn der auch auf Nominatim-Daten aufbaut.
Wobei auf der Demoseite photon.komoot.de der gleiche Fehler auftaucht, auf
www.komoot.de dagegen nicht mehr und dort wird nicht nur die falsche
Schelleingasse 8 herausgefiltert, sondern auch die korrekte
Alois-Drasche-Park 8 gefunden.

https://github.com/komoot/photon
https://www.komoot.de/plan/tour/d11At9JDwD54Cw=FuYABMoBI2A=/@48.1865220,16.3714850,17z
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] Fwd: Zustellort NEU in Österreich

[Johann Haag]

Ich gehe davon aus, dass hier auch BEV Leute mitlesen.
Es werden vom BEV gerade in Österreich Namen für Zustellorte definiert. Da
und dort sind solche zur eindeutigen Unterscheidung sinnvoll. Warum kürzt
man aber im BEV Entwurf, auch Gemeindenamen ab, wo slche bereits eindeutig
sind.
Der Versuch auf Leerzeichen zu verzichten kann es nicht sein, da in den
neuen Abkürzungen solche weiter vorkommen. Auch kann es eine Beschränkung
der maximale Zeichenzahl nicht sein, da auch bereits kurze Gemeindenamen im
Entwurf weiter verkürzt werden.

Etwas ratlos,
Johann Haag


-- Forwarded message -
Von: Johann Haag 
Date: Mo., 15. Juni 2020 um 09:51 Uhr
Subject: Zustellort NEU in Österreich
To: OpenStreetMap AT 


In Österreich wird gerade das Gewerberegister überarbeitet. Dazu
beschäftigt man sich aktuell mit der Festlegung, der Begrifflichkeit
Zustellort.
Die Frage ist nun, ob wir diesen in OpenStreetMap erfassen können.
Details hierzu auch in meinem Weblink Verzeichnis, addresshistory.hxg.at

https://drive.google.com/drive/folders/1dntYbApmC7rvc3vaVrCZMHpJVp89tXgh?usp=sharing
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSRM-talk] take only distance from route

[Nikhil VJ]

Hi Luiz,

Pls provide the exact structure of the API call you are making. There may
be some problems in that. One commonly repeating mistake is that people put
latitude first while OSRM needs longitude first.

Documentation : http://project-osrm.org/docs/v5.5.1/api/

And you will get the distance as part of the whole json response. Then you
have to use your code to extract the distance from that json. If you don't
know how to work with json, just lookup online; it's very easy. You can
paste your response into a "json beautifier" like tool to see the structure
in more familiar ways.

--
Cheers,
Nikhil VJ
https://nikhilvj.co.in


On Fri, Jun 19, 2020 at 7:04 AM Luiz Claudio de Paula Costa <
luiz.netw...@gmail.com> wrote:

> Can any help me? I need take only distance from route, I am a newby and
> I'm not getting process the json return to extract the distance.
> thanks any help
> luiz from brasil
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [talk-au] How to tag plantations?

[Andrew Harvey]

Yeah exactly, I agree with this. An area used for forestry ie. to produce
timber, would still have natural=wood if there are trees there.

On Fri, 19 Jun 2020 at 11:00, Warin <61sundow...@gmail.com> wrote:

> On 18/6/20 6:48 pm, Little Maps wrote:
>
> Many thanks Warin, that seems much more variable in Vic, esp in Gippsland 
> where natural=wood is a common tag for areas tagged as State Forests. 
> Plantations in SW Vic are quite a mix. I wonder if it’s worth adding a 
> section to the Aus tagging guidelines page to specify a preferred usage for 
> landuse=forest and natural=wood, and perhaps other vegetation tags? I’d be 
> happy to draft some text if more seasoned mappers were happy to comment and 
> edit it. Thanks again Ian
>
>
> Tread here carefully Little Maps!
>
>
> I would like to see the following use:
>
> natural=wood for areas of trees. Note the key 'natural' applies to both 
> natural and man altered areas.
>
> landuse=forest for areas that are maintained by humans to obtain tree produce 
> e.g. timber. Note these areas usually have trees, but after harvest may have 
> no trees.
>
> Note there may be some who disagree with this, see 
> https://wiki.openstreetmap.org/wiki/Forest.
>
> I would be interested to here of any Australians who disagree with the above, 
> and why they disagree.
>
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] How to tag plantations?

[cleary]

I agree with Warin.

On Fri, 19 Jun 2020, at 12:58 AM, Warin wrote:
> On 18/6/20 6:48 pm, Little Maps wrote:
> > Many thanks Warin, that seems much more variable in Vic, esp in Gippsland 
> > where natural=wood is a common tag for areas tagged as State Forests. 
> > Plantations in SW Vic are quite a mix. I wonder if it’s worth adding a 
> > section to the Aus tagging guidelines page to specify a preferred usage for 
> > landuse=forest and natural=wood, and perhaps other vegetation tags? I’d be 
> > happy to draft some text if more seasoned mappers were happy to comment and 
> > edit it. Thanks again Ian 
> 
> 
> Tread here carefully Little Maps! 
> 
> 
> I would like to see the following use: natural=wood for areas of trees. 
> Note the key 'natural' applies to both natural and man altered areas. 
> landuse=forest for areas that are maintained by humans to obtain tree 
> produce e.g. timber. Note these areas usually have trees, but after 
> harvest may have no trees. 
> Note there may be some who disagree with this, see 
> https://wiki.openstreetmap.org/wiki/Forest. I would be interested to 
> here of any Australians who disagree with the above, and why they 
> disagree. 
> 
> 
> 
> 
> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

[OSRM-talk] take only distance from route

[Luiz Claudio de Paula Costa]

Can any help me? I need take only distance from route, I am a newby and I'm
not getting process the json return to extract the distance.
thanks any help
luiz from brasil
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [talk-au] How to tag plantations?

[Warin]

On 18/6/20 6:48 pm, Little Maps wrote:

Many thanks Warin, that seems much more variable in Vic, esp in Gippsland where 
natural=wood is a common tag for areas tagged as State Forests. Plantations in 
SW Vic are quite a mix. I wonder if it’s worth adding a section to the Aus 
tagging guidelines page to specify a preferred usage for landuse=forest and 
natural=wood, and perhaps other vegetation tags? I’d be happy to draft some 
text if more seasoned mappers were happy to comment and edit it. Thanks again 
Ian



Tread here carefully Little Maps!


I would like to see the following use:

natural=wood for areas of trees. Note the key 'natural' applies to both natural 
and man altered areas.

landuse=forest for areas that are maintained by humans to obtain tree produce 
e.g. timber. Note these areas usually have trees, but after harvest may have no 
trees.

Note there may be some who disagree with this, see 
https://wiki.openstreetmap.org/wiki/Forest.

I would be interested to here of any Australians who disagree with the above, 
and why they disagree.




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

Re: [OSM-talk-fr] Fontaine fleurie

[Philippe Verdy]

Le jeu. 18 juin 2020 à 13:57, Yves P.  a écrit :

> Je dirai ...  abandoned:amenity
> =fountain
> 
> .  qui n'empêche pas quelqu'un qui veut rendre des fontaines ornementales
> sur une carte .
>
> abandoned:*=* ou disused:*=* ou something_else:*=* empêche le rendu.
>

C'est justement ce qu'il faut: ne pas faire un rendu comme une vraie
fontaine. Là ce qui est désigné c'est juste un support ce n'est plus une
fontaine du tout.

En revanche on peut taguer cela comme un VRAI bac à fleur (peu importe sa
forme).

Si on tient à indiquer la forme, les tags "was:*" ou "disused:" peuvent
convenir bien que cela ne désigne pas vraiment la forme mais l'ancienne
fonction (car les vraies fontaines peuvent ne pas avoir l'apparence d'une
fontaine, une fontaine peut être installée dans un autre objet, une statue
par exemple, sans aucun mobilier apparent: l'eau coule ou ne coule pas
c'est tout; les plus modernes pourraient avoir un capteur de présence pour
ne pas couler en permanence ou seulement à certains horaires et certaines
conditions de température si c'est automatisé; l'ancienne poignée ou
l'ancien bouton peut être encore là mais conservé juste de façon décorative
alors que l'actionnement utilise tout autre chose)

Le tag fontaine n'indique que la fonction/l'usage, pas la forme. Donc
"disused:" convient tout à fait pour une ancienne fontaine transformée ou
conservée juste pour sa forme décorative ou artistique ou comme support
pour autre chose.

C'est en fait comme pour les bâtiments: on tague séparément la forme
architecturale (maison, grange, hangar, église, château, moulin, tour,
etc.) et l'usage (résidence, commerce, industrie, artisanat, service,
garage, stockage, abri, discothèque, bar, restaurant...).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[James]

Openstreetcam was transferred to grab taxi, images have stopped processing
and devs say they are working on back end but project seems dead

On Thu., Jun. 18, 2020, 7:27 p.m. Paul Johnson,  wrote:

> Doesn't OpenStreetCam have similar corporate ownership problems, with the
> additional problematic aspect that the toolchain's been neglected since
> Telenav cut 'em loose?
>
> On Thu, Jun 18, 2020 at 6:23 PM Niels Elgaard Larsen 
> wrote:
>
>> Paul Johnson:
>> > Great.  How's this affect those of us who trust Facebook about as far
>> as we can throw it?
>>
>>
>> Use openstreetcam
>>
>>
>> Start downloading all you images from Mapillary, if you did not keep a
>> copy-
>>
>>
>> But I think most important, use existing Mapillary photos to improve OSM
>> with speed
>> limits, surfaces, lit, etc.
>>
>>
>>
>>
>> >
>> > On Thu, Jun 18, 2020 at 5:37 PM Sérgio V. > > > wrote:
>> >
>> >
>> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
>> >
>> >
>> > - - - - - - - - - - - - - - - -
>> >
>> > Sérgio - http://www.openstreetmap.org/user/smaprs
>> >
>> > ___
>> > talk mailing list
>> > talk@openstreetmap.org 
>> > https://lists.openstreetmap.org/listinfo/talk
>> >
>> >
>> > ___
>> > talk mailing list
>> > talk@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk
>> >
>>
>>
>> --
>> Niels Elgaard Larsen
>>
>> ___
>> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Andrew Harvey]

+ Jan's diary post https://www.openstreetmap.org/user/jesolem/diary/393358

On Fri, 19 Jun 2020 at 09:22, Shaun McDonald 
wrote:

> Thanks for the heads up.
>
> They’ve also posted a blog post about it:
> https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html
>
> Supposedly no change from a mapping perspective. Commercial use now
> allowed for free.
>
> Shaun
>
> On 18 Jun 2020, at 23:32, Sérgio V.  wrote:
>
>
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
>
>
> - - - - - - - - - - - - - - - -
> Sérgio - http://www.openstreetmap.org/user/smaprs
> ___
> 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 mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Paul Johnson]

Doesn't OpenStreetCam have similar corporate ownership problems, with the
additional problematic aspect that the toolchain's been neglected since
Telenav cut 'em loose?

On Thu, Jun 18, 2020 at 6:23 PM Niels Elgaard Larsen 
wrote:

> Paul Johnson:
> > Great.  How's this affect those of us who trust Facebook about as far as
> we can throw it?
>
>
> Use openstreetcam
>
>
> Start downloading all you images from Mapillary, if you did not keep a
> copy-
>
>
> But I think most important, use existing Mapillary photos to improve OSM
> with speed
> limits, surfaces, lit, etc.
>
>
>
>
> >
> > On Thu, Jun 18, 2020 at 5:37 PM Sérgio V.  > > wrote:
> >
> >
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
> >
> >
> > - - - - - - - - - - - - - - - -
> >
> > Sérgio - http://www.openstreetmap.org/user/smaprs
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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-it] facebook compra mapillary

[Luca Delucchi]

On Thu, 18 Jun 2020 at 23:06, Martin Koppenhoefer
 wrote:
>
> la fonte: 
> https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html

leggendo qui però non sembrerebbe male, ora si possono usare anche per
scopi commerciali (questo non toglie che una bella copia delle foto se
ci tenete le farei in qualsiasi caso)
Alla fine si lasciavano comunque ad un privato che poteva fare ciò che
voleva, ovviamente ora si è saliti di livello

-- 
ciao
Luca

www.lucadelu.org

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Niels Elgaard Larsen]

Paul Johnson:
> Great.  How's this affect those of us who trust Facebook about as far as we 
> can throw it?


Use openstreetcam


Start downloading all you images from Mapillary, if you did not keep a copy-


But I think most important, use existing Mapillary photos to improve OSM with 
speed
limits, surfaces, lit, etc.




> 
> On Thu, Jun 18, 2020 at 5:37 PM Sérgio V.  > wrote:
> 
> 
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
> 
> 
> - - - - - - - - - - - - - - - -
> 
> Sérgio - http://www.openstreetmap.org/user/smaprs
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


-- 
Niels Elgaard Larsen

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Shaun McDonald]

Thanks for the heads up.

They’ve also posted a blog post about it: 
https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html 


Supposedly no change from a mapping perspective. Commercial use now allowed for 
free.

Shaun

> On 18 Jun 2020, at 23:32, Sérgio V.  wrote:
> 
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
>  
> 
> 
> 
> - - - - - - - - - - - - - - - -
> Sérgio - http://www.openstreetmap.org/user/smaprs 
> ___
> 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-de] Fwd: [OSM-talk] Facebook kauft Crowdsourced Mapping Firma Mapillary

[Michael Kugelmann]

FYI. (auch wenn die Seite auf Englisch ist)


 Weitergeleitete Nachricht 
Betreff:[OSM-talk] Facebook acquires crowdsourced mapping company
Mapillary
Datum:  Thu, 18 Jun 2020 22:32:42 +
Von:Sérgio V. 
An: talk...@openstreetmap.org ,
t...@openstreetmap.org 



https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Jeff McKenna]

Thanks for sharing this Sérgio.

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-06-18 7:32 p.m., Sérgio V. wrote:

https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


_



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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Paul Johnson]

Great.  How's this affect those of us who trust Facebook about as far as we
can throw it?

On Thu, Jun 18, 2020 at 5:37 PM Sérgio V.  wrote:

>
> https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Sérgio V .]

https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-br] Facebook acquires crowdsourced mapping company Mapillary

[Sérgio V .]

https://uk.reuters.com/article/us-facebook-deals-mapillary/facebook-acquires-crowdsourced-mapping-company-mapillary-idUKKBN23P3N6



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-it] [Osm] Fwd: importazione dati in OpenStreetMap

[Martin Koppenhoefer]

sent from a phone

> On 18. Jun 2020, at 06:35, Luca Delucchi  wrote:
> 
>> Al tempo non mi stupirebbe sapere che i dati sbagliati hanno mobilitato le 
>> persone
>> 
> 
> neanche tanto guardate questa presentazione del 2011
> https://www.slideshare.net/mvexel/insert-coin-to-play


infatti, i dati sbagliati sono veleno per attirare persone. Se ci sono dei 
buchi visibili in una mappa fatta dal basso, tutti possono capirne il motivo, e 
magari qualcuno si sente chiamato a dare una mano nella zona sua 
(particolarmente motivante per tante persone sono situazioni dove nel tuo 
villaggio c’è ben poco mentre in quello vicino è mappato tutto benissimo).

Invece se la mappa è piena, ma anche piena di errori, è un motivo per girarsi e 
non tornare mai più.

Anche dal punto di vista pratico: se la mappa è vuota lo sai che non sai, 
mentre con la mappa piena ti fidi e ti devi poter fidare. Un errore spesso è 
più grave rispetto ad una mancanza.

Cosa sembra più accattivante, fare l’esploratore o la pulizia stradale?

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

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[Friedrich Volkmann]

On 18.06.20 12:28, Florian Ledermann wrote:
hat einer für euch eine Erklärung, warum eine Suche bei Nominatim nach 
"Schelleingasse 8" als erstes Ergebnis die Node "Alois-Drasche-Park 8" liefert?


Weil Nominatim nicht für Adresssuche konzipiert ist. Es ignoriert alle 
addr:* Tags mit Ausnahme der Hausnummer (und soweit ich weiß addr:place).


Auffällig ist allerdings noch, dass 
Adress-Nodes im Alois-Drasche-Park von Nominatim anscheinend generell nicht 
gefunden werden (z.B. 
https://nominatim.openstreetmap.org/search.php?q=Alois-Drasche-Park+8 ) - 
keine Ahnung ob das etwas damit zu tun hat...


Im vorigen Beispiel hat es diesen Node aber gefunden (wo es falsch war).
Dem Draschepark hingegen ordnet Nominatim keine außerhalb befindlichen Nodes 
zu, da er kein highway ist.



Ich würde gerne das Tagging verbessern


Falscher Ansatz, denn der Fehler liegt nicht im Tagging, sondern in 
Nominatim. Verbessern müsstest du also Nominatim, oder einfacher ganz neu 
schreiben.


Eine Alternative zu Nominatim würden sicher viele begrüßen. Nominatim ist 
auf schnelle Aktualisierung optimiert, nicht auf Korrektheit der Ergebnisse. 
Normalerweise will man das Gegenteil. Ob die Daten minutenaktuell sind oder 
von voriger Woche, interessiert selten wen. Ich habe in meinem Auto noch ein 
Navi aus 2010 und finde trotzdem überall hin.


Ganz nützlich wär vor allem eine API, in der man nach 
Ort/Straße/Hausnr/PLZ/Firmenname usw. in separaten Feldern (CGI-Parametern) 
suchen kann. Nominatim unterscheidet das alles nicht. Ob du nach 1040 Wien 
Alois-Drasche-Park 8 oder nach Wien 8 Alois-Drasche-Park 1040 suchst, ist 
Nominatim egal. Das ist so, wie wenn du von einem davonfahrenden Bankräuber 
die Autonummer W729476 notierst und sie einem Polizisten gibst, und der 
schreibt zur Fahndung aus: "Kennzeichen mit einem 2er, einem 4er, einem 6er, 
2 7ern, einem 9er und einem W"


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

Re: [Talk-it] [Osm] Fwd: importazione dati in OpenStreetMap

[Martin Koppenhoefer]

sent from a phone

> On 18. Jun 2020, at 06:21, Luca Delucchi  wrote:
> 
> il fondatore di OSM negli ultimi anni non ha sempre detto cose
> condivise da tutti


e questa frase è ancora molto educata ;-)


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

[Talk-GB] SoTM 2020 Online Lightning Talks

[Jez Nicholson]

With this year's State of the Map conference going online there is more
opportunity to get involved than usual.

One thing is the
https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/registration_lightning_talks
Lightning Talks. Anyone can submit a 5-min video and 15 will be featured in
the conference programme. Deadline 28 June.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[talk-cz] Hradlove Strimelice u Sazavy: zmena v turistickych znackach

[Pavel Machek]

Ahoj!

Hradlove Strimelice u Sazavy: Zda se ze z modre je zelena, nebo tak
neco. Jestli ma nekdo cestu okolo...

Mejte se,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: PGP signature
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[Andreas]

Am 18.06.20 um 21:49 schrieb Johann Haag:

> Wenn etwas wie Nominatim derart nachhaltig nicht funktioniert, so kannst
> Du mit Gewissheit davon ausgehen, dass ein solches Verhalten bewusst
> herbeigeführt ist, unser OpenSource Projekt simpel nicht als
> Produktivsystem geeignet sein soll.

Musste die Verschwörungstheorie-Keule jetzt wirklich ausgepackt werden?

Auch kommerzielle Anbieter haben oft Probleme mit ihren Suchalgorithmen,
daher finde es sehr interessant hier gleich auf eine bewusste
Verfälschung des Suchergebnisses zu setzen.

Und wenn wirklich die Ursache für das Problem nicht gefunden werden
kann, kann man einen Issue auf der Projektseite auf github
(https://github.com/osm-search/Nominatim/issues) erstellen.

Wir sind eine Community und es gibt hier keine Elite. Es gibt vielleicht
erfahrenere Mapper und OSM Entwickler, aber das ist ja das schöne an dem
Projekt. Es können Menschen mit den unterschiedlichsten Wissensständen
sich miteinander austauschen und so OSM verbessern.

> Sowas nennt man Politik.
> Siehe auch: https://www.openstreetmap.org/user/addresshistory*hxg*at

Ich habe jetzt wirklich deine Profilseite besucht und musste beim Lesen
deines Begrüßungstextes nur den Kopfschütteln.

Du wolltest eine "brauchbare" Karte von Adressen in Österreich
erstellen, auf Grundlage von unbrauchbaren, falschen und lückenhaften Daten?

Deine Adress-Importe wurden revidiert, weil sie mehr Adressen zerstört
haben, als neue korrekte Adressdaten hinzugefügt haben. Die Daten haben
eine heute üblichen Qualitätsgrad nicht standgehalten.

Wie schon mehrfach erwähnt, gibt es für Importe gewisse Regeln die
einzuhalten sind und die meisten davon sagt mir zumindest mein Hausverstand:
- Sind die Daten die ich importieren will richtig
- Verstoßen diese Daten nicht den Lizenzbedingungen
- Wie werden Konflikte mit bestehenden Daten bereinigt

OSM gibt es jetzt schon eine lange Zeit und durch die Integration von
unterschiedlichen Informationen und Objekten ist die Editierung nicht
mehr so leicht wie am Anfang.

Ich persönlich hatte bereits bei einfachen Änderungen wie neue Straßen
oder Kreisverkehre erstellen das Problem, dass ich mich dabei mit
Relationen befassen musste, weil im Bearbeitungsgebiet sehr viele
Buslinien als Relationen auf den Kanten gemappt waren.

Ich finde es sehr traurig, dass du mit deinen Aussagen immer wieder die
Konfrontation mit der ML und dem Forum suchst. Vielleicht hast du auch
Spaß daran, ich glaube es aber nicht, weil dann würdest du ja auch in
deinem OSM Profil angeben, dass du auch der OSM User in Österreich bist
mit den meisten ML und Forensperren.

OSM ist ein Gemeinschaftsprojekt, dass schon viele Jahre besteht und ich
bin stolz ein Teil zu sein. Sicherlich bin ich mit bestimmten
Entwicklungen nicht einverstanden, aber ich spreche mit anderen darüber.
Ich informiere mich bei div. Community Events zB FOSSGIS und versuche so
Wissenslücken zu schließen, kann mit anderen über meine Vorstellungen
diskutieren oder bekomme Einblicke in Neuerungen in OSM.

Ich würde es begrüßen, wenn wir endlich wieder eine konstruktives
Diskussionsklima hier schaffen könnten, ohne ständige persönliche
Anfeindungen und faktenlosen Aussagen.

In dem Sinne wünsche ich dir und allen Lesern der ML hiermit einen
schönen Abend und noch viele schöne Stunden mit OSM.

mfg
geologist

> Am Do., 18. Juni 2020 um 12:31 Uhr schrieb Florian Ledermann
> mailto:florian.lederm...@tuwien.ac.at>>:
> 
> Liebe Community,
> 
> hat einer für euch eine Erklärung, warum eine Suche bei Nominatim nach
> "Schelleingasse 8" als erstes Ergebnis die Node "Alois-Drasche-Park 8"
> liefert?
> 
> https://nominatim.openstreetmap.org/search.php?q=schelleingasse+8
> 
> Die Address-Node, die hier als erstes geliefert wird, ist in OSM
> korrekt
> als "Alois-Drasche-Park 8" getagged, von Schelleingasse ist dort keine
> Rede. Dennoch wird im Nominatim-Ergebnis die Straße der Ergebnis-Node
> als "Schelleingasse" angezeigt. Das 2. Nominatim Ergebnis ist dann das
> korrekte Haus, leider ist es schwer das automatisiert zu erkennen da
> das
> erste Ergebnis bereits als Node "Schelleingasse 8" zurückgeliefert wird.
> 
> Ich konnte ein solches Ergebnis mit keiner anderen Adressen im 4.
> Bezirk
> reproduzieren, auch die anderen Adressen in der Schelleingasse liefern
> das erwartete (korrekte) Ergebnis. Auffällig ist allerdings noch, dass
> Adress-Nodes im Alois-Drasche-Park von Nominatim anscheinend generell
> nicht gefunden werden (z.B.
> https://nominatim.openstreetmap.org/search.php?q=Alois-Drasche-Park+8 )
> - keine Ahnung ob das etwas damit zu tun hat...
> 
> Ich würde gerne das Tagging verbessern, so dass das 1. Ergebnis in
> Nominatim die korrekte Adresse liefert, habe aber keine Idee wie ich
> das
> machen sollte, da das Tagging der Adresse mir korrekt erscheint.
> 
> Wäre also über einen Hinweis oder Erklärung dankbar!
> 

Re: [Talk-de] Massenweise Entfernung von oneway=no

[Martin Koppenhoefer]

sent from a phone

> On 18. Jun 2020, at 16:15, Volker Schmidt  wrote:
> 
> Was ist denn eine "area where oneway
> streets are common"?


ein städtisches Gebiet in Italien? M.E. haben die Italiener eine große Vorliebe 
für Einbahnstraßenlabyrinthe und “Inselbildung” (Vermeidung von 
Abkürzungsverkehr durch Wohngebiete).


 
> Fuer mich ist klar, dass, ausser mir,  viele andere mapper "oneway=no" auch
> als Gegenteil von "oneway=unknown or unverified"  benutzen.
> Das wiki soll ja dokumentieren wie die tags tatsaechlich benutzt werden,
> mit der impliziten Empfehlung, der Mehrheit zu folgen.
> Ich glaube, dass die tatsächliche Nutzung durch folgende Formulierung
> korrekt dargestellt wird:
> "oneway=no" is considered by many mappers as default value.


genau, das ist auch so festgelegt, dachte ich. Klar, wenn der oneway tag fehlt 
ist man beim alten Problem: default, oder noch unvollständig erfasst?

Gruß Martin 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] facebook compra mapillary

[Martin Koppenhoefer]

la fonte: 
https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] facebook compra mapillary

[Martin Koppenhoefer]

Appena saputo, Facebook ha comprato Mapillary. Dopo Openstreetcam (venduto da 
Telenav a Grab) è il secondo acquisto di streetview che non promette bene.

Se li avete affidato le vostre foto forse sarebbe una buona idea scaricarsi 
tutto finché si può...


Ciao Martin 

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

[Talk-de] Fragen zum iD-Konfliktlösungsvorschlag des OSMF-Vorstands sammeln, Einladung zum FOSSGIS-OSMF-Stammtisch am 25. Juni

[Michael Reichert]

Crossposting zu
https://forum.openstreetmap.org/viewtopic.php?pid=791368#p791368

Hallo,

heute fand wieder ein FOSSGIS-OSMF-Stammtisch per Mumble statt. Das
Protokoll findet ihr im FOSSGIS-Wiki unter
https://www.fossgis.de/wiki/FOSSGIS-OSMF-Stammtisch/2020-06-18

Wir haben auch über den Request for Comment des OSMF-Vorstands zu
möglichen Ansätzen zur Lösung der Kontroversen um den iD-Editor [1, 2]
gesprochen. Wir sind der Meinung, dass es in dem Dokument zu viele
Unklarheiten gibt, um es gut kommentieren zu können. Zum Kommentieren
müsste man zu viel in den Text interpretieren.

Deshalb möchten wir Rückfragen an den OSMF-Vorstand stellen, um
Unklarheiten zu beseitigen. Wir laden euch alle dazu ein, selbst den
Text zu lesen und Unklarheiten – bevorzugt als Fragen ausformuliert –
auf https://pads.ccc.de/FFCsJmjKms abzulegen. Wir würden es begrüßen,
wenn ihr die Fragen in neutraler Form stellt (das geht nicht immer, aber
ein Stück weit geht es schon).

Am Donnerstag, den 25. Juni 2020 findet um 20:00 Uhr unsere nächste
Sitzung per Mumble (Server: podcast.openstreetmap.de) statt. Dort
möchten wir diese Fragen diskutieren und zu einem Fragenkatalog
zusammenstellen. Zu dieser Sitzung seid ihr alle, wie immer, herzlich
eingeladen. Ein Mitgliedschaft im Verein ist nicht erforderlich.

Hinweis für Teilnehmende an der Sitzung: Bitte schaltet in eurem
Mumble-Client vor Beginn der Sitzung Push-to-Talk ein (eine Taste muss
dann gedrückt gehalten werden, solange ihr sprecht), um Echos und andere
unerwünschte Mikrofon-Einschaltungen zu vermeiden. Das ist im Menü unter
Konfiguration → Einstellungen → Audioeingabe → Übertragen möglich.

Viele Grüße

Michael


[1]
https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/
[2] Kontext hierzu: Gewisse Meinungsverschiedenheiten zwischen den
iD-Entwicklern und Teilen der Community sind fast so alt wie iD. Letztes
Jahr ist der Streit jedoch wiederholt eskaliert. Wer sich in die
Thematik tief einlesen möchte, kann an den folgenden Stellen anfangen:
https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions
https://lists.openstreetmap.org/pipermail/talk-de/2019-March/116027.html
https://lists.openstreetmap.org/pipermail/talk/2019-May/082538.html
https://lists.openstreetmap.org/pipermail/talk/2019-May/082609.html



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[scubbx]

Hallo!

Spannende Beobachtung!

Ohne es mir jetzt im Detail durchdacht zu haben, kann an Andreas
Vermutung oder einem ähnlichen Prozess was dran sein, denn auf der
Beschreibungsseite vom Nominatim
(https://wiki.openstreetmap.org/wiki/Nominatim/Development_overview)
steht über dessen Indizierprozess:

/"All indexed features are converted to a simple hierarchy (rank) of
importance with points scored between 0 and 30 (where 0 is most
important)."/

Street und Road haben einen Index von 26 und House oder building einen
von 28 und postcodes 11-25.

Danach passiert:

/"For each feature down to level 26 (street level) a list of parents
is calculated using the following algorithm: /

//

 1. /All polygon/multi-polygon areas which contain this feature (in
order of size)./
 2. /All items by name listed in the is_in are searched for within
the current country (in no particular order)./
 3. /The nearest feature for each higher rank, and all others within
1.5 times the distance to the nearest (in order of distance)./

//

/and a list of keywords is generated from those features. /

/During the indexing process, an address is also calculated using
the first feature found for each level. Where an is_in value is
provided it is used to filter the address."/

Und dann, die konkrete Gebäudeprozessierung mit Adressen:

/"Building indexing/
//

/Buildings, houses and other lower than street level features (i.e.,
bus stops, phone boxes, etc.) are indexed by relating them to their
most appropriate nearby street. /

/The street is calculated as: /

//

 1. /The street member of an associatedStreet relation/
 2. /If the node is part of a way: /
 1. /If this way is street level than that street/
 2. /The street member of an associatedStreet relation that this
way is in/
 3. /A street way with 50/100 meters and parallel with the way
we are in/
 3. /A nearby street with the name given in addr:street of the
feature we are in or the feature we are part of/
 4. /The nearest street (up to 3 miles)/
 5. /Not linked/

//

/All address information is then obtained from the street. As a
result addr:* tags on low-level features are not processed (except
as above). /

/For interpolated ways simple numerical sequences are extrapolated
(alphanumerical sequences are not currently handled) and additional
building nodes are inserted into the way by duplicating the first
(lowest) house number in the sequence."/


Möglicherweise wird das Gebäude der Schelleingasse zugewiesen, da diese
die nächste Straße ist. Der darin liegende Adresspunkt wird dann dem
Gebäude zugeteilt, weil er ein von Nominatim berechnetes "is_in"
Attribut für dieses Gebäude enthält.

Der Schritt "3" von oben greift nicht, weil es keine Straße mit dem Tag
"Alois-Drasche-Park" gibt, die der Adresspunkt zugeornet werden würde.

Es wäre interessant, sich das in der Nominatim Datenbank einmal direkt
anzusehen, was dort für Werte und Zuordnungen hinterlegt sind.

lg, Markus (ScubbX)


Am 18.06.20 um 14:17 schrieb andreas wecer:
> Hallo,
>
> spontane Vermutung, ohne es mir im Detail angesehen zu haben:
>
> Nominatim braucht für street/place ein konkretes OSM-Objekt mit diesem
> Namen. Wenn kein Straßenname angegeben ist, wird die Hausnummer der
> nächstgelegenen Straße zugewiesen. Möglicherweise passiert das auch,
> wenn der angegebene Straßenname nicht gefunden wird, was vermutlich
> hier der Fall ist. 
>
> LG Andreas
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-us] Import of addresses for San Francisco, CA

[Yury Yatsynovich]

I see. Thanks for clarifying, Russell!

On Thu, Jun 18, 2020 at 3:33 PM Russell Nelson  wrote:

> It was an experiment, to see how accurate the three methods could be.
> That road, and many around it, are not completely built-out. When a new
> building is built on an empty parcel, it will have an address
> immediately.  When a new address is assigned to a new (split out)
> parcel, the interpolation will give it an address immediately.
>
> On 6/18/20 3:19 PM, Yury Yatsynovich wrote:
> > Oh, wow!
> > Maybe that's fine, but to me it looks like duplicated info. As far as
> > I understand, extrapolation lines are needed in areas where buildings
> > are not mapped yet and, hence, the extrapolation/approximate location
> > of the address is the best one can get. If the address is precisely
> > assigned to a building, why would one need the same address on the
> > extrapolation line? But, again, that's just my opinion and maybe I'm
> > overlooking something important.
>


-- 
Yury Yatsynovich
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[Johann Haag]

Wenn etwas wie Nominatim derart nachhaltig nicht funktioniert, so kannst Du
mit Gewissheit davon ausgehen, dass ein solches Verhalten bewusst
herbeigeführt ist, unser OpenSource Projekt simpel nicht als
Produktivsystem geeignet sein soll.
Sowas nennt man Politik.
Siehe auch: https://www.openstreetmap.org/user/addresshistory*hxg*at

Am Do., 18. Juni 2020 um 12:31 Uhr schrieb Florian Ledermann <
florian.lederm...@tuwien.ac.at>:

> Liebe Community,
>
> hat einer für euch eine Erklärung, warum eine Suche bei Nominatim nach
> "Schelleingasse 8" als erstes Ergebnis die Node "Alois-Drasche-Park 8"
> liefert?
>
> https://nominatim.openstreetmap.org/search.php?q=schelleingasse+8
>
> Die Address-Node, die hier als erstes geliefert wird, ist in OSM korrekt
> als "Alois-Drasche-Park 8" getagged, von Schelleingasse ist dort keine
> Rede. Dennoch wird im Nominatim-Ergebnis die Straße der Ergebnis-Node
> als "Schelleingasse" angezeigt. Das 2. Nominatim Ergebnis ist dann das
> korrekte Haus, leider ist es schwer das automatisiert zu erkennen da das
> erste Ergebnis bereits als Node "Schelleingasse 8" zurückgeliefert wird.
>
> Ich konnte ein solches Ergebnis mit keiner anderen Adressen im 4. Bezirk
> reproduzieren, auch die anderen Adressen in der Schelleingasse liefern
> das erwartete (korrekte) Ergebnis. Auffällig ist allerdings noch, dass
> Adress-Nodes im Alois-Drasche-Park von Nominatim anscheinend generell
> nicht gefunden werden (z.B.
> https://nominatim.openstreetmap.org/search.php?q=Alois-Drasche-Park+8 )
> - keine Ahnung ob das etwas damit zu tun hat...
>
> Ich würde gerne das Tagging verbessern, so dass das 1. Ergebnis in
> Nominatim die korrekte Adresse liefert, habe aber keine Idee wie ich das
> machen sollte, da das Tagging der Adresse mir korrekt erscheint.
>
> Wäre also über einen Hinweis oder Erklärung dankbar!
>
> LG Florian
>
>
> --
> Dipl.-Ing. Florian Ledermann
> Cartography Research Group
> Department of Geodesy and Geoinformation
> TU Wien, Vienna, Austria
>
> http://cartography.tuwien.ac.at/florian-ledermann/
> https://twitter.com/floledermann
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-us] Import of addresses for San Francisco, CA

[Russell Nelson]

It was an experiment, to see how accurate the three methods could be. 
That road, and many around it, are not completely built-out. When a new 
building is built on an empty parcel, it will have an address 
immediately.  When a new address is assigned to a new (split out) 
parcel, the interpolation will give it an address immediately.


On 6/18/20 3:19 PM, Yury Yatsynovich wrote:

Oh, wow!
Maybe that's fine, but to me it looks like duplicated info. As far as 
I understand, extrapolation lines are needed in areas where buildings 
are not mapped yet and, hence, the extrapolation/approximate location 
of the address is the best one can get. If the address is precisely 
assigned to a building, why would one need the same address on the 
extrapolation line? But, again, that's just my opinion and maybe I'm 
overlooking something important.


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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

Encerrado o processo de votação, alguém se opõe em declarar a proposta
aprovada? O próximo passo é atualizar textos da Wiki, que tratam sobre
o assunto. Passarei aqui as correções a serem feitas para apreciação
da comunidade. Também há uma orientação em manter a página de votação
onde está, a qual pode ser usada de referência e ser linkada por
outras páginas.


> Registro aqui o encerramento da votação da nova proposta de
> classificação viária o qual ocorreu na data de 29/05/2020, às
> 23:59:59, horário de Rio Branco/AC.
>
> Foram um total de 11 votos, onde 7 concordaram, 3 discordaram e 1 absteve.
>
> Existem alguns pontos que foram levantados por colegas e poderão
> entrar na proposta passando por nova votação, como de costume.
>
> Também existem páginas da wiki que precisariam ser revisadas, conforme
> citei no email [1] que enviei no encerramento da votação, antes do
> pedido de prorrogação.
>
> [1] - https://lists.openstreetmap.org/pipermail/talk-br/2020-May/012834.html
>
> Alguma sugestão?

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

Re: [Talk-us] Import of addresses for San Francisco, CA

[Yury Yatsynovich]

Oh, wow!
Maybe that's fine, but to me it looks like duplicated info. As far as I
understand, extrapolation lines are needed in areas where buildings are not
mapped yet and, hence, the extrapolation/approximate location of the
address is the best one can get. If the address is precisely assigned to a
building, why would one need the same address on the extrapolation line?
But, again, that's just my opinion and maybe I'm overlooking something
important.

On Thu, Jun 18, 2020 at 2:58 PM Russell Nelson  wrote:

> I have done this in the area around Potsdam, NY. Assigning the address to
> the centroid of all the points that describe the parcel works quite well.
> It's not perfect, though. Look at May Road. I've entered addresses there in
> three different ways:
>
>   o On the building as an area, traced by hand and added by hand.
>
>   o On the centroid of the parcel as a point.
>
>   o On an address interpolation way, which hops from parcel point to
> parcel point.
>
> The addresses are, as a rule, close enough to the houses to be well worth
> the effort it took to import them. But, go look at it yourself.
>
> https://www.openstreetmap.org/#map=14/44.70688355057632/-74.96382634924055
> On 6/18/20 12:07 PM, Michal Migurski wrote:
>
> I support this import.
>
> I would also support the import of addresses for neighboring Oakland, CA.
>
> -mike.
>
> 
> michal migurski- contact info and pgp key:
> sf/cahttp://mike.teczno.com/contact.html
>
> On Jun 18, 2020, at 8:23 AM, Yury Yatsynovich 
> wrote:
>
> Greetings!
>
> I've been recently thinking about importing addresses for San Francisco,
> CA.
> It looks like there has been interest in this kind of import (the page
> devoted to it was created in 2010,
> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import).
>
> So, please, consider this message as my "community buy-in": does anyone
> have any objections related to this possible import?
> By now I've obtained a permit from the data owner (
> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p)
> and almost finished writing my code for matching buildings to address
> points.
>
> If there are no objections, I'll go on with organising all documentation
> and sharing the code/resulting .osm-files for review by OSM community.
>
> Looking forward to receiving your feedback!
>
> p.s. I have some experience in importing addresses (e.g., see
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses)
>
>
>
>
> --
> Yury Yatsynovich
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
>
> ___
> Talk-us mailing 
> listTalk-us@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-us
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Yury Yatsynovich
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-be] Mapillary & Facebook

[Michel Stuyts]

Apparently Facebook bought Mapillary.


https://blog.mapillary.com/news/2020/06/18/Mapillary-joins-Facebook.html



Michel

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

Re: [Talk-us] Import of addresses for San Francisco, CA

[Russell Nelson]

I have done this in the area around Potsdam, NY. Assigning the address 
to the centroid of all the points that describe the parcel works quite 
well. It's not perfect, though. Look at May Road. I've entered addresses 
there in three different ways:


  o On the building as an area, traced by hand and added by hand.

  o On the centroid of the parcel as a point.

  o On an address interpolation way, which hops from parcel point to 
parcel point.


The addresses are, as a rule, close enough to the houses to be well 
worth the effort it took to import them. But, go look at it yourself.


https://www.openstreetmap.org/#map=14/44.70688355057632/-74.96382634924055

On 6/18/20 12:07 PM, Michal Migurski wrote:

I support this import.

I would also support the import of addresses for neighboring Oakland, CA.

-mike.


michal migurski- contact info and pgp key:
sf/ca http://mike.teczno.com/contact.html

On Jun 18, 2020, at 8:23 AM, Yury Yatsynovich 
mailto:yury.yatsynov...@gmail.com>> wrote:


Greetings!

I've been recently thinking about importing addresses for San 
Francisco, CA.
It looks like there has been interest in this kind of import (the 
page devoted to it was created in 2010, 
https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import).


So, please, consider this message as my "community buy-in": does 
anyone have any objections related to this possible import?
By now I've obtained a permit from the data owner 
(https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p) 
and almost finished writing my code for matching buildings to address 
points.


If there are no objections, I'll go on with organising all 
documentation and sharing the code/resulting .osm-files for review by 
OSM community.


Looking forward to receiving your feedback!

p.s. I have some experience in importing addresses (e.g., see 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses)





--
Yury Yatsynovich
___
Talk-us mailing list
Talk-us@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-us



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

Re: [Talk-us] Import of addresses for San Francisco, CA

[Michal Migurski]

One building can definitely have more than a single address.

Addresses provide postal delivery information and don't necessarily correspond 
1:1 with other concepts like physical buildings or legal parcels.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Jun 18, 2020, at 11:08 AM, Joseph Eisenberg  
> wrote:
> 
> Legally in San Francisco does the address refer to the property, the 
> building, or the entrance? 
> 
> While I'm from California originally, I admit that I don't know the 
> definition of an address there. 
> 
> If one building can have more than one address (based on separate entrances), 
> then it would be best to use nodes.
> 
> - Joseph Eisenberg
> 
> On Thu, Jun 18, 2020 at 9:36 AM Yury Yatsynovich  > wrote:
> I saw addresses in SF mapped both ways -- some are mapped as nodes inside the 
> buildings or on contours of buildings (as entrances); others are added 
> directly on the ways/relations of buildings.
> 
> On Thu, Jun 18, 2020 at 12:20 PM Joseph Eisenberg  > wrote:
> >  matching buildings to address points
> 
> I support the idea of adding missing addresses. However, is it best practice 
> to match the address with the building area? 
> 
> Currently in SF are almost all addresses matched with buildings, or are some 
> mapped as nodes or separate area features?
> 
> -- Joseph Eisenberg
> 
> On Thu, Jun 18, 2020 at 8:30 AM Yury Yatsynovich  > wrote:
> Greetings!
> 
> I've been recently thinking about importing addresses for San Francisco, CA.
> It looks like there has been interest in this kind of import (the page 
> devoted to it was created in 2010, 
> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import 
> ).
> 
> So, please, consider this message as my "community buy-in": does anyone have 
> any objections related to this possible import?
> By now I've obtained a permit from the data owner 
> (https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p
>  
> )
>  and almost finished writing my code for matching buildings to address points.
> 
> If there are no objections, I'll go on with organising all documentation and 
> sharing the code/resulting .osm-files for review by OSM community.
> 
> Looking forward to receiving your feedback!
> 
> p.s. I have some experience in importing addresses (e.g., see 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses 
> )
> 
> 
> 
> 
> -- 
> Yury Yatsynovich
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us 
> 
> 
> 
> -- 
> Yury Yatsynovich
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

[Talk-us] Fwd: Import of addresses for San Francisco, CA

[Yury Yatsynovich]

Indeed, if address nodes were mapped at locations of entrances then
importing points with addresses as entrances would be preferable. Yet, the
imported address points are not at entrances' locations, but rather at
centroids of corresponding parcels, so matching them to buildings requires
parcels as an intermediate layer. In the case when multiple house numbers
are within the same building, they are usually combined into a
";"-separated list, e.g. [addr:housenumber = 101;103;105] -- Nominatim can
find addresses that are mapped using ";"-separated lists.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Import of addresses for San Francisco, CA

[Joseph Eisenberg]

Legally in San Francisco does the address refer to the property, the
building, or the entrance?

While I'm from California originally, I admit that I don't know the
definition of an address there.

If one building can have more than one address (based on separate
entrances), then it would be best to use nodes.

- Joseph Eisenberg

On Thu, Jun 18, 2020 at 9:36 AM Yury Yatsynovich 
wrote:

> I saw addresses in SF mapped both ways -- some are mapped as nodes inside
> the buildings or on contours of buildings (as entrances); others are added
> directly on the ways/relations of buildings.
>
> On Thu, Jun 18, 2020 at 12:20 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> >  matching buildings to address points
>>
>> I support the idea of adding missing addresses. However, is it best
>> practice to match the address with the building area?
>>
>> Currently in SF are almost all addresses matched with buildings, or are
>> some mapped as nodes or separate area features?
>>
>> -- Joseph Eisenberg
>>
>> On Thu, Jun 18, 2020 at 8:30 AM Yury Yatsynovich <
>> yury.yatsynov...@gmail.com> wrote:
>>
>>> Greetings!
>>>
>>> I've been recently thinking about importing addresses for San Francisco,
>>> CA.
>>> It looks like there has been interest in this kind of import (the page
>>> devoted to it was created in 2010,
>>> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import).
>>>
>>> So, please, consider this message as my "community buy-in": does anyone
>>> have any objections related to this possible import?
>>> By now I've obtained a permit from the data owner (
>>> https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p)
>>> and almost finished writing my code for matching buildings to address
>>> points.
>>>
>>> If there are no objections, I'll go on with organising all documentation
>>> and sharing the code/resulting .osm-files for review by OSM community.
>>>
>>> Looking forward to receiving your feedback!
>>>
>>> p.s. I have some experience in importing addresses (e.g., see
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses)
>>>
>>>
>>>
>>>
>>> --
>>> Yury Yatsynovich
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>
>
> --
> Yury Yatsynovich
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Import of addresses for San Francisco, CA

[Michal Migurski]

I support this import.

I would also support the import of addresses for neighboring Oakland, CA.

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html

> On Jun 18, 2020, at 8:23 AM, Yury Yatsynovich  
> wrote:
> 
> Greetings!
> 
> I've been recently thinking about importing addresses for San Francisco, CA.
> It looks like there has been interest in this kind of import (the page 
> devoted to it was created in 2010, 
> https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import 
> ).
> 
> So, please, consider this message as my "community buy-in": does anyone have 
> any objections related to this possible import?
> By now I've obtained a permit from the data owner 
> (https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p
>  
> )
>  and almost finished writing my code for matching buildings to address points.
> 
> If there are no objections, I'll go on with organising all documentation and 
> sharing the code/resulting .osm-files for review by OSM community.
> 
> Looking forward to receiving your feedback!
> 
> p.s. I have some experience in importing addresses (e.g., see 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses 
> )
> 
> 
> 
> 
> -- 
> Yury Yatsynovich
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-br] Digest Talk-br, volume 141, assunto 5

[Helio Cesar Tomio]

A carta de solicitacao para a empresa nao precisa ser exatamente como o
modelo que enviasse.
Basta que autorizem o uso dos dados de forma livre para realizar a
importação no Openstreetmap, compatível com a licença do OSM.

Vc precisa ter o cuidado para nao fazer edicoes que nao seguem as regras
das tags já aprovadas.
Por exemplo, eu acho muito estranho colocar nome em postes. Nao sei dizer
se isso é correto. Seria como colocar o nome em lixeiras, hidrantes,
orelhões,...
E a tag building nao parece apropriada para postes, qdo vc tem por exemplo
power=pole.

Recentemente foram aprovadas novas tags para linhas de energia, talvez na
linha do teu trabalho:
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management

Nas tuas futuras importacoes, necessario checar se a localizacao dos postes
ficará correta no OSM. Bastaria um erro no referencial utilizado
(sad69/sirgass2000/wgs84) que o trabalho seria comprometido.
Foi constatado que muitos postes acabaram ficando dentro de lotes ou sobre
edificações, devido alguma divergência de informação.

Sei que parece chatice tudo isso, mas a comunidade se preocupa para que os
dados do OSM nao se transformem numa confusão ou em informações erradas ou
inúteis.

Cordialmente,
Tomio

Em qua, 17 de jun de 2020 14:26, Mapas Osm  escreveu:

> A respeito da licença de dados, a mesma seria confirmada por meio de carta
> (modelo em anexo).
> Os dados são do tipo ponto no formato shapefile coletados com receptor
> GNSS com códigos de identificação de cada transformador e chave em alguns
> municípios dos estados de São Paulo e Mato Grosso do Sul.
> A metodologia de importação seria utilizando o Josm importando os dados em
> blocos e realizando todas as correções de conflitos que vierem a aparecer.
> Para haver a consulta dos códigos os pontos precisam ser mapeados com a
> "tag=building_transformer-tower" e a "ref" substituída por "name".
>
> On Tue, Jun 16, 2020 at 8:44 AM Mapas Osm  wrote:
>
>> Segue o anexo
>>
>> On Tue, Jun 16, 2020 at 8:43 AM Mapas Osm  wrote:
>>
>>> Obrigado pelos esclarecimentos,
>>> Em relação à licença, usando o modelo de carta em anexo, já é possível
>>> garanti-la?
>>>
>>> On Tue, Jun 16, 2020 at 8:01 AM 
>>> wrote:
>>>
 Enviar submissões para a lista de discussão Talk-br para
 talk-br@openstreetmap.org

 Para se cadastrar ou descadastrar via WWW, visite o endereço
 https://lists.openstreetmap.org/listinfo/talk-br
 ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
 corpo da mensagem para
 talk-br-requ...@openstreetmap.org

 Você poderá entrar em contato com a pessoa que gerencia a lista pelo
 endereço
 talk-br-ow...@openstreetmap.org

 Quando responder, por favor edite sua linha Assunto assim ela será
 mais específica que "Re: Contents of Talk-br digest..."


 Tópicos de Hoje:

1. Importações de transformadores. (Mapas Osm)
2. Re:  Importações de transformadores. (Helio Cesar Tomio)
3. Re:  Importações de transformadores. (Helio Cesar Tomio)
4. Re:  Importações de transformadores. (portalavent...@riseup.net)


 --

 Message: 1
 Date: Mon, 15 Jun 2020 10:49:03 -0300
 From: Mapas Osm 
 To: talk-br@openstreetmap.org
 Subject: [Talk-br] Importações de transformadores.
 Message-ID:
 >>> eqzxq+awho1pwojgww8c...@mail.gmail.com>
 Content-Type: text/plain; charset="utf-8"

 Olá,
 Tenho informações georreferenciadas de transformadores e chaves de parte
 dos estados de São Paulo e Mato Grosso do Sul, os dados foram fornecidos
 pela empresa de energia local. Cada ponto possui seu código específico
 indispensável para sua consulta.
 Existe a possibilidade de importar esses dados para o OSM base? Caso
 positivo, como proceder à importação de forma que esses códigos podem
 ser
 consultados?

 Desde já agradeço!
 -- Próxima Parte --
 Um anexo em HTML foi limpo...
 URL: <
 http://lists.openstreetmap.org/pipermail/talk-br/attachments/20200615/a8470cfc/attachment-0001.htm
 >

 --

 Message: 2
 Date: Mon, 15 Jun 2020 18:16:43 -0300
 From: Helio Cesar Tomio 
 To: OpenStreetMap no Brasil 
 Subject: Re: [Talk-br]  Importações de transformadores.
 Message-ID:
 <
 cae1uxb0dlbp2gr3atwmzgecca986hjttbkkbpkqp8fntow4...@mail.gmail.com>
 Content-Type: text/plain; charset="utf-8"

 Sim, é permitido importações de dados desde que comunicado previamente
 para
 a comunidade local ou do Brasil.
 Esse comunicado deve esclarecer a origem dos dados (nao podem ter
 copyright), que tipo de dado, como vai ser feito (controle de erros,
 dados
 duplicados,...).

 Importacoes sao revertidas senao houver 

[Talk-us] Import of addresses for San Francisco, CA

[Yury Yatsynovich]

Greetings!

I've been recently thinking about importing addresses for San Francisco, CA.
It looks like there has been interest in this kind of import (the page
devoted to it was created in 2010,
https://wiki.openstreetmap.org/wiki/San_Francisco_Address_Import).

So, please, consider this message as my "community buy-in": does anyone
have any objections related to this possible import?
By now I've obtained a permit from the data owner (
https://data.sfgov.org/Geographic-Locations-and-Boundaries/Addresses-Enterprise-Addressing-System/3mea-di5p)
and almost finished writing my code for matching buildings to address
points.

If there are no objections, I'll go on with organising all documentation
and sharing the code/resulting .osm-files for review by OSM community.

Looking forward to receiving your feedback!

p.s. I have some experience in importing addresses (e.g., see
https://wiki.openstreetmap.org/wiki/Import/Catalogue/MassGIS_Addresses)




-- 
Yury Yatsynovich
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk] HOT Update

[Christoph Hormann]

It is probably advisable to clarify that in OSM we do not map people.  
People themselves are not considered part of the world geography.  OSM is 
about people mapping their own environment and sharing their local 
knowledge of the local geography - which includes human made structures 
of all kind but not the people creating them and living around them.


You probably did not intend to imply otherwise but quite a few readers of 
your text not familiar with OSM, cartography and humanitarian mapping 
jargon might get a wrong impression about OSM from your phrasing.


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

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

Re: [Talk-de] Massenweise Entfernung von oneway=no

[Volker Schmidt]

(Diese Diskussion ist irgendwie hängengeblieben)

Ich denke, dass 3 Millionen oneway=no weltweit anzeigen, dass das ein tag
ist, das man nicht einfach als "redundant" entfernen sollte.

Im wiki steht außerdem ein dummer Satz, und das seit langer Zeit:
" (Use only in order to avoid mapping errors in areas where e.g. oneway
streets are common, or to override defaults.)"
Der erste Teil ist einfach unsinnig. Was ist denn eine "area where oneway
streets are common"?
Fuer mich ist klar, dass, ausser mir,  viele andere mapper "oneway=no" auch
als Gegenteil von "oneway=unknown or unverified"  benutzen.
Das wiki soll ja dokumentieren wie die tags tatsaechlich benutzt werden,
mit der impliziten Empfehlung, der Mehrheit zu folgen.
Ich glaube, dass die tatsächliche Nutzung durch folgende Formulierung
korrekt dargestellt wird:
"oneway=no" is considered by many mappers as default value.
However a considerable number of mappers prefer to explicitly map two-way
roads with oneway=no, especially those where the road width appears limited
(lanes=1 or width values not sufficient for crossing of normal dual-track
vehicles).
In any case any "oneway=no" tags should not be considered redundant and
should not be removed without consulting the original mapper.

What is (nearly) completely missing in the present use of oneway is
oneway=unknown (7 uses globally in TagInfo), given the fact that mapping
from aerial imagery is common in th OSM community.

Da sehe ich Nachholbedarf.
Ich muss aus (schlechter) Erfahrung sagen, dass einige (wahrscheinlich
sogar nur wenige) Luftbildmapper oft fehlende Einbahnstraßen produzieren,
oder produziert haben.

Bitte um Kommentare bevor ich das auf the tagging Liste bringe?

Volker






Virus-free.
www.avast.com

<#m_-2993722840009941039_m_-4885503972250629702_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, 4 Jun 2020 at 14:09, Martin Koppenhoefer 
wrote:

> Am Do., 4. Juni 2020 um 00:36 Uhr schrieb Florian Lohoff :
>
> > Und bei den tags wie sidewalk, shoulder, cycleway, lit, surface mache
> > ich das - Bei oneway nicht. Und da stellt Volker natürlich zurecht
> > die Frage warum.
> >
> > Und das einzige was mir als Unterscheidungskriterium einfällt ist die
> > Statistische Verteilung der tag values
>
>
>
> wobei die Erwartungen da regional unterschiedlich sein können, habe mir das
> gerade mal in einem städtischen Gebiet angesehen, da habe ich z.B.
> ("zufälliges" Gebiet in meiner Umgebung) 595 highway=residential und davon
> sind 423 oneway=yes.
> In ganz Italien gibt es laut geofabrik taginfo italy 970.580
> highway=residential, davon haben 176.112 oneway=yes und 45.490 oneway=no
> (fehlen nur noch 170 oder so an anderen oneway-Werten wie -1), d.h.
> immerhin 18,15% sind als oneway=yes getaggt (und wir sind in der Fläche
> noch unreifer als in Deutschland, bisher erst 67,6% name tags weil vieles
> nur von Luftbildern kommt, wo neben name evtl. auch oneway tags noch
> fehlen).
>
> https://taginfo.geofabrik.de/europe/italy/tags/highway=residential#combinations
>
> in Deutschland sieht es so aus:
>
> https://taginfo.geofabrik.de/europe/germany/tags/highway=residential#combinations
> 6% oneway=yes und 2,3% oneway=no auf residentials, bei 94,7% name tag
> vorhanden.
>
> Das mit dem name-tag als Kriterium ist so eine Sache, weil es ja auch
> residential Straßen ohne Namen geben kann (und sich da evtl. die
> Gepflogenheiten auch unterscheiden), es gäbe als Kontrolltag noch "noname",
> was aber in D. 0,22% sind und in Italien 0,21%, "noname" ist wohl einfach
> nicht so populär.
>
> abschließend noch die globalen Daten zum Vergleich (sicherlich noch
> unvollständiger hinsichtlich der Attribute)
> https://taginfo.openstreetmap.org/tags/highway=residential#combinations
> 4,34% oneway=yes und 2,43% oneway=no auf residentials, bei 43,83% name
> tags
> (0,42% noname), insgesamt 52 Millionen ways.
>
>
> Gruß
> Martin
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>


Virus-free.
www.avast.com

<#m_-2993722840009941039_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Yves P.]

> Et dans OsmAnd c'est 
> https://proxy-ign.openstreetmap.fr/94GjiyqD/bdortho/{0}/{1}/{2}.jpg 
> 
>  
> J'ai essayé de le rajouter en tant que fond de carte, mais rien ne s'affiche 
> chez moi.
Tu n'as pas de faute de frappe ?

> Comment t'as fait pour afficher en haut à droite, l'icone de l'appreil photo 
> avec "Démarrer"
https://wiki.openstreetmap.org/wiki/File:OsmAnd_config_photo_1.jpg
https://wiki.openstreetmap.org/wiki/File:OsmAnd_config_photo_2.jpg
https://wiki.openstreetmap.org/wiki/File:OsmAnd_config_photo_3.jpg

> Mon usage final pour faire des relevés terrain avec OSMAnd ce serait 
> d'ajouter une action accompagnée d'une photo ? (comme ce qui a été évoqué 
> dans les messages précédents). Le bouton "Action rapide" ne me propose pas de 
> prendre des photos.
Il faut appuyer sur "+" pour en rajouter une.

Ensuite à l'usage, il fait apparaitre une barre d'icône
Déplacer si besoin le "point"
Puis cliquer sur l'appareil photo (que tu as ajouté précédemment).

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

[OSM-talk] HOT Update

[Tyler Radford]

Hi,

We wanted to share some news about HOT's work over the next five years,
which has been launched today -
https://www.hotosm.org/updates/audacious-announcement/

*Tyler Radford*
Executive Director
tyler.radf...@hotosm.org
@TylerSRadford

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Humanitarian Response & Economic Development*
web  | twitter  | facebook
 | donate 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Georges Dutreix via Talk-fr]

Le 18/06/2020 à 13:27, Jacques Lavignotte a écrit :

OSMAnd n'est pas le bon outil. Il fait trop de choses.


Effectivement, l'ergonomie d'Osmand est horrible.

Mais on peut positionner une photo, une note audio, une vidéo,
- avec toute la précision voulue - bon ok, sauf en rase campagne comme 
l'a dit Yves ;-)

- même si on n'a pas de réseau - cartes stockées dans l'ordiphone
- en 4 clics :

   1) action rapide
   2) ajouter une note photo - ou audio, parfois il est plus simple de
   dire "bâtiment manquant"
   3) recaler la carte sous le pointeur
   4) prendre la photo

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

[OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Quentin Salles]

Bonjour,

Et dans OsmAnd c'est
> https://proxy-ign.openstreetmap.fr/94GjiyqD/bdortho/{0}/{1}/{2}.jpg
>
J'ai essayé de le rajouter en tant que fond de carte, mais rien ne
s'affiche chez moi.

Voici une copie d'écran <
> https://wiki.openstreetmap.org/wiki/File:Notes_photo_avec_OsmAnd.jpg>.
>
Comment t'as fait pour afficher en haut à droite, l'icone de l'appreil
photo avec "Démarrer"

Mon usage final pour faire des relevés terrain avec OSMAnd ce serait
d'ajouter une action accompagnée d'une photo ? (comme ce qui a été évoqué
dans les messages précédents). Le bouton "Action rapide" ne me propose pas
de prendre des photos.

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

Re: [Talk-GB] COVID road changes

[Robert Skedgell]

LB Southwark have just made some ETOs which explicitly mention the
London Streetspace programme in the London Gazette announcement. The
orders come into force on 2020-06-25 and expire on 2021-12-29.

https://www.thegazette.co.uk/notice/3579196

This could be a good opportunity to work out how to tag the changes.

On 16/06/2020 19:27, Simon Still wrote:
>>Temporary and experimental traffic orders may include a date on which
>>the expire or have to be reviewed, so that could perhaps be tagged?
> 
>>None of the orders which I have seen have explicitly mentioned Covid-19,
>>but any suggestions about how to tag these would be useful.
> 
> A COVID-19 tag  - or  #StreetspaceLDN  StreetspaceLondon or some
> variation could also enable mapping that highlights the temporary
> infrastructure (I know there is interest in this within the cycling
> community) 
> 
> Best
> Simon
> (Didn’t receive original mail so apologies if this doesn’t thread)

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

Re: [OSM-ja] 郡名の英語表記について

[Satoshi IIDA]

いいだです。

Countyへの統一に賛成します。

住所の構造を決める際にこのへんは諸々ご協力を得て調べまして、
Countyの大きさとDistrictの大きさ、どっちが感覚的にいって大きい？みたいなことともヒアリングして、
（ぱっと出てこないけど、Tagging MLあたりで聞いた気がする）
それをもって、住所の構造を決めた記憶があります。

なので、addr:* タグについても、郡はaddr:countyがいまのところの合意かと思っています。

https://wiki.openstreetmap.org/wiki/JA:Key:addr#.E6.97.A5.E6.9C.AC.E3.81.AE.E4.BD.8F.E6.89.80.E8.A1.A8.E8.A8.98.E3.81.AB.E3.81.A4.E3.81.84.E3.81.A6
https://qiita.com/nyampire/items/7fa6efd944086aea820e#%E4%BD%8F%E6%89%80%E3%81%AE%E9%9A%8E%E5%B1%A4%E6%A7%8B%E9%80%A0

他、これもぱっと出てこないのですが、
省庁系の規格の翻訳でも、郡がCountyになっていたことを見つけて小躍りした記憶があります[要出典]

日本の共通語彙基盤では、郡、の構造が抜けていて批判をうけていたりしますし、
出典どこだったかなぁ、、、という検索ゲームをしています、はい。



2020年6月18日(木) 16:57 batosm :

> 「County」の統一に賛成です。USのAdmin
> LevelではDistrictは複数のレベルに存在します。CountyであればStateの下になるので、都道府県の下になる日本の群と同一の運用が出来ると思います。
>
> 2020年6月18日(木) 13:32 OKADA Tsuneo :
>
>> 岡田です。
>>
>> wikiのJapan taggingにも関わることですので、こちらに相談します。
>> https://wiki.openstreetmap.org/wiki/Japan_tagging
>>
>> 最近地名の英語表記を確認してまして、その中で郡名の英語表記が気になりました。
>> (安芸郡とか諏訪郡とかの郡)
>>
>> wikiでは「郡」の英名は「District」としていますが、
>>  国土地理院の「 地名等の英語表記規程 」(平成28年3月)の第14条では「郡」の英名は「County」を使うとなっています。
>> https://www.gsi.go.jp/common/000138865.pdf
>>
>> 実際の郡名のOSMの登録データのname:enを見ると、CountyとDistrictが混在しています。
>> 国土地理院の規程に従ってCountyに統一したらいいのではと思いますが、いかがでしょうか？
>> placeタグの値もcountyで一致するのですっきりします。
>>
>> 昔は「郡」の英訳は「District」でしたっけ？
>> そんなような記憶もありますし、wikipediaの「郡」の項には「District」と訳すとも書いていましたので。。
>>
>> 郡名はあまりOSMで目立たないので気にする人も少ないかもしれませんが。。
>>
>> ご意見下さい。
>>
>> --
>> 岡田常雄(OKADA Tsuneo)
>> tsuneo.ok...@gmail.com
>> ___
>> Talk-ja mailing list
>> Talk-ja@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ja
>>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Fontaine fleurie

[Yves P.]

> S'il vous plait : non. Une fontaine, c'est un point d'eau.
:)

> Si tu cherches quelque chose pour le rendu, j'irais plutôt voir du coté de 
> tourism=artwork 
On trouve aussi des anciens pressoirs ± fleuris bagués comme ça.

Le wiki renvoi sur taginfo pour les valeurs "maison" : il y a 155 fountain* et 
40 fontaine* (dont 39 fontaines Wallace).

Merci JB :)

Je mettrais bien ça sur le wiki. Fontaine fleurie donne quoi en grand breton ?

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

Re: [OSM-talk-fr] open-orthos: 3 départements de plus: 27, 53, 76...

[Denis Bigorgne]

Merci, j'en tiendrais compte.
En passant, on pourrait améliorer le message intimidant de JOSM au
téléchargement:  "L'imagerie aérienne "BDOrtho IGN" pourrait être mal
alignée; veuillez vérifier son calage à l'aide de trace GPS!"


Le jeu. 18 juin 2020 à 14:28, Stéphane Péneau 
a écrit :

> Le 18/06/2020 à 10:48, Christian Quest a écrit :
> > Je pense qu'on est en dessous d'1m, mais je ne trouve pas l'info et
> > comme le site "pro" de l'IGN est indisponible depuis décembre,
> > difficile de mieux répondre.
>
> De mémoire c'était 80cm maximum, et la valeur moyenne était bien plus
> bassemais c'est vraiment de mémoire.
>
>
> >
> > Le 18/06/2020 à 10:14, Denis Bigorgne a écrit :
> >> Merci, mais plus précisément : 1m, 3m, 5m ?
> >> Ce sont des précisions qu'on peut atteindre avec les GPS actuels, et
> >> on est un peu dans l'incertitude quand on veut porter un POI dans la
> >> nature et qu'il y a contradiction entre le GPS et l'orthophoto ( à
> >> droite ou à gauche du sentier ? Qu'est ce que je rectifie : le POI ou
> >> le sentier ? )
>
> En France, avec la BDOrtho, tu peux considérer que cette dernière est
> bien plus précise que ton récepteur GPS.
>
> Stf
>
>
>
> ___
> 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] Cartopartie : comment relever efficacement les horaires des commerces ?

[Yves P.]

> Vous êtes masochistes.
Oui, fouette moi Jques :D

> Prenez juste des photos géoréférencées  et déposez les dans JOSM. Prenez des 
> notes sur du papier. C'est tout.
Note : "le poteau est à droite du sapin et 2 m à gauche du caillou"

Pour le géoréférencement, je prends les coordonnées GPS de l'appareil photo, 
avec les erreurs multipath, les satellites GPS masqués par les obstacles… ;)

Ok, la carto partie est en ville, donc 3 photos et de bonnes notes devraient le 
faire :)

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

Re: [OSM-talk-fr] Fontaine fleurie

[JB]

Le 18/06/2020 à 13:56, Yves P. a écrit :


Quitte à modifier les logiciels de rendu, je préfèrerais garder 
amenity=fountain et lui rajouter un tag additionnel (cf. proposition 
de Marc).

Ainsi dans les 2 cas, la fontaine reste rendue.


S'il vous plait : non. Une fontaine, c'est un point d'eau.
Si tu cherches quelque chose pour le rendu, j'irais plutôt voir du coté 
de tourism=artwork (un truc pour faire joli, mais sans utilité 
"pratique". Ça y est, je me suis aussi mis à dos tout les métiers de l'art…)

JB.


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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Jacques Lavignotte]

Le 18/06/2020 à 13:42, Yves P. a écrit :

Si tu utilises les actions rapides, ça place le point au centre de la 
carte, mais tu peux la bouger avant de prendre la photo, pour qu'elle 
soit placée au bon endroit.



ça y est, j'ai compris :D


Vous êtes masochistes.

Prenez juste des photos géoréférencées  et déposez les dans JOSM. Prenez 
des notes sur du papier. C'est tout.


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] open-orthos: 3 départements de plus: 27, 53, 76...

[Stéphane Péneau]

Le 18/06/2020 à 10:48, Christian Quest a écrit :
Je pense qu'on est en dessous d'1m, mais je ne trouve pas l'info et 
comme le site "pro" de l'IGN est indisponible depuis décembre, 
difficile de mieux répondre.


De mémoire c'était 80cm maximum, et la valeur moyenne était bien plus 
bassemais c'est vraiment de mémoire.





Le 18/06/2020 à 10:14, Denis Bigorgne a écrit :

Merci, mais plus précisément : 1m, 3m, 5m ?
Ce sont des précisions qu'on peut atteindre avec les GPS actuels, et 
on est un peu dans l'incertitude quand on veut porter un POI dans la 
nature et qu'il y a contradiction entre le GPS et l'orthophoto ( à 
droite ou à gauche du sentier ? Qu'est ce que je rectifie : le POI ou 
le sentier ? )


En France, avec la BDOrtho, tu peux considérer que cette dernière est 
bien plus précise que ton récepteur GPS.


Stf



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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Julien Lepiller]

Le 18 juin 2020 07:42:38 GMT-04:00, "Yves P."  a écrit :
>> Oui, mais pour "prendre une photo", il faut le faire sur un poi ou un
>point que tu places sur la carte avec un appui long.
>
>> Si tu utilises les actions rapides, ça place le point au centre de la
>carte, mais tu peux la bouger avant de prendre la photo, pour qu'elle
>soit placée au bon endroit.
>ça y est, j'ai compris :D
>
>J'utilisais le bouton dans le panneau de droite. Il prend directement
>une photo avec les coordonnées GPS de l'instant (sans possibilité de
>"recaler" manuellement le point).
>
>Le bouton action rapide fonctionne comme dans Street Complete :)
>
>Mon cas d'utilisation est dans la "cambrousse". Je dois donc afficher
>la "carte en ligne" BDOrtho IGN pour avoir une référence visuelle pour
>recaler éventuellement ma photo.
>
>Voici une copie d'écran
>.
>
>__
>Yves

Ah ! J'avais jamais fait attention au bouton « Démarrer ». J'ai toujours cru 
que c'était en rapport aux traces gpx. D'où la confusion de mon côté aussi. 
C'est vrai que ce bouton n'est pas terrible.

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

Re: [Talk-at] Irreführendes Nominatim-Ergebnis

[andreas wecer]

Hallo,

spontane Vermutung, ohne es mir im Detail angesehen zu haben:

Nominatim braucht für street/place ein konkretes OSM-Objekt mit diesem
Namen. Wenn kein Straßenname angegeben ist, wird die Hausnummer der
nächstgelegenen Straße zugewiesen. Möglicherweise passiert das auch, wenn
der angegebene Straßenname nicht gefunden wird, was vermutlich hier der
Fall ist.

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

Re: [Talk-it] Compresenza addr street e place

[Marcello]

Il 18/06/20 12:51, Andrea Musuruane ha scritto:

Ciao,

On Thu, Jun 18, 2020 at 12:39 PM Damjan Gerl > wrote:


Forse si, forse no... Le cose che mi hanno portato a non usarlo sono:
- la regola che in addr:city si mette il comune (quindi Trieste)
- se metto addr:city=Opicina per lo stesso cap (34151) mi trovo
anche altri addr:city=Trieste per Barcola (place=suburb), perché
lo stesso cap è usato anche in Trieste città.

Quindi capito che addr:place è da togliere, cosa usiamo?
o solo addr:city=Opicina / Opčine
o addr:city=Trieste  + addr:town=Opicina / Opčine

Io sarei per quest'ultimo..


Cerco di fare un po' di chiarezza.

In Italia gli indirizzi si assegnano a livello comunale. Quindi è 
errato mettere un addr:city diverso dal nome del comune in cui si 
trova l'indirizzo.


Se, come riportato dalla pagina wiki, le chiavi addr:* corrispondono 
all'indirizzo postale, non mi sembra automatico che in addr:city vada il 
nome del comune. Secondo le regole di composizione degli indirizzi di 
Poste Italiane, postato qui qualche giorno fa da Andrea Falco, a pag.8 
punto 11 si legge che è necessario indicare il nome del comune se la 
frazione non è inclusa nel Codice di Avviamento Postale, ma alcune 
frazioni sono incluse. Per Opicina è giusto mettere Trieste perché 
facendo una ricerca del CAP nel sito delle Poste non trova nulla, ma non 
sempre è così.
A volte capita ancora, anche se l'attuale normativa lo esclude 
esplicitamente, di avere odonimi uguali in differenti parti del comune 
(ad esempio in due frazioni). In questo caso si usa addr:hamlet. 
Tralasciamo il fatto che hamlet è un valore del tag place, così come 
city è un valore del tag place, con una sua specificità. E' solo una 
nomenclatura.


Se proprio vuoi inserire lo stesso l'informazione su luogo in cui si 
trovano anche se questa è inutile per la sua localizzazione, puoi 
usare addr:hamlet.


Se si usano altri tag non documentati come addr:town (anche se usati: 
in OSM può esistere qualsiasi tag, purtroppo), proprio perché non 
documentati, hanno un significato ambiguo e non ci saranno data user 
che li useranno.


Ciao,

Andrea


--
Ciao
Marcello

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

Re: [OSM-talk-fr] Fontaine fleurie

[Yves P.]

> Je dirai ...  abandoned:amenity 
> =fountain 
> .
>   qui n'empêche pas quelqu'un qui veut rendre des fontaines ornementales sur 
> une carte .
abandoned:*=* ou disused:*=* ou something_else:*=* empêche le rendu.

Il faut effectivement que les moteurs de rendu (et les éditeurs) soient mis à 
jour pour cela.

Quitte à modifier les logiciels de rendu, je préfèrerais garder 
amenity=fountain et lui rajouter un tag additionnel (cf. proposition de Marc).
Ainsi dans les 2 cas, la fontaine reste rendue.

> voici deux catégories où tu pourrais peut-être mettre cette photo :
> 
> https://commons.wikimedia.org/wiki/Category:Defunct_fountains 
>   
> 
> https://commons.wikimedia.org/wiki/Category:Former_fountains 
>   
Merci, je ne les connaissais pas.

Former est-ce les anciennes fontaines complètement détruites ?
Et Defunct celles qui ont été transformées en bac à fleur ?

Les photos dans Category:Former fountains 
 semblent un peu 
mélangées :/

> auqul on peux ajouter flowers=yes
:)

> même s'il manque sans doute un tag principal genre
> landuse=flowerbed
> landuse=meadow (pas trop du tout)
> leisure=garden garden:style=flower_garden (micro-mapping ?)
Là je ne te rejoint pas. Une fontaine (fleurie) est un objet physique posé sur 
un terrain, pas un terrain.

Pour building=* on ne rajoute pas landuse=*. Le polygone du bâtiment est "sur" 
le polygone d'un terrain avec le tag landuse=*.

Idem pour leisure=garden, c'est un terrain.

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Yves P.]

> Oui, mais pour "prendre une photo", il faut le faire sur un poi ou un point 
> que tu places sur la carte avec un appui long.

> Si tu utilises les actions rapides, ça place le point au centre de la carte, 
> mais tu peux la bouger avant de prendre la photo, pour qu'elle soit placée au 
> bon endroit.
ça y est, j'ai compris :D

J'utilisais le bouton dans le panneau de droite. Il prend directement une photo 
avec les coordonnées GPS de l'instant (sans possibilité de "recaler" 
manuellement le point).

Le bouton action rapide fonctionne comme dans Street Complete :)

Mon cas d'utilisation est dans la "cambrousse". Je dois donc afficher la "carte 
en ligne" BDOrtho IGN pour avoir une référence visuelle pour recaler 
éventuellement ma photo.

Voici une copie d'écran 
.

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Eric SIBERT]

Le 18/06/2020 à 13:27, Jacques Lavignotte a écrit :

OSMAnd n'est pas le bon outil. Il fait trop de choses.


+1.

Il faut prendre OSMTracker. On active l'enregistrement de la trace en 
continue comme ça le GPS fonctionne en permanence même téléphone éteint 
et arrive à capter plus de satellites, d'où une meilleure précision. 
Quand on ne prend pas de photo, on tient le téléphone à bout de bras, le 
plus haut possible ;-). Ne pas oublier le gilet OSM pour expliquer ce 
que tu fais...


Eric

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

Re: [OSM-talk-fr] accès aux photos IGN

[Yves P.]

> Pour info la couche "BDOrtho" dans JOSM renvoie vers 
> https://proxy-ign.openstreetmap.fr/94GjiyqD/bdortho/{zoom}/{x}/{y}.jpg 
> Merci
>  Vincent pour le lien :)

Et dans OsmAnd c'est 
https://proxy-ign.openstreetmap.fr/94GjiyqD/bdortho/{0}/{1}/{2}.jpg 


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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Jacques Lavignotte]

OSMAnd n'est pas le bon outil. Il fait trop de choses.



Le 18/06/2020 à 13:15, Julien Lepiller a écrit :

Le 18 juin 2020 07:04:18 GMT-04:00, "Yves P."  a écrit :

Heu ? OsmAnd place les photos là où tu lui dit de les placer. Si

c'est mal localisé, c'est ta faute :p


Ou j'ai loupé quelque chose ?

On ne doit pas procéder de la même manière ?

Je randonne et j'appui sur le bouton prendre une photo.

__
Yves


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


Oui, mais pour "prendre une photo", il faut le faire sur un poi ou un point que 
tu places sur la carte avec un appui long. Si tu utilises les actions rapides, ça place 
le point au centre de la carte, mais tu peux la bouger avant de prendre la photo, pour 
qu'elle soit placée au bon endroit.

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



--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Julien Lepiller]

Le 18 juin 2020 07:04:18 GMT-04:00, "Yves P."  a écrit :
>> Heu ? OsmAnd place les photos là où tu lui dit de les placer. Si
>c'est mal localisé, c'est ta faute :p
>> 
>> Ou j'ai loupé quelque chose ?
>On ne doit pas procéder de la même manière ?
>
>Je randonne et j'appui sur le bouton prendre une photo.
>
>__
>Yves
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

Oui, mais pour "prendre une photo", il faut le faire sur un poi ou un point que 
tu places sur la carte avec un appui long. Si tu utilises les actions rapides, 
ça place le point au centre de la carte, mais tu peux la bouger avant de 
prendre la photo, pour qu'elle soit placée au bon endroit.

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Yves P.]

> Heu ? OsmAnd place les photos là où tu lui dit de les placer. Si c'est mal 
> localisé, c'est ta faute :p
> 
> Ou j'ai loupé quelque chose ?
On ne doit pas procéder de la même manière ?

Je randonne et j'appui sur le bouton prendre une photo.

__
Yves


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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Julien Lepiller]

Le 18 juin 2020 04:21:02 GMT-04:00, "Yves P."  a écrit :
>>> Je m'en suis servi hier, j'ai des photos assez mal localisées.
>> 
>>> Je fais un glisser-déplacer directement des photos dans JOSM.
>> 
>>> Faut-il plutôt charger la trace comme dans OSMTracker ?
>> 
>> Tu auras la même précision : celle du GPS.
>Pas forcément ;)
>
>Certains logiciels laisse faire l'application "appareil photo"
>d'Android pour stocker les coordonnées GPS dans les données EXIF.
>Hors elle utilise un filtre (les dernières photos sont toutes à la même
>position) ☹️
>
>Dans ce cas, le coordonnées de la photo dans la trace GPX de
>l'application sont différentes des coordonnées EXIF (et bien
>meilleures).
>
>__
>Yves
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

Heu ? OsmAnd place les photos là où tu lui dit de les placer. Si c'est mal 
localisé, c'est ta faute :p

Ou j'ai loupé quelque chose ?

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

Re: [Talk-it] Compresenza addr street e place

[Andrea Musuruane]

Ciao,

On Thu, Jun 18, 2020 at 12:39 PM Damjan Gerl  wrote:

> Forse si, forse no... Le cose che mi hanno portato a non usarlo sono:
> - la regola che in addr:city si mette il comune (quindi Trieste)
> - se metto addr:city=Opicina per lo stesso cap (34151) mi trovo anche
> altri addr:city=Trieste per Barcola (place=suburb), perché lo stesso cap è
> usato anche in Trieste città.
>
> Quindi capito che addr:place è da togliere, cosa usiamo?
> o solo addr:city=Opicina / Opčine
> o addr:city=Trieste  + addr:town=Opicina / Opčine
>
> Io sarei per quest'ultimo..
>

Cerco di fare un po' di chiarezza.

In Italia gli indirizzi si assegnano a livello comunale. Quindi è errato
mettere un addr:city diverso dal nome del comune in cui si trova
l'indirizzo.

A volte capita ancora, anche se l'attuale normativa lo esclude
esplicitamente, di avere odonimi uguali in differenti parti del comune (ad
esempio in due frazioni). In questo caso si usa addr:hamlet. Tralasciamo il
fatto che hamlet è un valore del tag place, così come city è un valore del
tag place, con una sua specificità. E' solo una nomenclatura.

Se proprio vuoi inserire lo stesso l'informazione su luogo in cui si
trovano anche se questa è inutile per la sua localizzazione, puoi usare
addr:hamlet.

Se si usano altri tag non documentati come addr:town (anche se usati: in
OSM può esistere qualsiasi tag, purtroppo), proprio perché non documentati,
hanno un significato ambiguo e non ci saranno data user che li useranno.

Ciao,

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

Re: [Talk-it] Compresenza addr street e place

[Damjan Gerl]

  
  
Martin Koppenhoefer je 17.6.2020 ob
  11:04 napisal:


  
  

  Am Mo., 15. Juni 2020 um
19:32 Uhr schrieb Federico Cortese :
  
  On Mon, Jun 15, 2020 at
7:18 PM Cascafico Giovanni  wrote:
>
> Io pensavo che addr:place risolvesse semplicemente
indirizzi senza via e senza preoccuparsi del luogo in cui
sono compresi. Devo quindi ogni volta valutare la classe del
luogo abitato? E se qualcuno lo cambia, p.es. da hamlet a village, che
ne è di tutti gli addr:hamlet?
  
  
  
  giusto per addr:place (come indicatore che l'indirizzo
non si basa su una strada), invece i tag addr:hamlet (ecc.)
sono meno chiari. 
  
   
  
Sì addr:place serve solo per indirizzi senza via, quindi in
generale è
giusto toglierlo dove la via c'è già in addr:street.
Se invece addr:place è stato usato per metterci il nome del
paese,
frazione o simili, puoi sostituirlo con addr:hamlet,
indipendentemente
da come è taggato il place.
Infatti come già ha spiegato Andrea non esistono altri tag
addr:town
addr:village ecc.



a dire la verità, esistono anche questi tags, ma con molto
  meno usi:
43.000 addr:town
147.000 addr:village
222.000 addr:neighbourhood

423.600 addr:hamlet
5,7 milioni addr:suburb


Guardando la mappa, mi sembra che si tratta di un centro
  abitato distinto (non è tutto uno, morfologicamente, con
  Trieste), perciò dal livello morfologico è meno indicato
  "suburb".
Sono un po' indeciso, visto che "hamlet" non sembra adatto
  come tag (troppo grande, taggato come place=town). Direi di
  decidersi tra addr:town e addr:suburb


  

Si, è un centro abitato distinto, non un suburb. Perciò potrebbe
andare bene addr:town


  
Non conoscendo la situazione, se si mettesse
  "addr:city=Opicina", sarebbe sbagliato?
  


Forse si, forse no... Le cose che mi hanno portato a non usarlo
sono:
- la regola che in addr:city si mette il comune (quindi Trieste)
- se metto addr:city=Opicina per lo stesso cap (34151) mi trovo
anche altri addr:city=Trieste per Barcola (place=suburb), perché lo
stesso cap è usato anche in Trieste città.

Quindi capito che addr:place è da togliere, cosa usiamo?
o solo addr:city=Opicina / Opčine
o addr:city=Trieste  + addr:town=Opicina / Opčine

Io sarei per quest'ultimo...


  Ciao
Martin

  


Ciao
Damjan
  


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

[Talk-at] Irreführendes Nominatim-Ergebnis

[Florian Ledermann]

Liebe Community,

hat einer für euch eine Erklärung, warum eine Suche bei Nominatim nach 
"Schelleingasse 8" als erstes Ergebnis die Node "Alois-Drasche-Park 8" 
liefert?


https://nominatim.openstreetmap.org/search.php?q=schelleingasse+8

Die Address-Node, die hier als erstes geliefert wird, ist in OSM korrekt 
als "Alois-Drasche-Park 8" getagged, von Schelleingasse ist dort keine 
Rede. Dennoch wird im Nominatim-Ergebnis die Straße der Ergebnis-Node 
als "Schelleingasse" angezeigt. Das 2. Nominatim Ergebnis ist dann das 
korrekte Haus, leider ist es schwer das automatisiert zu erkennen da das 
erste Ergebnis bereits als Node "Schelleingasse 8" zurückgeliefert wird.


Ich konnte ein solches Ergebnis mit keiner anderen Adressen im 4. Bezirk 
reproduzieren, auch die anderen Adressen in der Schelleingasse liefern 
das erwartete (korrekte) Ergebnis. Auffällig ist allerdings noch, dass 
Adress-Nodes im Alois-Drasche-Park von Nominatim anscheinend generell 
nicht gefunden werden (z.B. 
https://nominatim.openstreetmap.org/search.php?q=Alois-Drasche-Park+8 ) 
- keine Ahnung ob das etwas damit zu tun hat...


Ich würde gerne das Tagging verbessern, so dass das 1. Ergebnis in 
Nominatim die korrekte Adresse liefert, habe aber keine Idee wie ich das 
machen sollte, da das Tagging der Adresse mir korrekt erscheint.


Wäre also über einen Hinweis oder Erklärung dankbar!

LG Florian


--
Dipl.-Ing. Florian Ledermann
Cartography Research Group
Department of Geodesy and Geoinformation
TU Wien, Vienna, Austria

http://cartography.tuwien.ac.at/florian-ledermann/
https://twitter.com/floledermann

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

Re: [OSM-talk-fr] Fontaine fleurie

[Marc M.]

auqul on peux ajouter flowers=yes
même s'il manque sans doute un tag principal genre
landuse=flowerbed
landuse=meadow (pas trop du tout)
leisure=garden garden:style=flower_garden (micro-mapping ?)

Le 18.06.20 à 10:26, European Water Project a écrit :
> Je dirai ...  abandoned:amenity
> =fountain
> .
>  
> qui n'empêche pas quelqu'un qui veut rendre des fontaines ornementales
> sur une carte .
> 
> voici deux catégories où tu pourrais peut-être mettre cette photo :
> 
> https://commons.wikimedia.org/wiki/Category:Defunct_fountains  
> 
> https://commons.wikimedia.org/wiki/Category:Former_fountains  
> 
> 
> 
> On Wed, 17 Jun 2020 at 21:07, Yves P.  > wrote:
> 
> Bonsoir,
> 
> Comment taguer une fontaine remplie de terre et ornée de fleurs
> 
> 
>  ?
> 
> Il n'y a rien dans le wiki, je ne trouve pas non de catégorie dans
> Wikimedia (quel est le nom en anglais).
> 
> amenity=fountain seulement va dépiter les cyclistes et randonneurs
> assoiffés cet été :D
> disused:amenity=fountain va empêcher le rendu. Avec ou sans eau,
> c'est un bon point de repère…
> 
> __
> 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
> 


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

Re: [Talk-GB] Status of Potlatch 2

[Mateusz Konieczny via Talk-GB]

Jun 18, 2020, 10:57 by nathanc...@outlook.com:

>
> Hi all,
>
>
>  
>
>
> Possibly not the correct place to raise this but I was wondering if anyone 
> knew what the plans for Potlatch 2 are?
>
>
https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Potlatch_2_for_desktop

> Where is best to raise this, if not here?
>
It was possible to comment on and support microgrant proposals but deadline for 
that ended.

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

[Talk-GB] Status of Potlatch 2

[nathan case]

Hi all,

Possibly not the correct place to raise this but I was wondering if anyone knew 
what the plans for Potlatch 2 are?

Adobe Flash will be unsupported from 31 December 2020 
(https://www.adobe.com/products/flashplayer/end-of-life.html) . On, or around 
this date, Flash support will be completely removed from Firefox 
(https://developer.mozilla.org/en-US/docs/Plugins/Roadmap), Chrome 
(https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/), and 
Edge 
(https://support.microsoft.com/en-in/help/4532571/microsoft-edge-turn-on-flash) 
 (where it is already turned off by default).

With the major browsers no longer supporting Flash after this date, and 
Potlatch currently relying on Flash, it seems like Potlatch will no longer be 
accessible?

Are there plans to transition from Flash, or to retire it completely from OSM? 
Where is best to raise this, if not here?

Cheers,

Nathan


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

Re: [talk-au] How to tag plantations?

[Little Maps]

Many thanks Warin, that seems much more variable in Vic, esp in Gippsland where 
natural=wood is a common tag for areas tagged as State Forests. Plantations in 
SW Vic are quite a mix. I wonder if it’s worth adding a section to the Aus 
tagging guidelines page to specify a preferred usage for landuse=forest and 
natural=wood, and perhaps other vegetation tags? I’d be happy to draft some 
text if more seasoned mappers were happy to comment and edit it. Thanks again 
Ian
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] open-orthos: 3 départements de plus: 27, 53, 76...

[Christian Quest]

Je pense qu'on est en dessous d'1m, mais je ne trouve pas l'info et 
comme le site "pro" de l'IGN est indisponible depuis décembre, difficile 
de mieux répondre.



Le 18/06/2020 à 10:14, Denis Bigorgne a écrit :

Merci, mais plus précisément : 1m, 3m, 5m ?
Ce sont des précisions qu'on peut atteindre avec les GPS actuels, et 
on est un peu dans l'incertitude quand on veut porter un POI dans la 
nature et qu'il y a contradiction entre le GPS et l'orthophoto ( à 
droite ou à gauche du sentier ? Qu'est ce que je rectifie : le POI ou 
le sentier ? )



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Fontaine fleurie

[European Water Project]

Je dirai ...  abandoned:amenity
=fountain

.  qui n'empêche pas quelqu'un qui veut rendre des fontaines ornementales
sur une carte .

voici deux catégories où tu pourrais peut-être mettre cette photo :

https://commons.wikimedia.org/wiki/Category:Defunct_fountains

https://commons.wikimedia.org/wiki/Category:Former_fountains



On Wed, 17 Jun 2020 at 21:07, Yves P.  wrote:

> Bonsoir,
>
> Comment taguer une fontaine remplie de terre et ornée de fleurs
> 
>  ?
>
> Il n'y a rien dans le wiki, je ne trouve pas non de catégorie dans
> Wikimedia (quel est le nom en anglais).
>
> amenity=fountain seulement va dépiter les cyclistes et randonneurs
> assoiffés cet été :D
> disused:amenity=fountain va empêcher le rendu. Avec ou sans eau, c'est un
> bon point de repère…
>
> __
> 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] Cartopartie : comment relever efficacement les horaires des commerces ?

[Yves P.]

>> Je m'en suis servi hier, j'ai des photos assez mal localisées.
> 
>> Je fais un glisser-déplacer directement des photos dans JOSM.
> 
>> Faut-il plutôt charger la trace comme dans OSMTracker ?
> 
> Tu auras la même précision : celle du GPS.
Pas forcément ;)

Certains logiciels laisse faire l'application "appareil photo" d'Android pour 
stocker les coordonnées GPS dans les données EXIF.
Hors elle utilise un filtre (les dernières photos sont toutes à la même 
position) ☹️

Dans ce cas, le coordonnées de la photo dans la trace GPX de l'application sont 
différentes des coordonnées EXIF (et bien meilleures).

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

Re: [OSM-talk-fr] Cartopartie : comment relever efficacement les horaires des commerces ?

[Jacques Lavignotte]

Le 18/06/2020 à 10:06, Yves P. a écrit :


Je m'en suis servi hier, j'ai des photos assez mal localisées.



Je fais un glisser-déplacer directement des photos dans JOSM.



Faut-il plutôt charger la trace comme dans OSMTracker ?


Tu auras la même précision : celle du GPS.

Qu'attends-tu pour installer une station de base Gnns ??

;)

J.
--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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

Re: [OSM-talk-fr] open-orthos: 3 départements de plus: 27, 53, 76...

[Denis Bigorgne]

Merci, mais plus précisément : 1m, 3m, 5m ?
Ce sont des précisions qu'on peut atteindre avec les GPS actuels, et on est
un peu dans l'incertitude quand on veut porter un POI dans la nature et
qu'il y a contradiction entre le GPS et l'orthophoto ( à droite ou à gauche
du sentier ? Qu'est ce que je rectifie : le POI ou le sentier ? )


Le mer. 17 juin 2020 à 10:07, Christian Quest  a
écrit :

> Le 17/06/2020 à 09:11, Denis Bigorgne a écrit :
> > Bonjour, une question : quelle est la précision du calage de la BD
> > Ortho - en plaine ?
> > Et aussi : comment faire apparaître les limite du cliché, pour un
> > éventuel recalage ?
> >
> En plaine elle est très bonne, vu que l'ortho-rectification est facile
> vu que le terrain est plat.
>
> C'est en montagne que c'est moins bon, mais la BD Ortho (et l'OrthoHR)
> est très bien calée et n'a pas besoin d'être recalée.
>
> Il faut juste se méfier de la parallaxe sur les toits des bâtiments,
> sinon, au niveau du sol c'est tout bon.
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] Cartopartie : comment relever efficacement les horaires des commerces ?

[Yves P.]

> Bonjour,
> Pour des relevés terrain, je faisais également plusieurs photos dans un ordre 
> précis. Mais l'utilisation de OsmAnd me parait etre une fort bonne idée pour 
> plus de précisions.
Je m'en suis servi hier, j'ai des photos assez mal localisées.
Je fais un glisser-déplacer directement des photos dans JOSM.

Est-ce que j'ai louper quelque chose ?
Faut-il plutôt charger la trace comme dans OSMTracker ?

> D'ailleurs à ce sujet, lorsque vous faites "Ajouter une action", je ne vois 
> nulle part écrit nouvelle photo ? 
Configurer l'écran → Action rapide → Ajouter une action → Nouvelle note photo

Il est possible de faire aussi comme ça :
Configurer l'écran → Panneau de droite  → Notes audio/vidéo, puis 
éventuellement Prendre une photo

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

Re: [OSM-talk-fr] Comment tagguer plusieurs caméras de vidéosurveillance sur un poteau

[Marc M.]

Bonjour,

Le 18.06.20 à 06:28, Quentin Salles a écrit :
> un poteau dans lequel 4 caméras sont posés dessus.
> Chacune de ces caméras cible différentes directions.

camera:direction =valeur1;valeur2;valeur3;valeur4
devices=4

Cordialement,
Marc

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

Re: [OSM-ja] 郡名の英語表記について

[batosm]

「County」の統一に賛成です。USのAdmin
LevelではDistrictは複数のレベルに存在します。CountyであればStateの下になるので、都道府県の下になる日本の群と同一の運用が出来ると思います。

2020年6月18日(木) 13:32 OKADA Tsuneo :

> 岡田です。
>
> wikiのJapan taggingにも関わることですので、こちらに相談します。
> https://wiki.openstreetmap.org/wiki/Japan_tagging
>
> 最近地名の英語表記を確認してまして、その中で郡名の英語表記が気になりました。
> (安芸郡とか諏訪郡とかの郡)
>
> wikiでは「郡」の英名は「District」としていますが、
>  国土地理院の「 地名等の英語表記規程 」(平成28年3月)の第14条では「郡」の英名は「County」を使うとなっています。
> https://www.gsi.go.jp/common/000138865.pdf
>
> 実際の郡名のOSMの登録データのname:enを見ると、CountyとDistrictが混在しています。
> 国土地理院の規程に従ってCountyに統一したらいいのではと思いますが、いかがでしょうか？
> placeタグの値もcountyで一致するのですっきりします。
>
> 昔は「郡」の英訳は「District」でしたっけ？
> そんなような記憶もありますし、wikipediaの「郡」の項には「District」と訳すとも書いていましたので。。
>
> 郡名はあまりOSMで目立たないので気にする人も少ないかもしれませんが。。
>
> ご意見下さい。
>
> --
> 岡田常雄(OKADA Tsuneo)
> tsuneo.ok...@gmail.com
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [talk-au] How to tag plantations?

[Warin]

Within NSW landuse=forest is used for areas that produce things for human use 
e.g. timber.
Usually there are operated by Forestry Corporation of NSW, there are some 
privately operated areas too.
I should try to mark these with operator=Forestry Corporation of NSW or 
access=private for those privately operated.

If it is an area of trees then natural=wood is a good tag.

Note that landuse=forest may not all ways have trees e.g. just after harvest.

Other tags can be used for either of the above main tags including:
leaf_type=broadleaved
leaf_cycle=evergreen
species=*

Be careful in describing areas of trees as one type or another, near me to a 
casual observer looks to be eucalyptus but there is also somecasuarina, so it 
is really mixed broad and narrow leafed.


On 17/6/20 7:48 pm, Little Maps wrote:

Hi folks, I’m planning on mapping tree cover in an area with lots of pine and 
eucalypt plantations as well as native forests, and want to check on the 
preferred way of tagging plantations in Australia before I begin.

I realise that plantations don’t render in the standard OSM render and that 
there’s no international consensus on landuse=forest vs natural=wood etc, but 
see that as beside the point. There are so few plantations mapped as such in 
eastern Australia that it should be reasonably easy to develop a consistent 
approach. Do you think the following method is optimal to distinguish the three 
forest types?

1. Native eucalypt forests (not plantations, may or may not be used for 
forestry):

natural=wood
leaf_type=broadleaved
leaf_cycle=evergreen (somewhat superfluous in Aus but comprehensive)
source:geometry... etc.

2. Pine plantations (invariably Pinus radiata in my region)

natural=wood
plantation=yes
leaf_type=needleleaved
leaf_cycle=evergreen (again superfluous in Aus but comprehensive)

3. Hardwood plantations (mostly blue gum here)

natural=wood
plantation=yes
leaf_type= broadleaved
leaf_cycle=evergreen (again superfluous in Aus but comprehensive)

Thus, “plantation=yes” distinguishes plantations from natural forests, and 
leaf_type=broadleaved vs needleleaved distinguishes pine from euc plantations.

According to Taginfo, all existing tags for “plantation=yes” in Australia 
(about 1200 of them, and nearly all in WA) use “landuse=forest” and none use 
“natural=wood”. However I’m assuming that this group prefers to use 
“natural=wood” over “landuse=forest” - but I may be wrong.

Thanks once again for your helpful advice. Best wishes Ian




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

Re: [Talk-it] Fwd: [Osm] importazione dati in OpenStreetMap

[Francesco Ansanelli]

Il mer 17 giu 2020, 11:27 Martin Koppenhoefer  ha
scritto:

> Am So., 14. Juni 2020 um 11:10 Uhr schrieb Francesco Ansanelli <
> franci...@gmail.com>:
>
>> ...
>> Quello che manca, oggi, è un collegamento tra la "struttura OSM" ed i
>> "detentori del dato". ...
>>
>
>
> il "detentore" del dato siamo noi. In OSM collezioniamo dati nostri, che
> abbiamo raccolti noi. I fonti strutturati esterni possono essere utili per
> confrontarci, ma non possono sostituire la raccolta nostra dei dati.
>

Giusto, ma con "detentore" intendevo del dataset esterno, ovvero l'ente
pubblico ovvero altro "collezionista".
Anche secondo me il dato OSM è più importante, ma c'è un limite oggi: manca
la precisione con cui si è rilevato il dato.
A Cuneo ho inserito moltissimi numeri civici e l'ho fatto da telefono...
Probabilmente la precisione (anche se non è importante averla al
centimetro) sarà inferiore a quella che può avere il comune all'interno del
proprio sistema GIS. Se dovessi fare un ipotetico import, credo ne vada
tenuto conto.
Francesco


> Ciao
> Martin
> ___
> 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

[Talk-it] R: Fwd: [Osm] importazione dati in OpenStreetMap

[canfe]

I pompieri funzionano bene perché c’è un nucleo odi pagati e una comunità di 
volontari.
Cosi’ le varie Croce Rosse.
Ma guardando vicino a noi c’e’ … WAZE che ha lo stesso tipo di struttura.

 

Semplicemente il modello funziona.


Ora, senza cadere nei ‘distinguo’ mi preme porre l’attenzione che progetti su 
ampia scala necessitano di qualcuno che sia ‘obbligato’ a finirli, sennò 
rimangono incompleti per tempi lunghissimi, oppure non si riescono ad eseguire 
in tempi da emergenza.

 

Le varie e giustissime preoccupazioni evidenziate da tanti scriventi si possono 
superare con selezione del personale e corsi di abilitazione.
Esattamente come fanno i tre esempi sopra citati.

 

Cantone Ferruccio (canfe)

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