[talk-cz] WeeklyOSM CZ 509

[Tom Ka]

Ahoj, je dostupné vydání 509 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/13090

* Vtípek v datech.
* Vodstvo Šípské Fatry.
* Neviditelný chodník pro louky.
* Cesty pro horská kola.
* Motocyklová taxi.
* FR elektřina v OSM.
* GoPro a 3D mapování.
* Tagování MHD.
* Série geomob.
* Typický OSM mapper.
* Ceny OSM Award.
* HOT proti COVID-19.
* Aktualizace dlaždic.
* Novinky Overpass API.
* Tasking manager v4.
* OSM mapy v Drupalu.
* Prázdné ulice Moskvy.

Pěkné počtení ...

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

Re: [OSM-talk-fr] Fwd: Rapport du Président OSMF (était : [Osmf-talk] Summary Report on OSMF Chair's Outreach Jan-early Apr 2020)

[Philippe Verdy]

Cela ne réglera pas les discordances ou conflits intra-communautaires ou
intercommunautaires, mais ils ne devraient pas avoir d'effet sur les
fondations, et l'effet sur les organes de gouvernance sera limité : cette
gouvernance élargie peut fonctionner, indépendamment des fondations et des
communautés: on a toujours 3 grandes parties donc (les fondation(s)
fusionnées en une mais nécessaire à l'identité légale et réduite au minimum
mais employant aussi le personnel, les nombreuses communautés réunies, et
la gouvernance paritaire, chacun des 3 ensembles avec leurs pouvoirs et
missions et leurs propres conflits internes à régler avec des systèmes de
décision propre à chaque partie). Cet équilibre des 3 ensembles (qui
existent déjà dans les 2) offre beaucoup de garanties mais l'élargissement
garantie avant tout la stabilité et la pérennité de la fondation fusionnée.

Le jeu. 30 avr. 2020 à 04:02, Philippe Verdy  a écrit :

> Oui mais la Fondation OSM n'a pas les moyens (et notamment pas le
> personnel employé sous contrat et tenu à la neutralité vis-à-vis des
> contributeurs bénévoles). Les bénévoles existants sont trop peu nombreux,
> surchargés, pas disponibles dans un temps fiable.
> Et je ne parle que de la fusion des fondations, pas des projets qu'elles
> soutiennent, où il y aura toujours normalement la primauté des communautés
> bénévoles, il y aura aussi une participation des communauté dans les
> organes de gouvernance, où les fondations seules (ou leurs dirigeants) ne
> font pas la loi (sauf cas extrême imposé par la loi et où ces fondations
> doivent communiquer publiquement leurs décisions prises autant que possible
> aux organes de gouvernance qui eux ont leurs actions publiques).
>
> Le mer. 29 avr. 2020 à 21:13, Christian Rogel <
> christian.ro...@club-internet.fr> a écrit :
>
>>
>> > Le 29 avr. 2020 à 13:15, Philippe Verdy  a écrit :
>> > Au vu du constat, tout laisse penser que l'OSMF devrait se dissoudre et
>> carrément songer à une fusion avec la Fondation Wikimedia, qui est
>> nettement mieux structurée et peut remplir des objectifs similaires en
>> conservant l'esprit du projet mais avec une plus grande participation
>> communautaire. Cela résoudrait aussi bon nombre de problèmes administratifs
>> que l'OSMF est incapable de résoudre, et assurerait une meilleure
>> gouvernance et plus de transparence...
>>
>> En quoi, l’administration de Wikipedia serait plus efficiente ? Les
>> projets, malgré la formule convenue, sont hétérogènes.
>> Ce n’est pas parce que Wikipédia est intéressé par ce que produit OSM
>> qu’il peut souhaiter en assurer la gouvernance.
>> Ce serait un bien faible bénéfice à espérer, alors que la prise en main
>> par des universitaires et assimilés a eu pour effet d’éloigner une masse
>> énorme de rédacteurs.
>> Bref, La communauté wikipédienne et ses gardiens chaordonnés (chaordic
>> organization) ont, sûrement, d’autres préoccupations.
>> Que dire sur le rapport ? Justement, qu’on y retrouve, appliqué à
>> d’autres objets, les mêmes tensions, se résumant à des bagarres qui,
>> mettent implicitement en jeu des pouvoirs symboliques.
>> Chez nous, les bénévoles gardent ce pouvoir symbolique, car les
>> cartographes distants auront toujours du retard par rapport aux gens sur le
>> terrain.
>>
>> Christian R.
>> Membre de la Fondation OSM
>>
>> ___
>> 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] Fwd: Rapport du Président OSMF (était : [Osmf-talk] Summary Report on OSMF Chair's Outreach Jan-early Apr 2020)

[Philippe Verdy]

Oui mais la Fondation OSM n'a pas les moyens (et notamment pas le personnel
employé sous contrat et tenu à la neutralité vis-à-vis des contributeurs
bénévoles). Les bénévoles existants sont trop peu nombreux, surchargés, pas
disponibles dans un temps fiable.
Et je ne parle que de la fusion des fondations, pas des projets qu'elles
soutiennent, où il y aura toujours normalement la primauté des communautés
bénévoles, il y aura aussi une participation des communauté dans les
organes de gouvernance, où les fondations seules (ou leurs dirigeants) ne
font pas la loi (sauf cas extrême imposé par la loi et où ces fondations
doivent communiquer publiquement leurs décisions prises autant que possible
aux organes de gouvernance qui eux ont leurs actions publiques).

Le mer. 29 avr. 2020 à 21:13, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> > Le 29 avr. 2020 à 13:15, Philippe Verdy  a écrit :
> > Au vu du constat, tout laisse penser que l'OSMF devrait se dissoudre et
> carrément songer à une fusion avec la Fondation Wikimedia, qui est
> nettement mieux structurée et peut remplir des objectifs similaires en
> conservant l'esprit du projet mais avec une plus grande participation
> communautaire. Cela résoudrait aussi bon nombre de problèmes administratifs
> que l'OSMF est incapable de résoudre, et assurerait une meilleure
> gouvernance et plus de transparence...
>
> En quoi, l’administration de Wikipedia serait plus efficiente ? Les
> projets, malgré la formule convenue, sont hétérogènes.
> Ce n’est pas parce que Wikipédia est intéressé par ce que produit OSM
> qu’il peut souhaiter en assurer la gouvernance.
> Ce serait un bien faible bénéfice à espérer, alors que la prise en main
> par des universitaires et assimilés a eu pour effet d’éloigner une masse
> énorme de rédacteurs.
> Bref, La communauté wikipédienne et ses gardiens chaordonnés (chaordic
> organization) ont, sûrement, d’autres préoccupations.
> Que dire sur le rapport ? Justement, qu’on y retrouve, appliqué à d’autres
> objets, les mêmes tensions, se résumant à des bagarres qui, mettent
> implicitement en jeu des pouvoirs symboliques.
> Chez nous, les bénévoles gardent ce pouvoir symbolique, car les
> cartographes distants auront toujours du retard par rapport aux gens sur le
> terrain.
>
> Christian R.
> Membre de la Fondation OSM
>
> ___
> 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] Let's talk Attribution

[Martin Koppenhoefer]

sent from a phone

> On 29. Apr 2020, at 23:17, Kathleen Lu  wrote:
> 
> Mapbox also has a whitelabling option for customers to remove the logo from 
> Mapbox tiles. But again, we're talking about the tile service. It would be 
> quite reasonable for OSM to add a logo to the OSM tiles and make keeping that 
> logo on there a condition of using OSM tiles. 
> Separately, it *is* possible to use certain Mapbox data without using Mapbox 
> tiles.


actually you even have to put a mapbox logo on the map if you show your own 
data, hosted by mapbox:
https://docs.mapbox.com/help/how-mapbox-works/attribution/

Maps using Mapbox map designs or data supplied by Mapbox must display both the 
Mapbox wordmark and text attribution. 

You must also display the Mapbox wordmark if your map uses a custom style or 
custom data hosted by Mapbox.



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

Re: [OSM-talk] Let's talk Attribution

[Robert Whittaker (OSM lists)]

On Wed, 29 Apr 2020 at 11:22, Christoph Hormann  wrote:
> And what i have also said several times before is that the only way you
> can consistently interpret the ODbL attribution requirement - what
> Martin quoted as:
>
> „You must include a notice associated with the Produced Work reasonably
> calculated to make any Person that uses, views, accesses, interacts
> with, or is otherwise exposed to the Produced Work aware that Content
> was obtained from the Database,...“
>
> is in the way that the determination if any Person that uses, views,
> accesses, interacts with, or is otherwise exposed to the Produced
> Work becomes aware that Content was obtained from the Database from the
> attribution provided needs to *be based on reason*.  So far no one has
> even attempted to explain the reasoning behind the expectation that a
> user of an application with hidden attribution becomes aware that
> Content was obtained from the Database.

Indeed. To put this another way -- and a lot of people seem to be
mis-understanding this -- whatever attribution an OSM licensee chooses
to employ, the licensee needs to be able to make a reasonable argument
that *every* user who views, interacts with, etc the produced work
will become aware that the content has come from OSM. Not just some
users, or those that choose to go looking for the data source, but
every user. The "reasonable" does not refer to how good the
attribution needs to be, or the expectation/ease of each user finding
it, or the space it takes up on the screen. It refers to the
calculation made by the licensee. The attribution must ensure -- in
the reasonable view of the licensee -- that every user will see it.

I fail to see how not showing a visible attribution to every user in
the normal course of their interaction with a produced work could
possibly be "reasonably calculated" to make everyone aware of the OSM
provenance. Hiding the attribution behind an "(i)" that you know most
users won't click on, or putting in on a splash screen that disappears
so quickly people won't get a chance to read it does not comply with
the ODbL in my opinion. I think we need to accept that this is what
our licence says, and take better steps to ensure licensees understand
this.

Robert.

-- 
Robert Whittaker

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

Re: [Talk-at] PLZ Import

[Robert Kaiser]

Mit allen diesen Mängeln, die hier angeführt sind, bin ich jedenfalls 
auch dafür, einen revert zu machen.


KaiRo


scubbx schrieb:

Mir scheint, dass die von geo_sch importierten Flächen aus einer
fraglichen Quelle (lizenztechnisch) stammen und auch von der Qualität
nicht passen.
Bevor diese durch Bearbeitungen nicht mehr klar erkenntlich sind,
sollten diese reverted werden.

Was meint ihr?


Am 29.04.20 um 10:57 schrieb Johann Haag:

Aktuell entwickelt sich die Diskussion im OSM- Webforum gut.
https://forum.openstreetmap.org/viewtopic.php?pid=784826#p784826
Man sieht, dass Grafiken im Jahr 2020 zeitgemäß sind, und Bewegung in
eine Thematik bringen können.
Frage kann man den Talk- Mail Verteiler eventuell auf zeitgemäßes HTML
umstellen. ?

Grüße Johann Haag

Am Mo., 27. Apr. 2020 um 19:56 Uhr schrieb mailto:vari...@mailbox.org>>:

 Servus,

 Benutzer wurde angeschrieben mit ein paar Fragen und auf die
 Mailingliste und/oder auf das Forum hingewiesen. beautifulplaces
 hat auch ein (imho unnötig schroffes) Changesetkommentar gemacht
 und im Forum in einem Thread was hinzugefügt diesbezüglich.

 Grüße

 andreas wecer mailto:andreas.we...@gmail.com>> hat am 27. April 2020 19:22
 geschrieben:


 "survey" ist jedenfalls eine tolle Quelle für einen
 österreichweiten PLZ-Import und "POSTCODE" kein korrekter key

 Am Mo., 27. Apr. 2020 um 17:41 Uhr schrieb Thomas Rupprecht <
 rupprecht.tho...@gmail.com >:

 Hallo,

 geo_sch  hat
 heute einiges an PLZ Polygonen importiert. Der import sieht
 aber nicht sehr durchdacht aus. Ich hätte auch nichts von
 einer Diskussion über so einen Import mitbekommen.

 Kann sich das noch wer andere ansehen?

 Beispiel changelog:
 https://www.openstreetmap.org/changeset/84206322

 mfg Thomas Rupprecht
 ___
 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

 ___
 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


___
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-de] Gewichtung der Straßen im Routing

[Richard]

On Wed, Apr 29, 2020 at 03:52:51PM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 29. Apr 2020, at 13:12, Volker Schmidt  wrote:
> > 
> > Ich halte das mit maxspeed:practical fuer eine ziemliche Kruecke.
> 
> 
> +1, und schlecht verifizierbar (für welche Fahrzeugart ist das denn gedacht? 
> Geht es um verantwortliches Fahren oder um das physische Limit?

schon mal die Doku gesehen? Natürlich für jede Fahrzeugart separat taggen.

> > Habe mich mal umgeschaut, und die meisten Beispiele, die ich gefunden habe,
> > waren Strassen, wo fast alle relevanten tags fehlten:
> > lanes, width, surface, incline, oneway, smoothness, lit
> > Ich halte es fuer besser den Strassenzustand zu beschreiben, und dem Router
> > zu ueberlassen,  was er daraus macht (auch mit der Analyse der Geometrie),
> > als mit fiktiven Werten eine erwuenschtes Verhalten zu errreichen.
> 
> 
> 
> wobei es auch Faktoren wie kurze Sichtweite gibt, die man automatisch nicht 
> feststellen kann.

+1

ich denke man kann das auch übertreiben mit den ganz viele tags die den 
Strassenzustand 
beschreiben sollen. 
Momentan fehlt m.W. jegliche Systematik, Erfahrungen und Vergleichswerte wie 
sich das auf das
Routing auswirken sollte, insbesondere in den vielfältigen Kombinationen mit 
Straßen/wegetypen.
 
Beleuchtung? Gibt es im Wohngebiet, auf Stadtautobahnen oder verlassenen 
Parkwegen, was 
soll ein Router sinnvolles daraus zaubern..
Die ganzen surface, smoothness, incline tags können meiner Erfahrung nach nur 
in 
Ausnahmefällen etwas zum guten Routing beitragen. Eine Autobahn sollte z.B. 
eine 
"schlechtere" smoothness haben als eine kleine Straße im Wohngebiet.

Und solange die allermeisten Straßen linear eingezeichnet sind - also nicht als 
Fläche hilft 
die Analyse der Geometrie auch nur begrenzt.. und andernfalls wäre die Analyse 
vermutlich
aus Gründen der Komplexität nicht durchführbar.

Richard

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

Re: [OSM-talk] Let's talk Attribution

[Kathleen Lu via talk]

You and Alexandre are correct that Google does not (usually) allow you to
use their data off of their platform. According to Google's Terms, you
usually cannot use just the data and not the tile server. Google does,
however, make exceptions for paying customers.

Mapbox also has a whitelabling option for customers to remove the logo from
Mapbox tiles. But again, we're talking about the tile service. It would be
quite reasonable for OSM to add a logo to the OSM tiles and make keeping
that logo on there a condition of using OSM tiles.
Separately, it *is* possible to use certain Mapbox data without using
Mapbox tiles. Mapbox employees have contributed to OSM for years. That data
belongs to Mapbox but is shared with the world through OSM and ODbL.
Attribution for that doesn't appear on-map unless the user is also using
Mapbox tiles.

The key difference between data and tiles is that one can use hundreds of
data sources in one map, but only one or a handful of service providers for
tiles, geocoding, etc. Both user expectations and reasonableness depend on
context.

-Kathleen

On Wed, Apr 29, 2020 at 5:01 AM Martin Koppenhoefer 
wrote:

> Am Mi., 29. Apr. 2020 um 04:05 Uhr schrieb Kathleen Lu <
> kathleen...@mapbox.com>:
>
>> I absolutely agree that looking at industry standard seems a good
>> indication of what is reasonable.
>> ...After researching this question, I found no commercial data provider
>> that required data attribution as prominently as the FAQ suggests. Industry
>> standard would suggest a *much* less strict interpretation of what is
>> "reasonable" under the ODbL.
>>
>
>
>
> I do have an example that comes to mind: imagine you use Google Geocoding.
> This obligates you to use the results in the Google ecosystem, and this has
> the requirement to display a Google logo on the map.
> Another example would maybe be mapbox? If you use data they have
> transformed, you will have to put a mapbox logo on the screen.
>
> Cheers
> Martin
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] Making bus lines more specific

[Mateusz Konieczny via Talk-transit]

Apr 28, 2020, 22:53 by mailingli...@iivq.net:

> Hello Robin,
>
> I highly agree with you.
> The main reason for PTv2 not having as widespread adoption as it could have 
> is that it is not rendered, that is to say, it is not rendered on OSM_carto 
> (Osmand's rendering of PTv2 is near-perfect).
>
Note that approved PTv2 proposal had explicit

"This proposal does not replace, deprecate or obsolete the already existing and 
well known tags. The usage of the proposed tags is recommended but not 
mandatory."

bus=yes was supposed to be added only to public_transport=stop_position

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport=625726#Platform

Following approved PTv2 proposal requires using highway=bus_stop to identify 
public_transport=platform as bus stop.


And public_transport=platform + bus=yes is neither approved nor more popular 
than highway=bus_stop.

And, at least in my opinion, it is also worse tagging scheme than simple 
highway=bus_stop.

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

Re: [OSM-talk] Let's talk Attribution

[Mateusz Konieczny via talk]

Apr 28, 2020, 06:48 by si...@poole.ch:

>
> Am 27.04.2020 um 19:49 schrieb Alexandre Oliveira:
>
>> Hello!
>>
>> I'll try to be brief and explain the main problems that exist with
>> OSM's way of handling lack of (proper) attribution.
>>
> There was just a (nearly 100 messages) long thread on the subject here 
> not to mention a longish consultation last year, with multiple in person
> sessions, which covered all the issues you touch on.
>

Is outcome of that discussions summarized anywhere?

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

Re: [Talk-at] PLZ Import

[scubbx]

Mir scheint, dass die von geo_sch importierten Flächen aus einer
fraglichen Quelle (lizenztechnisch) stammen und auch von der Qualität
nicht passen.
Bevor diese durch Bearbeitungen nicht mehr klar erkenntlich sind,
sollten diese reverted werden.

Was meint ihr?


Am 29.04.20 um 10:57 schrieb Johann Haag:
> Aktuell entwickelt sich die Diskussion im OSM- Webforum gut. 
> https://forum.openstreetmap.org/viewtopic.php?pid=784826#p784826
> Man sieht, dass Grafiken im Jahr 2020 zeitgemäß sind, und Bewegung in
> eine Thematik bringen können.
> Frage kann man den Talk- Mail Verteiler eventuell auf zeitgemäßes HTML
> umstellen. ?
>
> Grüße Johann Haag
>
> Am Mo., 27. Apr. 2020 um 19:56 Uhr schrieb  >:
>
> Servus,
>
> Benutzer wurde angeschrieben mit ein paar Fragen und auf die
> Mailingliste und/oder auf das Forum hingewiesen. beautifulplaces
> hat auch ein (imho unnötig schroffes) Changesetkommentar gemacht
> und im Forum in einem Thread was hinzugefügt diesbezüglich.
>
> Grüße
>> andreas wecer > > hat am 27. April 2020 19:22
>> geschrieben:
>>
>>
>> "survey" ist jedenfalls eine tolle Quelle für einen
>> österreichweiten PLZ-Import und "POSTCODE" kein korrekter key
>>
>> Am Mo., 27. Apr. 2020 um 17:41 Uhr schrieb Thomas Rupprecht <
>> rupprecht.tho...@gmail.com >:
>>
>> Hallo,
>>
>> geo_sch  hat
>> heute einiges an PLZ Polygonen importiert. Der import sieht
>> aber nicht sehr durchdacht aus. Ich hätte auch nichts von
>> einer Diskussion über so einen Import mitbekommen.
>>
>> Kann sich das noch wer andere ansehen?
>>
>> Beispiel changelog:
>> https://www.openstreetmap.org/changeset/84206322
>>
>> mfg Thomas Rupprecht
>> ___
>> 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
> ___
> 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
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] talk-at im HTML Format (Abgespalten aus PLZ Import)

[scubbx]

Obwohl es einige Male bereits verlockend gewesen wäre, finde ich HTML
für eine Mailingliste auch nicht angebracht.


Am 29.04.20 um 10:57 schrieb Johann Haag:
> Aktuell entwickelt sich die Diskussion im OSM- Webforum gut. 
> https://forum.openstreetmap.org/viewtopic.php?pid=784826#p784826
> Man sieht, dass Grafiken im Jahr 2020 zeitgemäß sind, und Bewegung in
> eine Thematik bringen können.
> Frage kann man den Talk- Mail Verteiler eventuell auf zeitgemäßes HTML
> umstellen. ?
>
> Grüße Johann Haag
>
> Am Mo., 27. Apr. 2020 um 19:56 Uhr schrieb  >:
>
> Servus,
>
> Benutzer wurde angeschrieben mit ein paar Fragen und auf die
> Mailingliste und/oder auf das Forum hingewiesen. beautifulplaces
> hat auch ein (imho unnötig schroffes) Changesetkommentar gemacht
> und im Forum in einem Thread was hinzugefügt diesbezüglich.
>
> Grüße
>> andreas wecer > > hat am 27. April 2020 19:22
>> geschrieben:
>>
>>
>> "survey" ist jedenfalls eine tolle Quelle für einen
>> österreichweiten PLZ-Import und "POSTCODE" kein korrekter key
>>
>> Am Mo., 27. Apr. 2020 um 17:41 Uhr schrieb Thomas Rupprecht <
>> rupprecht.tho...@gmail.com >:
>>
>> Hallo,
>>
>> geo_sch  hat
>> heute einiges an PLZ Polygonen importiert. Der import sieht
>> aber nicht sehr durchdacht aus. Ich hätte auch nichts von
>> einer Diskussion über so einen Import mitbekommen.
>>
>> Kann sich das noch wer andere ansehen?
>>
>> Beispiel changelog:
>> https://www.openstreetmap.org/changeset/84206322
>>
>> mfg Thomas Rupprecht
>> ___
>> 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
> ___
> 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
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] Progetto OsmGuineaBissau

[Nap Osm]

Bravi! 
Complimenti, mi piace molto questo vostro progetto! Siete stati anche molto 
bravi a documentare il tutto.
Spero vi siate divertiti a mappare 
Ancora complimenti!

From: 2021_Gabriele Uberto 
Sent: Wednesday, April 29, 2020 12:28 PM
To: talk-it@openstreetmap.org 
Subject: [Talk-it] Progetto OsmGuineaBissau


Buongiorno lista,

parlo in rappresentanza della classe 5^A dell’Istituto Tecnico Avogadro di 
Torino,

e volevo informarvi che stiamo portando avanti un progetto incentrato su OSM.

L’obiettivo è quello di mappare “da poltrona”  un villaggio situato in 
Guinea-Bissau.

Per presentare questo progetto e la classe, è stata creata una pagina Wiki.

Ogni studente ha creato degli account e i changeset  sono commentati con 
#IISAvogadro19 per riconoscere la fonte di mappatura.

Anche se in questi giorni come da decreto non siamo presenti a scuola, la 
classe sta continuando a lavorare al progetto.

Vi lascio di seguito il link alla pagina Wiki:

https://wiki.openstreetmap.org/wiki/OsmGuineaBissau_Avogadro

Inoltre alcuni studenti hanno anche creato un video presentazione del progetto, 
sia per farlo conoscere alla comunità, che per farlo aderire ad un concorso 
chiamato ‘Storie di alternanza’, vi lascio qui di seguito il link:

https://www.youtube.com/watch?v=lj0iqdUjjAA


Saluti,

Gabriele

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

Re: [Talk-at] PLZ Import

[Robert Grübler]

Robert Kaiser schrieb am 29. April 2020 21:14
>  Und Foren lese ich ein Mal in zwei Jahren ... nur Zeitverschwendung.

Beides hat seine Berechtigung, heute wie früher:
https://lists.openstreetmap.org/pipermail/talk-at/2013-October/006038.html

Aber html in Talk-Mails brauche ich auch nicht.

LG Robert


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

Re: [Talk-it] Modifiche massive nomi di strade in seguito a note anonime

[Marco Minghini]

Grazie a tutti per i commenti,
nel frattempo l'utente mcheck mi ha contattato chiedendo come può
collaborare costruttivamente. L'ho informato di questa discussione,
chiedendogli di unirsi e facendogli notare che le modifiche che ha fatto
non sono in linea nè con quello che c'è sul campo, nè con la wiki (che sono
le due soluzioni proposte in questa discussione) e sono quindi sbagliate a
prescindere, oltre al problema del vecchio nome cancellato (e non messo in
alt_name) e agli addr:street anch'essi modificati in modo non corretto.

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

Re: [Talk-at] PLZ Import

[Robert Kaiser]

Johann Haag schrieb:

Frage kann man den Talk- Mail Verteiler eventuell auf zeitgemäßes HTML
umstellen. ?


Hoffentlich nicht. Auf Grafiken kann man verlinken, wenn man will, aber 
meist braucht man sie nicht. Ich werfe HTML-E-Mails jedenfalls 
präferiert in den Spam-Ordner, wo sie meist hingehören. Und Foren lese 
ich ein Mal in zwei Jahren, weil es zu viel Arbeit ist, ständig die 
Anwendungen zu wechselns und div. Tabs zu öffenen und neu zu laden. 
Genausio sinnlos wie Social Media, nur Zeitverschwendung.


(Sorry für den Ton, aber ich passe mich einfach mal an Johanns Ton an, 
wenn ich auf ihn antworte.)


KaiRo


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

Re: [OSM-talk-fr] Fwd: Rapport du Président OSMF (était : [Osmf-talk] Summary Report on OSMF Chair's Outreach Jan-early Apr 2020)

[Christian Rogel]

> Le 29 avr. 2020 à 13:15, Philippe Verdy  a écrit :
> Au vu du constat, tout laisse penser que l'OSMF devrait se dissoudre et 
> carrément songer à une fusion avec la Fondation Wikimedia, qui est nettement 
> mieux structurée et peut remplir des objectifs similaires en conservant 
> l'esprit du projet mais avec une plus grande participation communautaire. 
> Cela résoudrait aussi bon nombre de problèmes administratifs que l'OSMF est 
> incapable de résoudre, et assurerait une meilleure gouvernance et plus de 
> transparence...

En quoi, l’administration de Wikipedia serait plus efficiente ? Les projets, 
malgré la formule convenue, sont hétérogènes.
Ce n’est pas parce que Wikipédia est intéressé par ce que produit OSM qu’il 
peut souhaiter en assurer la gouvernance.
Ce serait un bien faible bénéfice à espérer, alors que la prise en main par des 
universitaires et assimilés a eu pour effet d’éloigner une masse énorme de 
rédacteurs.
Bref, La communauté wikipédienne et ses gardiens chaordonnés (chaordic 
organization) ont, sûrement, d’autres préoccupations.
Que dire sur le rapport ? Justement, qu’on y retrouve, appliqué à d’autres 
objets, les mêmes tensions, se résumant à des bagarres qui, mettent 
implicitement en jeu des pouvoirs symboliques. 
Chez nous, les bénévoles gardent ce pouvoir symbolique, car les cartographes 
distants auront toujours du retard par rapport aux gens sur le terrain.

Christian R.
Membre de la Fondation OSM

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

Re: [OSM-talk-fr] [Revue de Presse] Article Ça reste ouvert dans le Progrès

[Florian LAINEZ]

En complément d'information, une revue de presse assez complète est tenue
sur la page https://blog.caresteouvert.fr/presse
On va rajouter cet article ! Merci

Le mer. 29 avr. 2020 à 20:27, Laurent Magréault 
a écrit :

> Bonsoir,
>
> Le Progrès a publié ce matin un article dans l'édition du Jura :
>
> https://www.leprogres.fr/economie/2020/04/28/caresteouvert-l-application-qui-vous-dit-ou-faire-vos-courses
>
> Un peu tardif et pas toujours fidèle dans la retranscription mais on prend
> quand même.
>
> ___)```)___
>
> Laurent Magréault
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

[OSM-talk-fr] [Revue de Presse] Article Ça reste ouvert dans le Progrès

[Laurent Magréault]

Bonsoir,

Le Progrès a publié ce matin un article dans l'édition du Jura :
https://www.leprogres.fr/economie/2020/04/28/caresteouvert-l-application-qui-vous-dit-ou-faire-vos-courses

Un peu tardif et pas toujours fidèle dans la retranscription mais on prend
quand même.

___)```)___

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

Re: [Talk-at] PLZ Import

[Johann Haag]

Aktuell entwickelt sich die Diskussion im OSM- Webforum gut.
https://forum.openstreetmap.org/viewtopic.php?pid=784826#p784826
Man sieht, dass Grafiken im Jahr 2020 zeitgemäß sind, und Bewegung in eine
Thematik bringen können.
Frage kann man den Talk- Mail Verteiler eventuell auf zeitgemäßes HTML
umstellen. ?

Grüße Johann Haag

Am Mo., 27. Apr. 2020 um 19:56 Uhr schrieb :

> Servus,
>
> Benutzer wurde angeschrieben mit ein paar Fragen und auf die Mailingliste
> und/oder auf das Forum hingewiesen. beautifulplaces hat auch ein (imho
> unnötig schroffes) Changesetkommentar gemacht und im Forum in einem Thread
> was hinzugefügt diesbezüglich.
>
> Grüße
>
> andreas wecer  hat am 27. April 2020 19:22
> geschrieben:
>
>
> "survey" ist jedenfalls eine tolle Quelle für einen österreichweiten
> PLZ-Import und "POSTCODE" kein korrekter key
>
> Am Mo., 27. Apr. 2020 um 17:41 Uhr schrieb Thomas Rupprecht <
> rupprecht.tho...@gmail.com>:
>
> Hallo,
>
> geo_sch  hat heute einiges an
> PLZ Polygonen importiert. Der import sieht aber nicht sehr durchdacht aus.
> Ich hätte auch nichts von einer Diskussion über so einen Import
> mitbekommen.
>
> Kann sich das noch wer andere ansehen?
>
> Beispiel changelog: https://www.openstreetmap.org/changeset/84206322
>
> mfg Thomas Rupprecht
> ___
> 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
>
> ___
> 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-de] Gewichtung der Straßen im Routing

[Georg Feddern]

Moin,

Am 29.04.2020 um 13:11 schrieb Volker Schmidt:

Ich halte das mit maxspeed:practical fuer eine ziemliche Kruecke.


+1 - leider, weil s.u.


Ich kann mir nicht vorstellen,
dass eine 4m breite Strasse in DE nicht Geschwindigkeits-begrenzt ist.


Oh, ich kann Dir diverse Beispiele nennen.

Diese 4 m breiten Straßen sind die ganz üblichen ländlichen und 
verkehrsschwachen Gemeindeverbindungsstraßen mit 90° Kurven und immer 
dem Bullen-Pi$$ ;-) nach am Feldrand lang gebaut.
Da lohnen sich keine Geschwindigkeitsbegrenzungsschilder - wer die 
Strecke nicht kennt, fährt da eh 'angemessen' vorsichtig und nutzt 
höchstens die Sichtweite aus - nur das junge Landvolk übertreibt es 
manchmal, weil 'gestern kam auch keiner'.


Damit gilt nun mal die offizielle rural maxspeed von 100, die nach 
allgemeiner Auffassung getaggt werden darf.
Ein Router mag noch die width berücksichtigen können - aber die 
geschwindigkeitsentscheidende Sichtweite kann er nichteinmal aus der 
Geometrie erschließen, weil sie auch vom Hoch und Runter sowie dem 
Rand-/Feldbewuchs abhängt.


Grüße
Georg

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

[talk-cz] NS v Praze Troji

[Tom Ka]

Ahoj, pri kontrolach Fody jsem narazil na
https://osm.fit.vutbr.cz/fody/?id=25729 a prilehle fotky naucnych
ceduli. V OSM je nejaka podle vseho uplne jina NS. Mohl by to nekdo
mistni zhlidnout a zkusit opravit podle reality - tj. bud je stara NS
zrusena a je tam "ted" nova, nebo jsou tam dve... Z gauce bez mistni
znalosti s tim nic moc neudelam.

Diky

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

Re: [Talk-de] Gewichtung der Straßen im Routing

[Martin Koppenhoefer]

sent from a phone

> On 29. Apr 2020, at 13:12, Volker Schmidt  wrote:
> 
> Ich halte das mit maxspeed:practical fuer eine ziemliche Kruecke.


+1, und schlecht verifizierbar (für welche Fahrzeugart ist das denn gedacht? 
Geht es um verantwortliches Fahren oder um das physische Limit?


> Habe mich mal umgeschaut, und die meisten Beispiele, die ich gefunden habe,
> waren Strassen, wo fast alle relevanten tags fehlten:
> lanes, width, surface, incline, oneway, smoothness, lit
> Ich halte es fuer besser den Strassenzustand zu beschreiben, und dem Router
> zu ueberlassen,  was er daraus macht (auch mit der Analyse der Geometrie),
> als mit fiktiven Werten eine erwuenschtes Verhalten zu errreichen.



wobei es auch Faktoren wie kurze Sichtweite gibt, die man automatisch nicht 
feststellen kann.


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

Re: [OSM-talk-fr] Liens depuis un tag dans JOSM (ex greffon Tag2Link)

[Philippe Verdy]

Si les bases de données ISIL sont gérées pays par pays avec une URL
spécifique, on pourrait envisager d'avoir "ref:isil:DE=DE-260" ou juste
"ref:isil:DE=260", ce qui résoud le problème de l'expression régulière, en
permettant à DataItem d'être configuré simplement avec une URL par pays
(une pour chaque type de balise "ref:isil:CC=*")
C'est une idée (en plus il est éventuellement possible qu'une même
bibliothèque "internationale" possède plusieurs références ISIL, une par
pays participant à l'institution, voire même aussi une "ref:isil:EU=*" si
c'est une bibliothèque européenne).
Certaines institutions bibliothécaires peuvent aussi avoir plusieurs fonds
séparés dont elles s'occupent (par exemple pour le dépôt légal reconnu dans
plusieurs pays simultanément mais effectué en un seul endroit, ou bien un
fond documentaire français dans une bibliothèque universitaire américaine
qui a une section dédiée, fonctionnant sur les termes du droit d'auteur
français et non le droit américain)


Le ven. 24 avr. 2020 à 16:25, Yves P.  a écrit :

> Bonjour,
>
> Je viens de découvrir qu'en plus des liens définis dans *Wikidata*, JOSM
> utilise les liens définis dans *DataItems* 
> https://josm.openstreetmap.de/wiki/Help/Action/Tag2Link
>
> Je viens de tester pour ref:isil
> , les
> expressions régulières ne sont pas (encore) prises en compte .
>
> Par exemple pour la bibliothèque allemande ISIL=DE-260, JOSM devrait
> proposer uniquement le lien vers l'agence allemande de gestion de l'ISIL :
> https://sigel.staatsbibliothek-berlin.de/nc/suche/?isil=DE-260
>
> __
> 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] Import of eBike Charging Stations in France

[Philippe Verdy]

For such import, it would be more valuable to just post some datafile (e.g.
some CSV file containing addresses) without the geocoding.

Then we could create a tack to validate each point with suggestion of
placement

E.g. the "Osmose" QA tool (widely used in France) can import such data
file, use its own legal geocoding based on OSM addresses from the joint
open "BANO" project where there's a cooperation between official French
public providers and OSM) and *propose* placements on the map, without
doing any import directly.

So please consider positing your data file (with enough fields for the
types of nodes that would allow their classification and tagging, with the
data you have about the kinds of charging stations, in addition to their
addresses in plain text) rather than making a mass import.

Such data file should not be very large (a few hundreds or thousands rows)
and is suitable for handling in the task lists implemented in French QA
tools. This strategy works well for lots of French data to integrate.
Osmose has a specific category named "To integrate" for such data.


Le sam. 25 avr. 2020 à 19:54, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> Le 25/04/2020 à 18:22, osm.sanspourr...@spamgourmet.com a écrit :
> >
> > It seems more logic to consider the charging station as part of the
> > hostel, amenity...
> > (charging_station=bicycle;charging_station:brand=Bosch eBike
> > PowerStation)
> >
> >
> I had also this feeling.
> We could imagine, the same way, a mass import of nespresso coffee
> dispensers or beverage vending machines, installed inside restaurants
> and cafés.
>
> Adding a service proposed by a restaurant like (charging_station=...)
> would be better.
>
>
> j'avais aussi cette impression en imaginant arriver des imports massifs
> de machines nespresso ou distributeurs de boissons installés dans les
> restos ou cafés.
> Ce n'est juste qu'un service offert par un resto et
> (charging_station=...) serait mieux.
>
> Georges
>
> ___
> 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] En regardant passer le train...

[Philippe Verdy]

En fait la situation est comparable à ce qui a été fait en Europe avec
l'import initial des données Corine pour la couverture naturelle: c'est un
premier jet, destiné à avoir une base de travail suffisante pour le
repérage de base et assurer une continuité territoriale minimale. Mais tout
import de ce type est ensuite à revoir dans le détail, et il ne faut pas
hésiter à "tailler dans le vif" (localement) ces données importées si on
veut améliorer les choses (mais sans tout effacer pour autant, ne le faire
que pour créer des données plus précises qui vont les remplacer avec un
degré de couverture au moins équivalent).

Le mer. 29 avr. 2020 à 15:01, Philippe Verdy  a écrit :

> Les US c'est très grand et bon nombre de voies ont été intégrées à la
> hâche à partir de données en assez basse résolution issues de bases de
> données publiques (imports TIGER) et les contributeurs locaux ne s'y sont
> pas intéressé partout de façon homogène, ils ont des tas d'autres zones à
> revoir et dans le milieu très rural, un tracé à la hâche suffit à la
> plupart des besoins actuels sans que cela donne trop d'erreurs de
> navigation pour trouver un chemin utilisable (et au moins ça assure la
> continuité du routage à longue distance).
> Evidemment on peut toujours améliorer ces données, mais comme le reste
> c'est un travail de fourni, pas évident à faire de façon homogène sur une
> surface aussi étendue avec finalement très peu de réutilisations locales,
> qui sont naturellement très concentrées dans les zones urbaines et les
> zones rurales les plus visitées.
> Ceci dit, la Russie a réussi à faire un niveau de détail excellent même
> sur ses immenses territoires ruraux.
> Le seul problème est donc d'intéresser les Américains à la cartographie
> libre de leurs espaces ruraux (OSM US n'est pas aussi actif que les
> chapitres européens, et les services commerciaux propriétaires sont bien
> plus présents sur nombre de sites, et sinon les sites gouvernementaux sont
> déjà très développés, souvent mieux qu'en Europe, pour plein de sujets, ce
> qui ne pousse pas beaucoup d'Américains à contribuer à OSM car ils n'en
> ressentent pas assez le besoin et se satisfont des solutions commerciales
> propriétaires et des sites gouvernementaux)
>
>
>
> Le dim. 26 avr. 2020 à 12:13, Eric SIBERT  a
> écrit :
>
>> En ces temps de confinement, on regarde n'importe quoi sur youtube:
>>
>> https://www.youtube.com/watch?v=9wT5O0k3vec
>>
>> Puis assez rapidement, je me demande où c'est dans OSM. Tiens, on voit
>> une voie ferrée dans la vidéo qui n'est pas dans OSM. Qu'est-ce qu'on a
>> comme source? Bing. C'est bien calé ça? Allons voir l'échangeur
>> autoroutier voisin. À voir les traces GPS et Mapillary, Bing est bien
>> calé. Par contre les bretelles de l'échangeur... :-(. D'ailleurs, il n'y
>> a pas que la position. Il y aussi le nombre de voies, les séparations de
>> bretelle et j'en passe, qui posent problème. Trop gros chantier. Je me
>> contente de rajouter la seconde voie ferrée.
>>
>> Puis sur la fin de la vidéo, il y a une route qui fait des zigzags le
>> long de la voie. Là, il y a eu des travaux, qu'on voit sur la vidéo. La
>> route a été reprofilée. Ça a été intégré dans OSM à la hache. Plus,
>> manque un pont. La relation de la route est restée sur le tronçon
>> désaffecté...
>>
>> Donc, la question: le réseau routier US dans OSM, c'est tout comme ça?
>>
>> Bon confinement.
>>
>> Eric
>>
>> ___
>> 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] En regardant passer le train...

[Philippe Verdy]

Les US c'est très grand et bon nombre de voies ont été intégrées à la
hâche à partir de données en assez basse résolution issues de bases de
données publiques (imports TIGER) et les contributeurs locaux ne s'y sont
pas intéressé partout de façon homogène, ils ont des tas d'autres zones à
revoir et dans le milieu très rural, un tracé à la hâche suffit à la
plupart des besoins actuels sans que cela donne trop d'erreurs de
navigation pour trouver un chemin utilisable (et au moins ça assure la
continuité du routage à longue distance).
Evidemment on peut toujours améliorer ces données, mais comme le reste
c'est un travail de fourni, pas évident à faire de façon homogène sur une
surface aussi étendue avec finalement très peu de réutilisations locales,
qui sont naturellement très concentrées dans les zones urbaines et les
zones rurales les plus visitées.
Ceci dit, la Russie a réussi à faire un niveau de détail excellent même sur
ses immenses territoires ruraux.
Le seul problème est donc d'intéresser les Américains à la cartographie
libre de leurs espaces ruraux (OSM US n'est pas aussi actif que les
chapitres européens, et les services commerciaux propriétaires sont bien
plus présents sur nombre de sites, et sinon les sites gouvernementaux sont
déjà très développés, souvent mieux qu'en Europe, pour plein de sujets, ce
qui ne pousse pas beaucoup d'Américains à contribuer à OSM car ils n'en
ressentent pas assez le besoin et se satisfont des solutions commerciales
propriétaires et des sites gouvernementaux)



Le dim. 26 avr. 2020 à 12:13, Eric SIBERT  a
écrit :

> En ces temps de confinement, on regarde n'importe quoi sur youtube:
>
> https://www.youtube.com/watch?v=9wT5O0k3vec
>
> Puis assez rapidement, je me demande où c'est dans OSM. Tiens, on voit
> une voie ferrée dans la vidéo qui n'est pas dans OSM. Qu'est-ce qu'on a
> comme source? Bing. C'est bien calé ça? Allons voir l'échangeur
> autoroutier voisin. À voir les traces GPS et Mapillary, Bing est bien
> calé. Par contre les bretelles de l'échangeur... :-(. D'ailleurs, il n'y
> a pas que la position. Il y aussi le nombre de voies, les séparations de
> bretelle et j'en passe, qui posent problème. Trop gros chantier. Je me
> contente de rajouter la seconde voie ferrée.
>
> Puis sur la fin de la vidéo, il y a une route qui fait des zigzags le
> long de la voie. Là, il y a eu des travaux, qu'on voit sur la vidéo. La
> route a été reprofilée. Ça a été intégré dans OSM à la hache. Plus,
> manque un pont. La relation de la route est restée sur le tronçon
> désaffecté...
>
> Donc, la question: le réseau routier US dans OSM, c'est tout comme ça?
>
> Bon confinement.
>
> Eric
>
> ___
> 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-it] Progetto OsmGuineaBissau

[2021_Gabriele Uberto]

Buongiorno lista,

parlo in rappresentanza della classe 5^A dell’Istituto Tecnico Avogadro di
Torino,

e volevo informarvi che stiamo portando avanti un progetto incentrato su
OSM.

L’obiettivo è quello di mappare “da poltrona”  un villaggio situato in
Guinea-Bissau.

Per presentare questo progetto e la classe, è stata creata una pagina Wiki.

Ogni studente ha creato degli account e i changeset  sono commentati con
#IISAvogadro19 per riconoscere la fonte di mappatura.

Anche se in questi giorni come da decreto non siamo presenti a scuola, la
classe sta continuando a lavorare al progetto.

Vi lascio di seguito il link alla pagina Wiki:

https://wiki.openstreetmap.org/wiki/OsmGuineaBissau_Avogadro

Inoltre alcuni studenti hanno anche creato un video presentazione del
progetto, sia per farlo conoscere alla comunità, che per farlo aderire ad
un concorso chiamato ‘Storie di alternanza’, vi lascio qui di seguito il
link:

https://www.youtube.com/watch?v=lj0iqdUjjAA

Saluti,

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

Re: [OSM-talk-fr] [Presse Locale][Ca Urge] Ça reste ouvert :

[Philippe Verdy]

Merci pour eux. Monaco étant évidemment couvert par des contributeurs
présents sur une zone plus large incluant au moins les Alpes-Maritimes
françaises.

Le mer. 29 avr. 2020 à 08:39, PanierAvide  a écrit :

> Pour info, on a ouvert Monaco hier :
> https://www.caresteouvert.fr/@43.733624,7.418960,14.41
>
> Comme on a pas exigé/attendu une communauté à Andorre, ça paraissait
> logique d'ajouter Monaco. L'attente d'une communauté locale porteuse du
> projet nécessite évidemment que le territoire soit assez grand pour qu'une
> communauté locale puisse y être active.
>
> Cordialement,
>
> Adrien P.
>
> Le 29/04/2020 à 00:57, Philippe Verdy a écrit :
>
> Bref, exiger une communauté locale à Monaco est sans doute trop: cette
> communauté est forcément extrêmement réduite, voire inexistante, composée
> en fait de contributeurs qui y vont souvent mais sont en fait logés
> ailleurs (Le Cap d'Ail ou Roquebrune-Cap-Martin pour les plus aisés sur la
> côte, Beausoleil ou la Turbie pour les autres dans les hauteurs les plus
> proches de Monaco, sinon venant d'autres villes de la Côte d'Azur française
> ou de la Riviera italienne, que ce soit en train ou bus, ou en voiture
> s'ils peuvent se garer à Monaco, éventuellement même à pied ou à vélo pour
> ceux habitant assez près de la frontière monégasque), plus des voyageurs
> professionnels qui peuvent venir de plus loin (y compris régulièrement par
> avion depuis l'aéroport Nice-Côte d'Azur) et ceux qui y ont une résidence
> secondaire, un bureau ou pas de porte pour une filiale ou une activité
> commerciale ou associative, ou encore une embarcation stationnée au port de
> Monaco (tant qu'on ne leur impose pas des restrictions de circulation pour
> passer la frontière franco-monégasque ou pour voyager de plus loin en avion
> via Nice ou Gênes, ni une quinzaine de confinement pour ceux qui peuvent se
> loger durablement hors des hôtels fermés).
>
>
>
> Le mer. 29 avr. 2020 à 00:41, Philippe Verdy  a écrit :
>
>> Monaco a sa communauté locale très largement liée aux services en France,
>> et a de nombreux travailleurs transfrontaliers, venant la plupart de France
>> (car Monaco ne peut pas les loger) ou sinon de l'Italie toute proche, y
>> compris des personnes monégasques résidant en France ou Italie. De plus la
>> réglementation locale de Monaco suit d'assez près celle applicable en
>> France (sauf la législation spécifique à certains commerces et aux taxes
>> applicables, ou la classification locale des établissements médicaux, bien
>> que Monaco coopère largement avec la France et dépend aussi de la France
>> pour nombre de services médicaux, avec aussi des reconnaissances mutuelles
>> en terme de sécurité sociale: les monégasques ne sont pas obligés de se
>> faire soigner uniquement à Monaco qui ne dispose pas de tous les services
>> nécessaires pour toutes les spécialités).
>>
>> Et je suis presque certain que la plupart des contributeurs pour Monaco
>> sont en fait en France, et tous parlent français et ont suivi nos règles
>> françaises pour le tagging (avec quelques exceptions, dont les tags "FR:*"
>> franco-français qui ne les concernent pas, remplacés si nécessaire par des
>> tags "MC:*" pour suivre les règles spécifiquement monégasques).
>>
>> L'Italie est aussi déjà intégrée dans CRO (mais selon les règles
>> communautaires italiennes). Bref c'est un tout petit trou qui ne coûte pas
>> grand chose de plus.
>>
>>
>>
>> Le mar. 28 avr. 2020 à 08:50, PanierAvide  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> La stratégie adoptée est que ce sont les communautés locales des
>>> différents pays qui sont porteurs de l'initiative, donc tant qu'une
>>> communauté locale ne se manifeste pas, pas d'ouverture de "Ça reste ouvert"
>>> dans un pays. L'idée étant qu'il faut du monde pour traduire, animer,
>>> contribuer, gérer les notes... Voir pour référence :
>>> https://github.com/osmontrouge/caresteouvert/wiki/Expand-%22%C3%87a-reste-ouvert%22-to-another-country
>>>
>>> Ceci étant dit, Andorre a été intégré pour ne pas avoir de discontinuité
>>> entre France et Espagne, ce ne serait donc pas plus mal d'activer Monaco
>>> également sur ce même principe.
>>>
>>> Cordialement,
>>>
>>> Adrien P.
>>>
>>> Le 28/04/2020 à 07:18, Philippe Verdy a écrit :
>>>
>>> Rien à Monaco (contrairement à Andorre) ou bien c'est groupé avec la
>>> France (étant donné la proximité des 4 autres communes françaises autour:
>>> Le Cap-d'Ail, La Turbie, Beausoleil et Roquebrune-Cap-Martin qui ont
>>> quelques points mais à mon avis même pas assez)?
>>>
>>> Je ne vois aucun point (même gris) à Monaco (dont les lieux pourraient
>>> être indexés avec ceux de la France, ça ne va pas beaucoup révolutionner
>>> les statistiques, sauf justement concernant les établissements médicaux,
>>> hors l'hôpital qui comme les autres ne sont pas à renseigner car ils sont
>>> évidemment ouverts et ont à gérer l'urgence et coopèrent avec toute la
>>> région, même si les frontières sont encore fermées ou sévèrement contrôlées

Re: [OSM-talk] Let's talk Attribution

[Martin Koppenhoefer]

Am Mi., 29. Apr. 2020 um 04:05 Uhr schrieb Kathleen Lu <
kathleen...@mapbox.com>:

> I absolutely agree that looking at industry standard seems a good
> indication of what is reasonable.
> ...After researching this question, I found no commercial data provider
> that required data attribution as prominently as the FAQ suggests. Industry
> standard would suggest a *much* less strict interpretation of what is
> "reasonable" under the ODbL.
>



I do have an example that comes to mind: imagine you use Google Geocoding.
This obligates you to use the results in the Google ecosystem, and this has
the requirement to display a Google logo on the map.
Another example would maybe be mapbox? If you use data they have
transformed, you will have to put a mapbox logo on the screen.

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

Re: [OSM-talk-fr] Libraires et takeaway

[Philippe Verdy]

Le terme "order" est aussi ambigu en tant que clé générique, pour remplacer
"reservation" qui est un peu trop spécifique (s'applique surtout à la
"consommation sur place" d'un service commandé à l'avance, mais pas
forcément payé à l'avance, ou seulement des arrhes, notamment les
restaurants pour réserver une table).
Je préférerais donc "prepaid=yes/only" (le (pré)paiement impliquant une
(pré)commande du bien ou service) ou "preorder=yes/only" (si un paiement
n'est pas exigé pour commander, par exemple un transport à la demande
public gratuit ou pour des abonnés ou détenteurs d'une carte y donnant
droit)

Enfin dans le cas d'achats ou réservations à distance, la plateforme est à
indiquer pour la commande à distance: "preorder:phone=yes",
"preorder:web=yes" (plutôt que "preorder:media=web" et donc des valeurs
multiples avec divers ordonnancements ou séparateurs comme
"preorder=web;phone" ou "preorder=phone, web"), et implique de fournir les
moyens de contact adaptés (phone=*, website=*)

En revanche "pickup" me semble un bon choix (inclus aussi "parcel" pour les
automates de retrait), très clair pour remplacer "takeway" (consommation
hors du lieu de fourniture du bien ou service, mais on doit venir chercher
le produit ou utiliser un service de livraison supplémentaire, du même
fournisseur ou d'un autre).

(Pour un magasin de bricolage on ne consomme jamais sur place de toute
façon donc on a toujours t"akeway=only", mais si la volonté est d'indiquer
qu'on n'a accès à la surface commerciale pour choisir les produits et
passer en caisse et qu'à la place on a accès à un catalogue à distance pour
précommander, c'est alors "preorder=only", que ce soit avec un retrait sur
place avec "pickup=yes/only" ou en livraison)

Reste ensuite la clé à adopter pour les bien ou services livrés à domicile
ou ailleurs par le fournisseur (pas de consommation sur place chez le
fournisseur, on ne doit pas venir chercher le produit, il peut y
avoir paiement ou pas à la livraison ou plus tard, ou y avoir d'autres
formules comme des bons d'achats prépayés, ou une facturation périodique
comme pour l'énergie): "delivery=yes/only"



Le mer. 29 avr. 2020 à 11:44, Frantz  a écrit :

> 28 avril 2020 22:43 "Marc M."  a écrit:
>
> > Bonjour,
> >
> > Le 28.04.20 à 16:22, Frantz a écrit :
> >
> >> Que pensez-vous de distinguer avec pickup, déjà utilisé pour les colis :
> >> - takeaway : achat sur place d'un produit emporté
> >> - pickup : uniquement retrait d'un produit (sans achat sur place)
> >
> > veux-tu dire qu'une pizzeria qui propose de commander
> > sur place ne devrait pas avoir le même tag que si tu
> > passes la commande par téléphone ?
>
> Ce n'est pas ce que je voulais dire, mais oui aussi pour cet exemple.
> Je cherchais surtout pour les commerces hors restauration, où le takeaway
> (tel qu'actuellement défini) est ambigüe.
>
> > si oui est-ce que cela ne devrait pas plutôt faire
> > l'obhjet d'un autre tag genre reservation:media=phone;onsite;web;app ?
>
> En effet, avec un reservation:media=phone + reservation:required on
> pourrait approcher.
> Il faudrait élargir l'utilisation indiquée sur le wiki de takeaway et
> reservation qui sont orientés restaurant/tourisme vers la signification
> retrait et commande.
> Pour un magasin de bricolage, les plus demandeurs en ce moment, ça
> donnerait :
> - takeaway=only
> - reservation=required
> - reservation:media=web
>
> Ça convient en effet, mais je trouverais plus simple et plus précis un
> "pickup" unique et dédié (et éventuellement un "order" au lieu de
> "reservation").
>
> --
> Frantz
>
> ___
> 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-de] Gewichtung der Straßen im Routing

[Christopher Lorenz via Talk-de]

Lt. Taginfo nur valhalla
Das :practical ist mir persönlich aber auch noch nie über den Weg gelaufen. 



Am 29. April 2020 12:33:02 MESZ schrieb Florian Lohoff :
>On Tue, Apr 28, 2020 at 09:15:39PM +0200, Tom Pfeifer wrote:
>> On 28.04.2020 17:35, Florian Lohoff wrote:
>> > Die Frage war wie ihr das mit der relativen Gewichtung von
>> > Routingalternativen bearbeitet und fixed.
>> 
>> Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man
>> realistischerweise auf einer Strasse vorankommt.
>> https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical
>> 
>> Auch hierzu das Beispiel Irland - bei der Umstellung der Geschwindigkeiten
>> von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale
>> Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die
>> rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene
>> Straße, die sich auch alle paar Meter windet, und gleich der Trecker
>> um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit
>> 15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router
>> zu mehr Realismus.
>
>OSRM supported das mit dem :practical nach meinem profile nicht - Den 
>nehme ich seit 2013 für die routing analyse weil schnell und prima
>scriptable.
>
>Wer supported das denn?
>
>Flo
>-- 
>Florian Lohoff f...@zz.de
>UTF-8 Test: The  ran after a , but the  ran away
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Fwd: Rapport du Président OSMF (était : [Osmf-talk] Summary Report on OSMF Chair's Outreach Jan-early Apr 2020)

[Philippe Verdy]

Au vu du constat, tout laisse penser que l'OSMF devrait se dissoudre et
carrément songer à une fusion avec la Fondation Wikimedia, qui est
nettement mieux structurée et peut remplir des objectifs similaires en
conservant l'esprit du projet mais avec une plus grande participation
communautaire. Cela résoudrait aussi bon nombre de problèmes administratifs
que l'OSMF est incapable de résoudre, et assurerait une meilleure
gouvernance et plus de transparence...

Le dim. 19 avr. 2020 à 11:17, Jean-Guilhem Cailton  a
écrit :

> Comme le rapport résumé par le nouveau président de la Fondation de ses
> premières consultations dans la communauté OSM m’a paru intéressant, et
> important pour l’avenir d’OSM, je vous fais suivre son courriel, qui
> contient un lien sur son article de journal, en anglais.
>
> Afin que le plus de contributeurs possible puisse en prendre connaissance,
> je l’ai fait traduire en français par Deepl.com, et rapidement remis en
> forme et relu, dans une page wiki, afin que la traduction puisse être revue
> et améliorée  (N’hésitez pas !) :
>
> https://wiki.openstreetmap.org/wiki/User:Jgc/TraductionJournalConsultationsApm-wa
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Gewichtung der Straßen im Routing

[Volker Schmidt]

Ich halte das mit maxspeed:practical fuer eine ziemliche Kruecke.
Habe mich mal umgeschaut, und die meisten Beispiele, die ich gefunden habe,
waren Strassen, wo fast alle relevanten tags fehlten:
lanes, width, surface, incline, oneway, smoothness, lit
Ich halte es fuer besser den Strassenzustand zu beschreiben, und dem Router
zu ueberlassen,  was er daraus macht (auch mit der Analyse der Geometrie),
als mit fiktiven Werten eine erwuenschtes Verhalten zu errreichen.
Ausserdem ist der tag selten (1300 in Deutschland und die beschraenkt auf
kleine Zonen, wo offensichtlich jeweils ein mapper in seiner Umgebung alles
damit voll gepflastert hat).

Um noch mal auf das urspruengliche Beispiel ( Liemekestrasse
 ) zurueckzukommen.
Wenn der Router eine Strasse trifft mit maxspeed=100 und
motor_vehicle=designated, width=4 dann  geht das schief. Die meisten Router
addieren Strafpunkte oder Bonuspunkte. In jedem Fall hat das falsche
tagging den Effekt, das zwei starke Vorteile (100km/Stunde und reserviert
fuer KFZ), den einen Nachteil (schmale Strasse) "ueberstimmen". Falsches
mappen sollte man nicht austricksen, sondern korrigieren. Im vorliegend
Fall waere der lokale mapper anzuschreiben, dass er die Situation vor Ort
kontrolliert und das tagging korrigiert. Ich kann mir nicht vorstellen,
dass eine 4m breite Strasse in DE nicht Geschwindigkeits-begrenzt ist.



On Wed, 29 Apr 2020 at 12:35, Florian Lohoff  wrote:

> On Tue, Apr 28, 2020 at 09:15:39PM +0200, Tom Pfeifer wrote:
> > On 28.04.2020 17:35, Florian Lohoff wrote:
> > > Die Frage war wie ihr das mit der relativen Gewichtung von
> > > Routingalternativen bearbeitet und fixed.
> >
> > Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man
> > realistischerweise auf einer Strasse vorankommt.
> > https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical
> >
> > Auch hierzu das Beispiel Irland - bei der Umstellung der
> Geschwindigkeiten
> > von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale
> > Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die
> > rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene
> > Straße, die sich auch alle paar Meter windet, und gleich der Trecker
> > um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit
> > 15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router
> > zu mehr Realismus.
>
> OSRM supported das mit dem :practical nach meinem profile nicht - Den
> nehme ich seit 2013 für die routing analyse weil schnell und prima
> scriptable.
>
> Wer supported das denn?
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gewichtung der Straßen im Routing

[Florian Lohoff]

On Tue, Apr 28, 2020 at 09:15:39PM +0200, Tom Pfeifer wrote:
> On 28.04.2020 17:35, Florian Lohoff wrote:
> > Die Frage war wie ihr das mit der relativen Gewichtung von
> > Routingalternativen bearbeitet und fixed.
> 
> Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man
> realistischerweise auf einer Strasse vorankommt.
> https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical
> 
> Auch hierzu das Beispiel Irland - bei der Umstellung der Geschwindigkeiten
> von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale
> Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die
> rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene
> Straße, die sich auch alle paar Meter windet, und gleich der Trecker
> um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit
> 15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router
> zu mehr Realismus.

OSRM supported das mit dem :practical nach meinem profile nicht - Den 
nehme ich seit 2013 für die routing analyse weil schnell und prima
scriptable.

Wer supported das denn?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [OSM-talk] Let's talk Attribution

[Christoph Hormann]

On Wednesday 29 April 2020, Kathleen Lu via talk wrote:
> [...]
> After researching this question, I found no commercial data provider
> that required data attribution as prominently as the FAQ suggests.
> Industry standard would suggest a *much* less strict interpretation
> of what is "reasonable" under the ODbL.

For clarity once again - although i have said this many times in the 
past and it is frankly annoying that i have to repeat myself this way 
because corporate lobbyists continue presenting/implying alternative 
facts.

OSM data is subject to the ODbL.  How it needs to be attributed is 
determined by the wording of the ODbL in the context of how OSM data is 
being produced through volunteer work (i.e. the contributor terms).

Geodata used by Google, Here, TomTom etc. is distributed and used under 
proprietary, non-open licenses which are very different from the ODbL 
and do not contain attribution requirements in any way comparable to 
that of the ODbL.  Hence attribution on use of such data sources 
(assuming it is actually attribution for the data source - which as 
Alexandre points out is not necessarily always the case) has 
*absolutely nothing* to do with attribution of OSM data use.  What you 
call commercial data providers depend on the economic viability of 
their licenses.  OSM does not.  If your business model does not allow 
using OSM data and complying with the ODbL at the same time you cannot 
use OSM data.

And what i have also said several times before is that the only way you 
can consistently interpret the ODbL attribution requirement - what 
Martin quoted as:

„You must include a notice associated with the Produced Work reasonably 
calculated to make any Person that uses, views, accesses, interacts 
with, or is otherwise exposed to the Produced Work aware that Content 
was obtained from the Database,...“

is in the way that the determination if any Person that uses, views, 
accesses, interacts with, or is otherwise exposed to the Produced
Work becomes aware that Content was obtained from the Database from the 
attribution provided needs to *be based on reason*.  So far no one has 
even attempted to explain the reasoning behind the expectation that a 
user of an application with hidden attribution becomes aware that 
Content was obtained from the Database.

But even completely disregarding these points of fundamental logic - the 
point the OSM community primarily needs to discuss in the context of 
providing practical guidance on attribution is what expectations 
mappers have when they agree to the contributor terms regarding the 
attribution provided by data users.  Any guidance the OSM community 
provides to data users regarding attribution needs to be fundamentally 
based on and compatible with that to have any social legitimacy.  And 
so far i have not heard any active mapper stating they expect anything 
other than clearly visible (or more generally: directly perceivable) 
attribution.  There are lots of mappers who state they don't care about 
attribution but not caring does not mean not expecting.  When there is 
talk among mappers about seeing OSM data use 'in the wild' people 
almost always are interested in the attribution - even those who would 
prefer if OSM had chosen PD as license.  The only defense of 
insufficient attribution i have heard from mappers so far is the 
willingness to settle for less (like because they don't care, because 
they would prefer a more liberal license anyway and are therefore fine 
with data users violating the ODbL or because they feel pity for the 
hardships of corporate data users in developing a business model that 
works while providing sufficient attribution to OSM).

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

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

Re: [OSM-talk-fr] Libraires et takeaway

[Frantz]

28 avril 2020 22:43 "Marc M."  a écrit:

> Bonjour,
> 
> Le 28.04.20 à 16:22, Frantz a écrit :
> 
>> Que pensez-vous de distinguer avec pickup, déjà utilisé pour les colis :
>> - takeaway : achat sur place d'un produit emporté
>> - pickup : uniquement retrait d'un produit (sans achat sur place)
> 
> veux-tu dire qu'une pizzeria qui propose de commander
> sur place ne devrait pas avoir le même tag que si tu
> passes la commande par téléphone ?

Ce n'est pas ce que je voulais dire, mais oui aussi pour cet exemple.
Je cherchais surtout pour les commerces hors restauration, où le takeaway (tel 
qu'actuellement défini) est ambigüe.
 
> si oui est-ce que cela ne devrait pas plutôt faire
> l'obhjet d'un autre tag genre reservation:media=phone;onsite;web;app ?

En effet, avec un reservation:media=phone + reservation:required on pourrait 
approcher.
Il faudrait élargir l'utilisation indiquée sur le wiki de takeaway et 
reservation qui sont orientés restaurant/tourisme vers la signification retrait 
et commande.
Pour un magasin de bricolage, les plus demandeurs en ce moment, ça donnerait :
- takeaway=only
- reservation=required
- reservation:media=web

Ça convient en effet, mais je trouverais plus simple et plus précis un "pickup" 
unique et dédié (et éventuellement un "order" au lieu de "reservation").

-- 
Frantz

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

[Talk-lv] OSMF finansējums

[Rihards]

OSMF ir sākusies microgrants programma - var saņemt līdz 5000 eiro OSM
uzlabošanas projektiem.
Līdz 10. maijam var pieteikties.
Vairāk info -
https://blog.openstreetmap.org/2020/04/19/announcing-the-osm-foundations-call-for-microgrant-applications/
.
-- 
 Rihards

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

[talk-ph] WeMap: Flight of the Drones webinar tonight, April 29

[Eugene Alvin Villar]

Hello all,

If you are following us on Facebook or are in the OSM PH Telegram group,
you should already know that the PH open mapping community has been holding
a series of online/virtual weekly webinars/mapathons every Wednesday night
since late March called Wednesday MapaTime or WeMap. Tonight starting at
7:30pm, we will be having our sixth WeMap session and it will be all about
drones or unmanned aerial vehicles (UAVs) and how they can be used to
complement mapping efforts, for example by collecting aerial imagery.

The links for this week's session is here: is.gd/5d0res

Come and join us!

~Eugene
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk-fr] gestion du cycle de vie des infos [était: Profusion de clés covid19]

[European Water Project]

Bonjour Marc,


>>>Je ne vois pas comment ajouter un meta par clef sans modifier
>>>l'api mais je suis ravi d'apprendre comment :)



C’était plus une interprétation qu'une affirmation firme ...



Tout changement qui implique une modification de l'API n’aboutira pas.



Ce que j’ai compris : l'ajout de la structure pour stocker cette méta data
dans la base de données ne serait pas si compliquée  Ce qui est
impératif est de ne pas déstabiliser l’écosystème OSM autour .. les outils
(API, etc.). Ceci impliquerait, que la seule moyenne d’accéder à cette meta
data sera dehors de l'API actuelle – peut-être avec une mini API dédiée qui
marcherait en parallèle.



Je vais demander à Simon, qui a les compétences techniques, s’il veut bien
commenter lui-même sur cette solution possible (et très hypothétique).



Cordialement,



Stuart


On Tue, 28 Apr 2020 at 18:52, Marc M.  wrote:

> Bonjour Stuart,
>
> Le 26.04.20 à 10:36, European Water Project a écrit :
> > c'est probablement possible d'ajouter ce metadata sur les tags
> > assez facilement sans besoin d'attendre la nouvelle API
>
> sans attendre, il y a key:date par exemple drink_water:date
> mais ce n'est pas une meta.
>
> Je ne vois pas comment ajouter un meta par clef sans modifier
> l'api mais je suis ravi d'apprendre comment :)
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-nl] do 30 April 2020 DGGS - 3D SPECIAL

[Just van den Broecke]

A.s. do 30 April 2020 weer een DGGS Ep. 3. Dit keer Thema Uitzending: 3D!.

Kijk via https://tv.osgeo.nl  op de livestream op ons YouTube kanaal of 
Twitch.tv/osgeonl. Chat mee.
Terugkijken kan ook op tv.osgeo.nl1, maar is vooral iets om live mee te 
maken.


We zullen 3D (in NL) van meerdere kanten belichten. Zelfs met kritische 
kanttekeningen.


Wie zijn er in de Show:

Hugo Ledoux - TU Delft 3D geoinformation research group - wat doet TU3D?
Mariëlle - “Marielle’s University” 3D leren
De Grote Geo Quiz - 3D Special - iedereen kan meedoen (via Kahoot).
Just van den Broecke - interview SpotInfo met Jan-Willem van Aalst - 
maken Digital Twin heel NL
Niene Boeijen - Column over 3D (gaan we nog niet verklappen, maar zal 
stof doen opwaaien)



Met vriendelijke groet,

--Just

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

Re: [OSM-talk-fr] [Presse Locale][Ca Urge] Ça reste ouvert :

[PanierAvide]

Pour info, on a ouvert Monaco hier : 
https://www.caresteouvert.fr/@43.733624,7.418960,14.41


Comme on a pas exigé/attendu une communauté à Andorre, ça paraissait 
logique d'ajouter Monaco. L'attente d'une communauté locale porteuse du 
projet nécessite évidemment que le territoire soit assez grand pour 
qu'une communauté locale puisse y être active.


Cordialement,

Adrien P.

Le 29/04/2020 à 00:57, Philippe Verdy a écrit :
Bref, exiger une communauté locale à Monaco est sans doute trop: cette 
communauté est forcément extrêmement réduite, voire inexistante, 
composée en fait de contributeurs qui y vont souvent mais sont en fait 
logés ailleurs (Le Cap d'Ail ou Roquebrune-Cap-Martin pour les plus 
aisés sur la côte, Beausoleil ou la Turbie pour les autres dans les 
hauteurs les plus proches de Monaco, sinon venant d'autres villes de 
la Côte d'Azur française ou de la Riviera italienne, que ce soit en 
train ou bus, ou en voiture s'ils peuvent se garer à Monaco, 
éventuellement même à pied ou à vélo pour ceux habitant assez près de 
la frontière monégasque), plus des voyageurs professionnels qui 
peuvent venir de plus loin (y compris régulièrement par avion depuis 
l'aéroport Nice-Côte d'Azur) et ceux qui y ont une résidence 
secondaire, un bureau ou pas de porte pour une filiale ou une activité 
commerciale ou associative, ou encore une embarcation stationnée au 
port de Monaco (tant qu'on ne leur impose pas des restrictions de 
circulation pour passer la frontière franco-monégasque ou pour voyager 
de plus loin en avion via Nice ou Gênes, ni une quinzaine de 
confinement pour ceux qui peuvent se loger durablement hors des hôtels 
fermés).




Le mer. 29 avr. 2020 à 00:41, Philippe Verdy > a écrit :


Monaco a sa communauté locale très largement liée aux services en
France, et a de nombreux travailleurs transfrontaliers, venant la
plupart de France (car Monaco ne peut pas les loger) ou sinon de
l'Italie toute proche, y compris des personnes monégasques
résidant en France ou Italie. De plus la réglementation locale de
Monaco suit d'assez près celle applicable en France (sauf la
législation spécifique à certains commerces et aux taxes
applicables, ou la classification locale des établissements
médicaux, bien que Monaco coopère largement avec la France et
dépend aussi de la France pour nombre de services médicaux, avec
aussi des reconnaissances mutuelles en terme de sécurité sociale:
les monégasques ne sont pas obligés de se faire soigner uniquement
à Monaco qui ne dispose pas de tous les services nécessaires pour
toutes les spécialités).

Et je suis presque certain que la plupart des contributeurs pour
Monaco sont en fait en France, et tous parlent français et ont
suivi nos règles françaises pour le tagging (avec quelques
exceptions, dont les tags "FR:*" franco-français qui ne les
concernent pas, remplacés si nécessaire par des tags "MC:*" pour
suivre les règles spécifiquement monégasques).

L'Italie est aussi déjà intégrée dans CRO (mais selon les règles
communautaires italiennes). Bref c'est un tout petit trou qui ne
coûte pas grand chose de plus.



Le mar. 28 avr. 2020 à 08:50, PanierAvide mailto:panierav...@riseup.net>> a écrit :

Bonjour,

La stratégie adoptée est que ce sont les communautés locales
des différents pays qui sont porteurs de l'initiative, donc
tant qu'une communauté locale ne se manifeste pas, pas
d'ouverture de "Ça reste ouvert" dans un pays. L'idée étant
qu'il faut du monde pour traduire, animer, contribuer, gérer
les notes... Voir pour référence :

https://github.com/osmontrouge/caresteouvert/wiki/Expand-%22%C3%87a-reste-ouvert%22-to-another-country

Ceci étant dit, Andorre a été intégré pour ne pas avoir de
discontinuité entre France et Espagne, ce ne serait donc pas
plus mal d'activer Monaco également sur ce même principe.

Cordialement,

Adrien P.

Le 28/04/2020 à 07:18, Philippe Verdy a écrit :

Rien à Monaco (contrairement à Andorre) ou bien c'est groupé
avec la France (étant donné la proximité des 4 autres
communes françaises autour: Le Cap-d'Ail, La Turbie,
Beausoleil et Roquebrune-Cap-Martin qui ont quelques points
mais à mon avis même pas assez)?

Je ne vois aucun point (même gris) à Monaco (dont les lieux
pourraient être indexés avec ceux de la France, ça ne va pas
beaucoup révolutionner les statistiques, sauf justement
concernant les établissements médicaux, hors l'hôpital qui
comme les autres ne sont pas à renseigner car ils sont
évidemment ouverts et ont à gérer l'urgence et coopèrent avec
toute la région, même si les frontières sont encore fermées
ou sévèrement contrôlées par les autorités monégasques,
sachant que la population