Re: [OSM-talk-fr] adresses numéros bis, ter ...

2020-11-06 Per discussione Philippe Verdy
sauf que c'est faux. le B peut signifier la lettre B (après A) ou le bis
(après le numéro sans suffixe). Et dans certains cas, on a les deux types:
12, 12A, 12B, 12C, puis 12 bis...
On ne peut pas dans ce cas abréger les "bis, ter, etc.", qui alors ne
doivent pas non plus être collés au numéro mais avec une espace), et
devraient rester en minuscules (alors que les lettres simples peuvent être
accolées et devrait être en capitales dans OSM).  Noter que la
capitalisation n'est pas signifiante (puisque pour la poste tout est forcé
en capitales), mais dans OSM on devrait garder les distinctions (comme pour
les noms de rues, avec leurs diacritiques et ponctuations), même si pour
l'usage postal on simplifie la graphie (et là on
remplace chaque ponctuation, tiret ou apostrophe, par une espace et il est
même permis de supprimer les diacritiques, et même recommandé, voire
obligatoire pour les envois en grand nombre pour faciliter le tri
automatique et bénéficier des tarifs réduits: les échec de tri automatique
peuvent être refacturés à l'expéditeur par la Poste)

Ceci dit les OCR postaux sont de plus en plus performants (les polices de
caractères et la qualité d'impression aussi, on n'utilise plus
d'imprimantes matricielles, trop lentes pour les envois en nombre), et
l'obligation c'est surtout pour la boite postale ou code de
distribution spéciale, le code postal, la ville, le pays, et le nom de rue;
les premières lignes d'adresse avec le nom exact du destinataire ou du
service et les précisions locales sont moins concernées car c'est lu par
des humains et ne nécessite pas le tri automatique)


Le ven. 6 nov. 2020 à 14:06, Yves P.  a écrit :

> A nouveau pour mémoire
> https://www.mail-archive.com/talk-fr@openstreetmap.org/msg97921.html ;)
>
> Merci :)
>
> J'ai commis ça :
> https://wiki.openstreetmap.org/wiki/FR:Adresses#Normalisation_du_suffixe_des_n.C2.B0_de_rue.5B1.5
>
> __
> 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: [Talk-it] living street in Italia nel wiki

2020-11-06 Per discussione Lorenzo Mastrogiacomi
Il giorno sab, 07/11/2020 alle 01.28 +0100, Damjan Gerl ha scritto:
> Martin Koppenhoefer je 6.11.2020 ob 23:43 napisal:
> > Qualcuno ha cambiato il wiki italiano per highway=living_street:
> > https://wiki.openstreetmap.org/w/index.php?title=IT:Tag:highway%3Dliving_street=next=1453296
> >  
> >  > >
> > 
> > riferendosi al segnale "Zona residenziale", CdS 3, 58. Ma non ha 
> > niente a che fare, perché il segnale non comporta regole
> > particolari, 
> > per avere un significato specifico ci devono essere posti cartelli 
> > integrativi.
> > 
> > Al momento sarei propenso ad un revert, ma forse non ho capito bene
> > la 
> > situazione. Voi cosa ne pensate?
> > 
> > Ciao
> > Martin
> 
> Ma questo posso taggarlo come highway=living_street oppure no?
> https://www.mapillary.com/map/im/MiCLwMt7c8pjIFBP920wAw
> 
> Grazie
> Damjan
> 

Per me "in Italia non esiste" è un po' esagerato. Ci sono casi in cui
ci può stare e questo potrebbe essere uno di quelli considerato anche
il limite dei 20.

Però anche la modifica al wiki non va bene perché non si applica alle
normali strade delle zone residenziali, anche se hanno l'ormai comune
limite dei 30 km/h.


Ciao
Lorenzo


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


Re: [Talk-it] living street in Italia nel wiki

2020-11-06 Per discussione Damjan Gerl

Martin Koppenhoefer je 6.11.2020 ob 23:43 napisal:

Qualcuno ha cambiato il wiki italiano per highway=living_street:
https://wiki.openstreetmap.org/w/index.php?title=IT:Tag:highway%3Dliving_street=next=1453296 



riferendosi al segnale "Zona residenziale", CdS 3, 58. Ma non ha 
niente a che fare, perché il segnale non comporta regole particolari, 
per avere un significato specifico ci devono essere posti cartelli 
integrativi.


Al momento sarei propenso ad un revert, ma forse non ho capito bene la 
situazione. Voi cosa ne pensate?


Ciao
Martin


Ma questo posso taggarlo come highway=living_street oppure no?
https://www.mapillary.com/map/im/MiCLwMt7c8pjIFBP920wAw

Grazie
Damjan

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


Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

2020-11-06 Per discussione Eric SIBERT via Talk-fr

Le 06/11/2020 à 11:54, Philippe Verdy a écrit :
Le click and collect se généralisé à presque tous les commerces de 
proximité à Niort, [...]


C'est triste une ville plus morte qu'un dimanche...


Niort en temps normal?

OK, je sors ->


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


Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?

2020-11-06 Per discussione Philippe Verdy
Ca dépend: normalement il n'y a pas de franchissement si on va dans la
direction de la voie, mais certains véhicules ont le droit de franchir pour
une arrêt de livraison ou pour une intervention de sécurité, ou pour entrer
dans un garage. Ils ne peuvent pas le faire à vitesse normale, mais en
vitesse au pas c'est possible... Cela agit donc bien comme un
ranlentisseur non pas dans le sens de la voie mais pour le franchissement
de voie.

Ceci dit j'aurais quand même tendance à tracer des voies séparées car ces
franchissements ne sont pas pour la circulation normale mais pour un arrêt:
l'emplacement de ce franchissement n'est pas bien défini, et c'est pour
ça qu'il faut indiquer que c'est franchissable (de la même façon qu'un
ralentisseur) avec un "kerb" ou quelque chose de plus doux encore (ce n'est
pas un traffic island qui est, lui, infranchissable, sauf par les piétons)

Mais "kerb" peut aussi bien désigner une bordure de trottoir, pas très
pratique mais pourtant couramment présent dans les zones où il est permis
de stationner en partie sur le trottoir). Comment qualifier mieux ces
"kerb" franchissables en vitesse très lente (au pas) ? Et doit-on alors
créer une connexion d'une voie à l'autre (et en quel point faire ce
franchissement? ou juste indiquer une largeur correspondant à l'écart entre
les deux voies "connectées" par cette séparation franchissable, ou un
polygone englobant la zone de franchissement possible contenant le "kerb" ?)

Sur la photo mapillary, on voit aussi que le "kerb" est discontinu et avec
des pentes douces, visiblement faits pour ne pas gêner trop le
franchissement par les deux-roues., mais dessiner un à un ces espaces
intercalaires me semble un peu ardu, il est plus simple alors de taguer le
kerb avec un truc du genre "barrier:bike=no" ou "access:bike=yes" (sans
exclure de tracer en plus le polygone "area=yes" englobant le "kerb",
continu ou pas, et les voies traversables de chaque côté).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[Talk-it] living street in Italia nel wiki

2020-11-06 Per discussione Martin Koppenhoefer
Qualcuno ha cambiato il wiki italiano per highway=living_street:
https://wiki.openstreetmap.org/w/index.php?title=IT:Tag:highway%3Dliving_street=next=1453296

riferendosi al segnale "Zona residenziale", CdS 3, 58. Ma non ha niente a
che fare, perché il segnale non comporta regole particolari, per avere un
significato specifico ci devono essere posti cartelli integrativi.

Al momento sarei propenso ad un revert, ma forse non ho capito bene la
situazione. Voi cosa ne pensate?

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


Re: [Talk-GB] OSM UK's first tile layer

2020-11-06 Per discussione Adrian via Talk-GB
The test will be, if Rob is able to produce example areas processed with the OS 
look-up table transformation, do the misalignments go away?

Sorry for a rather long and technical message.

I've done some more investigation and testing. QGIS reckons EPSG:27700 is the 
OS look-up table transformation, while JOSM thinks it is the Helmert 
transformation. The ultimate authority is the EPSG registry 
https://epsg.org/crs_27700/OSGB-1936-British-National-Grid.html . Unfortunately 
that page is not entirely clear. But there is a reference to the OSTN15 grid 
file in a footnote, so I think EPSG:27700 is intended to be the look-up table 
transformation. So, apologies for saying previously that EPSG:27700 is the 
Helmert transformation.

The work to incorporate a large number of projections into JOSM was done nearly 
five years ago. It is based on proj4. Both proj4 and proj5 have EPSG:27700 as 
the Helmert transformation (based on looking at the strings, and on the 
behaviour of JOSM). proj6 and proj7 have EPSG:27700 as the most basic 
transformation, which gives misalignments of over 100m (based on looking at the 
strings). By 'string', I mean the line of text that begins +proj=. Some file 
formats for geographic information (GIS files), can accommodate a range of 
projections. Most of these declare the projection near the beginning of the 
file. The Land Registry open data are such files and they declare EPSG:27700. 
If you process them with proj, or an app that uses proj, you are not going to 
get the right results unless you can override the declaration.

The strange thing is that QGIS also uses proj. The developers of QGIS must have 
altered the definition of EPSG:27700 from the one built-in to proj. But I 
haven't discovered exactly what has been done.

I set about loading some of the Land Registry open data into JOSM, with the 
look-up table transformation. With the opendata plugin, JOSM can read a range 
of GIS file formats. Unfortunately that does not include .gml, the format of 
the Land Registry files. The Land Registry suggest using QGIS, so I did. JOSM 
and QGIS have four formats in common, KML, geoJSON, Esri shapefile .shp, and 
MapInfo file .mif. I am a complete newbie to QGIS, but it is a nightmare! The 
option to disable projection handling (No CRS) does not work properly. (This 
would give a means of overriding the declaration in the file.) With three of 
the four formats for the output file, KML, .shp and .mif, QGIS simplified the 
polygons, weeding out nearly half of the nodes. QGIS gave no warning of this, 
and I could not find an option to turn off this behaviour. (There is an option 
to turn off this behaviour for rendering. Perhaps it would have turned it off 
for output too. But why were geoJSON files unaffected?) When writing a .mif 
file in EPSG:27700 projection, QGIS wrote the most basic transformation as the 
projection, without giving a warning. QGIS did this because the .mif format has 
limitations on the projection definitions that it can handle. Perhaps the 
latest version of QGIS is a bit buggy and I should have used the LTS version.

I tried doing the transformation in QGIS, then loaded the output file into 
JOSM. All four file formats worked, and gave the same results (apart from the 
loss of nodes with three of the formats). So if you're using QGIS, I'd 
recommend doing it this way and using geoJSON. It doesn't even need the 
opendata plugin. If you want to do just the file format conversion in QGIS, and 
do the transformation in JOSM, it's more tricky. The KML and geoJSON formats 
are ruled out because they must by definition contain WGS 84 lats and longs. So 
you are stuck with the loss of nodes. The .shp format gives up to 5m 
misalignment because QGIS declares EPSG:27700 in the file and the opendata 
plugin provides no means for overriding the EPSG:27700 and using the custom 
projection I described previously. The .mif format works (in terms of getting 
no misalignment) if you do a simple hack. Open the .mif file in a text editor 
and change the fourth line from CoordSys Earth Projection 8, 79, "m", -2, 49, 
0.9996012717, 40, -10 to CoordSys Nonearth Units "m" Bounds (0.0, 0.0) 
(130.0, 130.0) ensuring that none of the spaces are omitted. This means 
that no projection is defined in the file and the opendata plugin will then ask 
you which projection you want to use. You simply choose the custom projection, 
provided that you have previously set it up. (You may need to scroll down to 
see the Okay button.) The transformation in JOSM gives essentially the same 
results as the transformation in QGIS.

For the newbie, here's how to do the transformation in QGIS. Launch QGIS. 
Create a new project. Then Layer > Add Layer > Add Vector Layer and open the 
.gml file you have downloaded from the Land Registry open data. Accept the 
suggested CRS of EPSG:27700 and close the Data Source Manager dialog. Then 
Layer > Save As > choose Format GeoJSON, filename as 

Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

2020-11-06 Per discussione Cédric Frayssinet

Il semblerait que 'Ça Reste Ouvert' revienne prochainement sur Lyon.
Déclaration du maire Grégory Doucet :
https://nitter.net/Gregorydoucet/status/1324723611199021058
(5e tweet)

Cédric

---
Envoyé depuis l'application smartphone FairEmail, libre et orientée sécurité, 
veuillez excuser ma brièveté.
https[https://email.faircode.eu]://[https://email.faircode.eu]email.faircode.eu[https://email.faircode.eu]

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


Re: [OSM-legal-talk] Data Portal License CC0 1.0 and OpenStreetMap

2020-11-06 Per discussione Mateusz Konieczny via legal-talk
It is likely, but it should be evaluated. I mentioned it because
sometimes people assume "CC0=can be imported" while it is definitely untrue:

https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#CC0

Nov 6, 2020, 17:47 by pierz...@yahoo.fr:

> 2020-10-06 , Mateusz Konieczny wrote via legal-talk :
>
> > For example Wikidata is CC0 but mostly copyright incompatible with OSM
> > and unusable for imports in general.
>
> If I understand correctly, there is quite a difference in solididy of license 
>  from groups like Wikidata who import data from various sources vs a 
> government agencies that produce their own data.
>
>  
> Pierre 
>
> Le vendredi 6 novembre 2020 11 h 08 min 52 s UTC−5, Mateusz Konieczny via 
> legal-talk  a écrit :
>
>
> See > https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>
> "License terms are compatible, but the licenser does not guarantee for it. 
> 4c of the license explicitly states: > "Affirmer disclaims responsibility for 
> clearing rights of other persons that may apply to the Work or any use 
> thereof, 
> including without limitation any person's Copyright and Related Rights in the 
> Work. 
> Further, Affirmer disclaims responsibility for obtaining any necessary 
> consents, 
> permissions or other rights required for any use of the Work."> "
>
> For example Wikidata is CC0 but mostly copyright incompatible with OSM
> and unusable for imports in general.
>
> Nov 6, 2020, 16:48 by legal-talk@openstreetmap.org:
>
>> Government of Quebec has added the licence CC0 1.0 to his >> 
>> https://www.donneesquebec.ca>>  Data portal >>  for import of datasets and 
>> never returned requests to add specific authorisation for OSM>> . 
>>
>> Looking at the history of discussions, it is not clear for me if the CC0 
>> Public license is compatible with OSM. 
>>
>> Then my question : Does >>  CC0 1.0>>  license make the data compatible with 
>> OpenStreeMap Odbl llicense ?  
>>
>> If so, we will have access to datasets of high quality such as route, 
>> hydrography, address.
>>
>> License in french
>> https://www.donneesquebec.ca/fr/licence/
>>
>> Deepl translation 
>> ---
>> In order to promote collaboration, exchange and sharing, as well as the use 
>> of open data by all, the Government of Quebec and several municipalities 
>> have adopted a common licence, Creative Commons 4.0 (CC), which comes in six 
>> variants.
>>
>> This licence is recognized as one of the least restrictive in terms of the 
>> rights to use open data, while protecting copyright.
>>
>> The universal Creative Commons 1.0 licence (CC0 1.0) can also be used, in 
>> particular to encourage the integration of data into a larger set of open 
>> and linked data, in which the origin of each piece of data can sometimes be 
>> more complex to recognise. 
>> ---
>>
>>  
>> Pierre
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>

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


Re: [Talk-GB] Multi-lingual tagging in Wales

2020-11-06 Per discussione Christopher Jones
A default to English is perhaps a little tone deaf. 

As Andy wisely suggests, seeking a consensus among (ideally local) mappers is 
the way forward here. 

—
Chris

> On 31 Oct 2020, at 18:19, Jez Nicholson  wrote:
> 
> I like it.
> 
> + "in the event of dispute... the default language is English."? 
> .although I'm not sure how to define dispute'.
> 
> On Sat, 31 Oct 2020, 11:07 Ben Proctor,  wrote:
> Thanks Chris (and everyone else) for your very helpful contributions. 
> 
> I've tried to synthesise the discussion on this thread and would like to 
> propose the following for the Wales section of the Multilingual Tagging page 
> on the OSM Wiki. 
> 
> This would be a slight change from the current entry
> 
> BEGINS/---
> 
> In Wales many, but by no means all, places and features are named differently 
> in Welsh and English. 
> 
> Instances where the name is different in Welsh and English
> 
> The name tag should contain the name widely used by the local population. 
> 
> This should be either the name used in English or the name used in Welsh but 
> not both.
> 
> If the name included in the name: tag is that used in English, name:cy can be 
> added to show the alternate name (cy is the two letter ISO639-1 language code 
> for the Welsh language).
> 
> If it is the name included in the name: tag is the name used in Welsh, 
> name:en can be added to show the alternate name (en is the two letter 
> ISO639-1 language code for the English language).
> 
> Examples:
> 
> name: Welshpool
> name:cy Y Trallwng
> 
> name: Biwmares
> name:en Beaumaris
> 
> It should not be necessary to add both name:en and name:cy though it is not 
> harmful to do so.
> 
> Instances where the name is the same in Welsh and English
> 
> The name: tag should contain the name.
> 
> It is not, in principle, necessary to add either a name:cy or a name:en 
> (since there is only one name in both languages). 
> 
> However
> 
> Multi-lingual tagging in Wales is currently patchy. Adding a name:cy tag even 
> though this will duplicate the information in the name: tag would help other 
> mappers distinguish between cases where multi-lingual tagging has not yet 
> been applied and cases where the name is the same in Welsh and English.
> 
> Example:
> name: Caernarfon 
> name:cy Caernarfon
> 
> ---/ENDS
> 
> 
> I *think* this largely synthesises the discussion so far. I'd welcome more 
> comments on this.
> 
> 
> On Wed, Oct 21, 2020 at 4:40 PM Christopher Jones  wrote:
> Hi Ben,
> 
> Personally, I don’t see the point of 
> 
> name: Swansea
> name:en Swansea
> name:cy Abertawe
> 
> It's stating the obvious that if name:cy is not the same as name: for a place 
> in Wales, the name attribute is the English, and visa versa. It’s a little 
> close to “tagging for the renderer” for my taste. That said it costs little 
> to duplicate it in practice, so rock on if that’s what you want to do!
> 
> Regarding what should be in the name tag, we have a set of flawed options…
> 
> You initially suggested using a “widely” known by rule, this by its nature 
> favours the English names. The majority of the Welsh population are primary 
> English speakers, and despite a huge amount of time and money being spent on 
> welsh language laws and education provision that’s not about to change in any 
> of our lifetimes, even the welsh governments hugely ambitious target is for 
> 1M welsh speakers by 2050, that still less than a third of the population.
> 
> • always use the name that is used in Welsh 
> 
> In Gwynedd where 65% of the population identify as able to speak welsh, this 
> might make some sense, in Blaenau Gwent where its 7.8%, this makes no sense. 
> (Figures from the 2011 census) 
> 
> • use the Welsh name and English name together separated by a hyphen 
> (which is the practice in some other countries)
> 
> I’m going to refer you to 
> https://lists.openstreetmap.org/pipermail/talk-gb/2017-August/020478.html 
> where I made my argument against this (tl;dr - its ugly, confusing and there 
> are much better ways of achieving the aim (ie localised renders)) 
> 
> • use the name on local signage
> 
> I’m going to assume you mean to use the first name on the local signage 
> because the vast majority of signage has both English and welsh names (where 
> they both exist), indeed its been a legal requirement for them to do so for 
> quite some time. The major issue with this is since the Welsh Language 
> Measure of 2011 councils have a duty to ensure "that the Welsh language is 
> treated no less favourably than the English language” this ensures that on 
> any sign made in the last 10 years Welsh is first regardless of local usage.
> 
> So we end up with the status quo….
> 
> • use the name that is used by the "local population" (which is what 
> the wiki currently suggests)
> 
> This too has issues, the main one being its hard to verify, it relies on 
> local mappers being able to reach a consensus.
> 
> To me, this 

Re: [Talk-GB] Multi-lingual tagging in Wales

2020-11-06 Per discussione Christopher Jones
This looks good to me!

Thanks!

—
Chris

> On 31 Oct 2020, at 11:03, Ben Proctor  wrote:
> 
> Thanks Chris (and everyone else) for your very helpful contributions. 
> 
> I've tried to synthesise the discussion on this thread and would like to 
> propose the following for the Wales section of the Multilingual Tagging page 
> on the OSM Wiki. 
> 
> This would be a slight change from the current entry
> 
> BEGINS/---
> 
> In Wales many, but by no means all, places and features are named differently 
> in Welsh and English. 
> 
> Instances where the name is different in Welsh and English
> 
> The name tag should contain the name widely used by the local population. 
> 
> This should be either the name used in English or the name used in Welsh but 
> not both.
> 
> If the name included in the name: tag is that used in English, name:cy can be 
> added to show the alternate name (cy is the two letter ISO639-1 language code 
> for the Welsh language).
> 
> If it is the name included in the name: tag is the name used in Welsh, 
> name:en can be added to show the alternate name (en is the two letter 
> ISO639-1 language code for the English language).
> 
> Examples:
> 
> name: Welshpool
> name:cy Y Trallwng
> 
> name: Biwmares
> name:en Beaumaris
> 
> It should not be necessary to add both name:en and name:cy though it is not 
> harmful to do so.
> 
> Instances where the name is the same in Welsh and English
> 
> The name: tag should contain the name.
> 
> It is not, in principle, necessary to add either a name:cy or a name:en 
> (since there is only one name in both languages). 
> 
> However
> 
> Multi-lingual tagging in Wales is currently patchy. Adding a name:cy tag even 
> though this will duplicate the information in the name: tag would help other 
> mappers distinguish between cases where multi-lingual tagging has not yet 
> been applied and cases where the name is the same in Welsh and English.
> 
> Example:
> name: Caernarfon 
> name:cy Caernarfon
> 
> ---/ENDS
> 
> 
> I *think* this largely synthesises the discussion so far. I'd welcome more 
> comments on this.
> 
> 
> On Wed, Oct 21, 2020 at 4:40 PM Christopher Jones  wrote:
> Hi Ben,
> 
> Personally, I don’t see the point of 
> 
> name: Swansea
> name:en Swansea
> name:cy Abertawe
> 
> It's stating the obvious that if name:cy is not the same as name: for a place 
> in Wales, the name attribute is the English, and visa versa. It’s a little 
> close to “tagging for the renderer” for my taste. That said it costs little 
> to duplicate it in practice, so rock on if that’s what you want to do!
> 
> Regarding what should be in the name tag, we have a set of flawed options…
> 
> You initially suggested using a “widely” known by rule, this by its nature 
> favours the English names. The majority of the Welsh population are primary 
> English speakers, and despite a huge amount of time and money being spent on 
> welsh language laws and education provision that’s not about to change in any 
> of our lifetimes, even the welsh governments hugely ambitious target is for 
> 1M welsh speakers by 2050, that still less than a third of the population.
> 
> • always use the name that is used in Welsh 
> 
> In Gwynedd where 65% of the population identify as able to speak welsh, this 
> might make some sense, in Blaenau Gwent where its 7.8%, this makes no sense. 
> (Figures from the 2011 census) 
> 
> • use the Welsh name and English name together separated by a hyphen 
> (which is the practice in some other countries)
> 
> I’m going to refer you to 
> https://lists.openstreetmap.org/pipermail/talk-gb/2017-August/020478.html 
> where I made my argument against this (tl;dr - its ugly, confusing and there 
> are much better ways of achieving the aim (ie localised renders)) 
> 
> • use the name on local signage
> 
> I’m going to assume you mean to use the first name on the local signage 
> because the vast majority of signage has both English and welsh names (where 
> they both exist), indeed its been a legal requirement for them to do so for 
> quite some time. The major issue with this is since the Welsh Language 
> Measure of 2011 councils have a duty to ensure "that the Welsh language is 
> treated no less favourably than the English language” this ensures that on 
> any sign made in the last 10 years Welsh is first regardless of local usage.
> 
> So we end up with the status quo….
> 
> • use the name that is used by the "local population" (which is what 
> the wiki currently suggests)
> 
> This too has issues, the main one being its hard to verify, it relies on 
> local mappers being able to reach a consensus.
> 
> To me, this remains the pragmatic option!
> 
> Thanks for reading! 
> 
> And Ben, thanks for taking on the welsh render!
> 
> —
> Chris - not a Welsh speaker, but ran cyOSM, the first multilingual OSM render 
> many moons ago.
> 
> 
> > On 21 Oct 2020, at 12:10, Ben Proctor  wrote:
> > 
> > Thanks to everyone who has chipped in 

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

2020-11-06 Per discussione Alexandre Oliveira
> Other widespread online mapping services also require this kind of
> *attribution
> on the map*, usually even more prominently (brand logo with much bigger
> size than our textual example).

I'd like to emphasize what I said in the previous messages sent to
this thread - OpenStreetMap is a data provider and without data you
don't have a map (in other words: a map is a visualization of a
dataset). Mapbox provides a map (read: visualization of data from
OSM), so why is it okay for Mapbox, which is no secret that they use
OSM data, to put a giant watermark in the corner of the map, but for
them it is absolutely unacceptable to add a small text on the other
corner of the map crediting OSM for the data source? Without OSM,
there would be no data for Mapbox to produce a map.

And I would also like to say that the 2nd version of the draft
proposed by the LWG is as bad as the first draft. The first version
had lots of feedback from the community and it seems to me that the
LWG ignored all this feedback and just went with what corporate users
participating in the LWG proposed.

For example, they are proposing that it would be absolutely acceptable
to attribute OSM in a splash screen that disappears after 3-5 seconds
when you start an application. I have pointed out this controversial
idea, because in the meeting minutes the LWG says a splash screen is
not acceptable, and then proceed to suggest it as an acceptable
attribution because it was suggested by corporations.


I honestly hope that the OSMF rejects the draft as it is right now,
because the current draft provides several breaches to allow companies
like Mapbox and Facebook to undermine the importance of the
OpenStreetMap project.

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


Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?

2020-11-06 Per discussione Eric SIBERT via Talk-fr

Une séparation pas centrale:

https://www.mapillary.com/map/im/HsxR0OyWJaOFMa8zC7hMwn

Eric

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


Re: [OSM-legal-talk] Data Portal License CC0 1.0 and OpenStreetMap

2020-11-06 Per discussione Simon Poole
Everything relevant has been documented here 
https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility for a long 
time.

Am 6. November 2020 17:47:16 MEZ schrieb "Pierre Béland via legal-talk" 
:
> 2020-10-06 , Mateusz Konieczny wrote via legal-talk :  
>> For example Wikidata is CC0 but mostly copyright incompatible with
>OSM
>> and unusable for imports in general.
>If I understand correctly, there is quite a difference in solididy of
>license  from groups like Wikidata who import data from various sources
>vs a government agencies that produce their own data.
>
> 
>Pierre 
> 
>
>Le vendredi 6 novembre 2020 11 h 08 min 52 s UTC−5, Mateusz Konieczny
>via legal-talk  a écrit :  
> 
> See https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>
>"License terms are compatible, but the licenser does not guarantee for
>it. 
>4c of the license explicitly states: "Affirmer disclaims responsibility
>for 
>clearing rights of other persons that may apply to the Work or any use
>thereof, 
>including without limitation any person's Copyright and Related Rights
>in the Work. 
>Further, Affirmer disclaims responsibility for obtaining any necessary
>consents, 
>permissions or other rights required for any use of the Work.""
>
>For example Wikidata is CC0 but mostly copyright incompatible with OSM
>and unusable for imports in general.
>
>Nov 6, 2020, 16:48 by legal-talk@openstreetmap.org:
>
>Government of Quebec has added the licence CC0 1.0 to his
>https://www.donneesquebec.ca Data portal  for import of datasets and
>never returned requests to add specific authorisation for OSM. 
>
>Looking at the history of discussions, it is not clear for me if the
>CC0 Public license is compatible with OSM. 
>
>Then my question : Does  CC0 1.0 license make the data compatible with
>OpenStreeMap Odbl llicense ?  
>
>If so, we will have access to datasets of high quality such as route,
>hydrography, address.
>
>License in french
>https://www.donneesquebec.ca/fr/licence/
>
>Deepl translation 
>---
>In order to promote collaboration, exchange and sharing, as well as the
>use of open data by all, the Government of Quebec and several
>municipalities have adopted a common licence, Creative Commons 4.0
>(CC), which comes in six variants.
>
>This licence is recognized as one of the least restrictive in terms of
>the rights to use open data, while protecting copyright.
>
>The universal Creative Commons 1.0 licence (CC0 1.0) can also be used,
>in particular to encourage the integration of data into a larger set of
>open and linked data, in which the origin of each piece of data can
>sometimes be more complex to recognise. 
>---
>
> 
>Pierre 
>
> ___
>legal-talk mailing list
>legal-talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/legal-talk
>  

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk


Re: [OSM-legal-talk] Data Portal License CC0 1.0 and OpenStreetMap

2020-11-06 Per discussione Pierre Béland via legal-talk
 2020-10-06 , Mateusz Konieczny wrote via legal-talk :  
> For example Wikidata is CC0 but mostly copyright incompatible with OSM
> and unusable for imports in general.
If I understand correctly, there is quite a difference in solididy of license  
from groups like Wikidata who import data from various sources vs a government 
agencies that produce their own data.

 
Pierre 
 

Le vendredi 6 novembre 2020 11 h 08 min 52 s UTC−5, Mateusz Konieczny via 
legal-talk  a écrit :  
 
 See https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

"License terms are compatible, but the licenser does not guarantee for it. 
4c of the license explicitly states: "Affirmer disclaims responsibility for 
clearing rights of other persons that may apply to the Work or any use thereof, 
including without limitation any person's Copyright and Related Rights in the 
Work. 
Further, Affirmer disclaims responsibility for obtaining any necessary 
consents, 
permissions or other rights required for any use of the Work.""

For example Wikidata is CC0 but mostly copyright incompatible with OSM
and unusable for imports in general.

Nov 6, 2020, 16:48 by legal-talk@openstreetmap.org:

Government of Quebec has added the licence CC0 1.0 to his 
https://www.donneesquebec.ca Data portal  for import of datasets and never 
returned requests to add specific authorisation for OSM. 

Looking at the history of discussions, it is not clear for me if the CC0 Public 
license is compatible with OSM. 

Then my question : Does  CC0 1.0 license make the data compatible with 
OpenStreeMap Odbl llicense ?  

If so, we will have access to datasets of high quality such as route, 
hydrography, address.

License in french
https://www.donneesquebec.ca/fr/licence/

Deepl translation 
---
In order to promote collaboration, exchange and sharing, as well as the use of 
open data by all, the Government of Quebec and several municipalities have 
adopted a common licence, Creative Commons 4.0 (CC), which comes in six 
variants.

This licence is recognized as one of the least restrictive in terms of the 
rights to use open data, while protecting copyright.

The universal Creative Commons 1.0 licence (CC0 1.0) can also be used, in 
particular to encourage the integration of data into a larger set of open and 
linked data, in which the origin of each piece of data can sometimes be more 
complex to recognise. 
---

 
Pierre 

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


Re: [OSM-legal-talk] Data Portal License CC0 1.0 and OpenStreetMap

2020-11-06 Per discussione Mateusz Konieczny via legal-talk
See https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

"License terms are compatible, but the licenser does not guarantee for it. 
4c of the license explicitly states: "Affirmer disclaims responsibility for 
clearing rights of other persons that may apply to the Work or any use thereof, 
including without limitation any person's Copyright and Related Rights in the 
Work. 
Further, Affirmer disclaims responsibility for obtaining any necessary 
consents, 
permissions or other rights required for any use of the Work.""

For example Wikidata is CC0 but mostly copyright incompatible with OSM
and unusable for imports in general.

Nov 6, 2020, 16:48 by legal-talk@openstreetmap.org:

> Government of Quebec has added the licence CC0 1.0 to his > 
> https://www.donneesquebec.ca>  Data portal >  for import of datasets and 
> never returned requests to add specific authorisation for OSM> . 
>
> Looking at the history of discussions, it is not clear for me if the CC0 
> Public license is compatible with OSM. 
>
> Then my question : Does >  CC0 1.0>  license make the data compatible with 
> OpenStreeMap Odbl llicense ?  
>
> If so, we will have access to datasets of high quality such as route, 
> hydrography, address.
>
> License in french
> https://www.donneesquebec.ca/fr/licence/
>
> Deepl translation 
> ---
> In order to promote collaboration, exchange and sharing, as well as the use 
> of open data by all, the Government of Quebec and several municipalities have 
> adopted a common licence, Creative Commons 4.0 (CC), which comes in six 
> variants.
>
> This licence is recognized as one of the least restrictive in terms of the 
> rights to use open data, while protecting copyright.
>
> The universal Creative Commons 1.0 licence (CC0 1.0) can also be used, in 
> particular to encourage the integration of data into a larger set of open and 
> linked data, in which the origin of each piece of data can sometimes be more 
> complex to recognise. 
> ---
>
>  
> Pierre 

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


Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?

2020-11-06 Per discussione Jean-Claude Repetto

Le 06/11/2020 à 09:35, leni a écrit :



si la séparation est longue, je fais comme Vincent, si elle est courte 
https://wiki.openstreetmap.org/wiki/Tag:traffic_calming%3Disland


cordialement

leni



traffic_calming= island ne me paraît pas adapté, ici il ne s'agit pas 
d'un ralentisseur.


Jean-Claude


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


[OSM-legal-talk] Data Portal License CC0 1.0 and OpenStreetMap

2020-11-06 Per discussione Pierre Béland via legal-talk
Government of Quebec has added the licence CC0 1.0 to his 
https://www.donneesquebec.ca Data portal  for import of datasets and never 
returned requests to add specific authorisation for OSM. 

Looking at the history of discussions, it is not clear for me if the CC0 Public 
license is compatible with OSM. 

Then my question : Does  CC0 1.0 license make the data compatible with 
OpenStreeMap Odbl llicense ?  

If so, we will have access to datasets of high quality such as route, 
hydrography, address.

License in french
https://www.donneesquebec.ca/fr/licence/
Deepl translation 
---
In order to promote collaboration, exchange and sharing, as well as the use of 
open data by all, the Government of Quebec and several municipalities have 
adopted a common licence, Creative Commons 4.0 (CC), which comes in six 
variants.

This licence is recognized as one of the least restrictive in terms of the 
rights to use open data, while protecting copyright.

The universal Creative Commons 1.0 licence (CC0 1.0) can also be used, in 
particular to encourage the integration of data into a larger set of open and 
linked data, in which the origin of each piece of data can sometimes be more 
complex to recognise. 
---

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


Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?

2020-11-06 Per discussione Lionel Allorge
Bonjour,

Merci pour vos réponses.

Bon confinement :-)

-- 
Lionel Allorge

« Quand ça change, ça change.
Faut jamais se laisser démonter ! »

Les Tontons Flingueurs

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


Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

2020-11-06 Per discussione Yves P.
> Par chez moi, la CCI remet en route son site 
> https://twitter.com/CCI54/status/1324658562040254464 
>  mais en repartant de 
> zéro !
> 
Le nom de domaine http://jesuisouvert.fr/54 vous rappel quelque chose ??

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


Re: [Talk-de] Vorstandswahlen der OSMF - Kandidatur bis 7.11. Ende des Tages

2020-11-06 Per discussione LuKaRo
On 06.11.20 14:03, Frederik Ramm wrote:
> Der Nachteil der "normalen" gegenüber der "Associate" Membership ist:
>
> * Die OSMF ist rechtlich verpflichtet, Auskunft über ihre aktuellen und
> vergangenen (!) Mitglieder zu erteilen inkl. Wohnanschrift. Das heisst,
> Dritte können herausfinden, wo Du wohnst; diese (englische, gesetzliche)
> Vorschrift steht über dem Datenschutz.
>
> * Alle Mitglieder haften persönlich, wenn der Verein pleite geht und
> Schulden hat, mit einem Betrag von bis zu ... *trommelwirbel* ... 1
> britischem Pfund ;)
>
> Bye
> Frederik

Ahh, verstehe. Ist natürlich die Frage, ob ich dann aus Datenschutzgründen eher 
eine Associate Membership in Betracht ziehen würde. Aber im Falle einer 
Satzungsänderung würde ich natürlich schon gerne mit abstimmen können. Da werde 
ich also nochmal drüber nachdenken müssen. Vielen Dank auf jeden Fall für die 
Infos!

LG,
LuKaRo




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


Re: [Talk-de] Vorstandswahlen der OSMF - Kandidatur bis 7.11. Ende des Tages

2020-11-06 Per discussione Frederik Ramm
Hallo,

On 06.11.20 12:31, LuKaRo wrote:
> Was ist denn überhaupt der Vorteil der Associate Membership? Also aus
> welchen Gründen sollte man eine Associate Membership der normalen
> Mitgliedschaft gegenüber vorziehen?

Der Nachteil der "normalen" gegenüber der "Associate" Membership ist:

* Die OSMF ist rechtlich verpflichtet, Auskunft über ihre aktuellen und
vergangenen (!) Mitglieder zu erteilen inkl. Wohnanschrift. Das heisst,
Dritte können herausfinden, wo Du wohnst; diese (englische, gesetzliche)
Vorschrift steht über dem Datenschutz.

* Alle Mitglieder haften persönlich, wenn der Verein pleite geht und
Schulden hat, mit einem Betrag von bis zu ... *trommelwirbel* ... 1
britischem Pfund ;)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"



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


Re: [OSM-talk-fr] adresses numéros bis, ter ...

2020-11-06 Per discussione Yves P.
> A nouveau pour mémoire 
> https://www.mail-archive.com/talk-fr@openstreetmap.org/msg97921.html 
>  ;)
> 
Merci :)

J'ai commis ça : 
https://wiki.openstreetmap.org/wiki/FR:Adresses#Normalisation_du_suffixe_des_n.C2.B0_de_rue.5B1.5

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


Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

2020-11-06 Per discussione Romain MEHUT
Par chez moi, la CCI remet en route son site 
https://twitter.com/CCI54/status/1324658562040254464 mais en repartant 
de zéro !


https://outils.ccimp.com/geolocal-54/

Romain

Le 06/11/2020 à 11:14, Christian Quest a écrit :


C'est celui que j'utilise car le click-and-collect correspond à la 
vente à emporter par opposition à la livraison.


Je complète autant que possible avec phone/email/website.

Su ma petite carte, les POI de ce type sont désormais en orange quand 
on zoome, et les infos sont indiquées.



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

Les petits commerçants se mettent au "click and collect".
Un articles des Inrocks à ce sujet : Voici une carte interactive 
des librairies proposant le service “click and collect” 


(avec une carte Google)

Je ne sais pas si le tag takeaway:covid19 
 est adapté 
pour ça.


Et je pense que *CRO manque* vraiment car il était *fédérateur*, et 
l'affichage des POI par CRO et leur filtrage étaient adaptés :)


__
Yves



--
Ce message a été vérifié par *MailScanner* 


pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

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

--
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] adresses numéros bis, ter ...

2020-11-06 Per discussione Romain MEHUT

Bonjour,

A nouveau pour mémoire 
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg97921.html ;)


Romain

Le 06/11/2020 à 13:27, Yves P. a écrit :
Je voulais vérifier la bonne pratique pour une adresse style "15 bis 
rue xxx" et je n'ai pas trouvé sur 
https://wiki.openstreetmap.org/wiki/FR:Key:addr

ni ailleurs. Mais j'ai peut-être mal cherché.
On met addr:housenumber=15B, 15 Bis, 15 bis ?


Pour Rennes : 
https://wiki.openstreetmap.org/wiki/Rennes_Métropole/Adresses_codification

15 bis

Je met ça aussi dans le Jura. On a eu des discussions, mais où ? IRC, 
Telegram, talk-fr… ?


__
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] Comment indiquer une séparation centrale sur une rue ?

2020-11-06 Per discussione osm . sanspourriel

Et si par endroit c'est un simple trait blanc :

overtaking=no

https://wiki.openstreetmap.org/wiki/FR:Key:overtaking

Jean-Yvon

Le 06/11/2020 à 09:35, leni - lenny.li...@orange.fr a écrit :



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


Re: [OSM-talk-fr] adresses numéros bis, ter ...

2020-11-06 Per discussione Yves P.
> Je voulais vérifier la bonne pratique pour une adresse style "15 bis rue xxx" 
> et je n'ai pas trouvé sur https://wiki.openstreetmap.org/wiki/FR:Key:addr 
> 
> ni ailleurs. Mais j'ai peut-être mal cherché.
> On met addr:housenumber=15B, 15 Bis, 15 bis ?

Pour Rennes : 
https://wiki.openstreetmap.org/wiki/Rennes_Métropole/Adresses_codification
15 bis

Je met ça aussi dans le Jura. On a eu des discussions, mais où ? IRC, Telegram, 
talk-fr… ?

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


[Talk-es] Mapatón Humanitario 19 Nov GeoWeek

2020-11-06 Per discussione 00 UE -Raquel Bernedo Pardal
Buenos días,

El día 19 de noviembre, durante la GeoWeek [1], Cruz 
Roja Española junto con TECSOS va a realizar un nuevo mapatón humanitario en el 
marco de la iniciativa Missing Maps [2]. Os 
dejo el enlace para difusión a aquellas personas que podáis/puedan estar 
interesadas en participar. Este mapatón está dirigido a personas que no han 
mapeado antes o que lo han hecho muy poquito: 
https://www2.cruzroja.es/web/cruzroja/detalle-actividades/-/actividad/29140263?_activitiesDetail_startHour=17:00&_activitiesDetail_endHour=19:00&_activitiesDetail_startDate=19/11/2020&_activitiesDetail_professionId=430

Si alguien está interesado/a en participar como moderador/a y/o validador/a, os 
animamos a contactar con nosotros en 
equip...@cruzroja.es o 
del@cruzroja.es

Muchas gracias!



[1] https://osmgeoweek.org/
[2] Missing Maps

CONFIDENCIALIDAD. El contenido de esta comunicación y el de toda la 
documentación anexa es confidencial y va dirigido únicamente al destinatario 
del mismo. En el supuesto de que usted no fuera el destinatario, le solicitamos 
nos lo haga saber a la dirección del remitente y que no comunique su contenido 
a terceros, procediendo a su destrucción.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es


[OSM-talk-fr] adresses numéros bis, ter ...

2020-11-06 Per discussione Georges Dutreix via Talk-fr

Bonjour,

Je voulais vérifier la bonne pratique pour une adresse style "15 bis rue 
xxx" et je n'ai pas trouvé sur 
https://wiki.openstreetmap.org/wiki/FR:Key:addr

ni ailleurs. Mais j'ai peut-être mal cherché.
On met addr:housenumber=15B, 15 Bis, 15 bis ?

Si c'est spécifique à la France, ce serait peut-être indiquer également 
ici : https://wiki.openstreetmap.org/wiki/FR:Adresses#France ?


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


Re: [Talk-de] Vorstandswahlen der OSMF - Kandidatur bis 7.11. Ende des Tages

2020-11-06 Per discussione LuKaRo
Hi,

danke für die schnelle Rückmeldung!

On 11/5/20 11:39 PM, Frederik Ramm wrote:
> Das stimmt. Wir haben diese Regel vor einiger Zeit verschärft - früher
> waren es nur 30 Tage vor der Wahl, aber wir wollten vermeiden, dass sich
> irgendein Firmenfuzzi aufstellen lässt und gerade mal schnell den 2000
> Angestellten sagt, sie sollen in die OSMF eintreten ;) Das Problem ist
> dadurch nicht aus der Welt, aber wenigstens muss die Firma es sich jetzt
> länger vorher überlegen ;)
Verstehe, das leuchtet mir ein.
> Wählen dürfen auch die "Associate". Das einzige, was die nicht dürfen
> ist (a) für den Vorstand kandidieren und (b) über Satzungsänderungen
> abstimmen.

Was ist denn überhaupt der Vorteil der Associate Membership? Also aus
welchen Gründen sollte man eine Associate Membership der normalen
Mitgliedschaft gegenüber vorziehen?

LG,
LuKaRo



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


Re: [Talk-de] Vorstandswahlen der OSMF - Kandidatur bis 7.11. Ende des Tages

2020-11-06 Per discussione Roland Olbricht via Talk-de

Hallo,


Im Dezember ist wieder OSMF-Vorstandswahl. In ziemlich genau 52 Stunden
ist Ende der Bewerbungsfrist. Wenn ihr Interesse habt, als
Vorstandsmitglied zu dienen, könnt ihr Euch hier eintragen:

[..]> Ich selber bin ja nun schon eine Weile raus da, aber es ist meiner

Ansicht nach eine wichtige Arbeit. Die OSMF driftet ständig in Richtung
der "big business"-Leute, und auch dieses Jahr wird sich wieder Michal
Migurski zur Wahl stellen, der beim letzten Mal noch ganz deutlich in
seinem Wahlprogramm schrieb, dass er nicht als Privatmann, sondern als
Vertreter von Facebook in den Vorstand will - für mich eine sehr
schwierige Vorstellung.


Auf die Liste habe ich mich jetzt eingetragen. Wenn noch jemand Lust
hat, trage ich mich gerne wieder aus. Es bleiben bei mir ohnehin schon
mehr OSM-Themen liegen als mir lieb ist.

Ich denke aber, dass es schwierig wird, gezielt einen unerwünschten
Kandidaten draußen zu halten: das verwendete Wahlsystem STV hat ja
gerade als Zweck, die Chancen von Nischen-Bewerbern zu verbessern und
taktische Züge zu erschweren.

Eine Bitte an alle diejenigen, die mich wählen wollen: Mit Tobias'
Arbeit bin ich sehr zufrieden und möchte ihn auf keinen Fall verdrängen.
Setzt ihn also daher bitte VOR mich auf den Wahlzettel.

Zur Taktik: wenn ich Michal verdrängen soll, muss ich darauf abzielen,
bei möglichst vielen Wählern vor ihm auf dem Wahlzettel zu stehen, die
absolute Position ist weitgehend egal. Ich werde daher mit einer eher
business-freundlichen Position auftreten, die ich aber nicht in der OSMF
fortzusetzen beabsichtige. Generell ist der Zweck der Overpass API ja,
dass mehr Leute zu Tagging-Fragen auf Augenhöhe mitreden können, und die
Share-Alike-Lizenz ist wohlabgewogen gewählt.

Viele Grüße,

Roland

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


Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

2020-11-06 Per discussione Philippe Verdy
Le click and collect se généralisé à presque tous les commerces de
proximité à Niort, qui pour la plupart sont fermés au public, juste un
guichet de retrait à la porte. Plus moyen de voir ce qu'on achète et les
prix s'envolent avec une réduction drastique du choix.

C'est triste une ville plus morte qu'un dimanche...

Le ven. 6 nov. 2020 à 11:16, Christian Quest  a
écrit :

> C'est celui que j'utilise car le click-and-collect correspond à la vente à
> emporter par opposition à la livraison.
>
> Je complète autant que possible avec phone/email/website.
>
> Su ma petite carte, les POI de ce type sont désormais en orange quand on
> zoome, et les infos sont indiquées.
>
>
> Le 06/11/2020 à 10:31, Yves P. a écrit :
>
> Les petits commerçants se mettent au "click and collect".
> Un articles des Inrocks à ce sujet : Voici une carte interactive
> des librairies proposant le service “click and collect”
> 
> (avec une carte Google)
>
> Je ne sais pas si le tag takeaway:covid19
>  est adapté pour
> ça.
>
> Et je pense que *CRO manque* vraiment car il était *fédérateur*, et
> l'affichage des POI par CRO et leur filtrage étaient adaptés :)
>
> __
> Yves
>
>
>
> --
> Ce message a été vérifié par *MailScanner* 
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> --
> 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] Let's talk Attribution

2020-11-06 Per discussione Martin Koppenhoefer
To put this more into context, the facebook page does have a link to
OpenStreetMap behind the faint "i", and the majority of contributors may
eventually see this as reasonable attribution for the small map they
initially show, but it is quite clearly not suitable on the bigger popup
map to make everybody who sees the map aware that the data is from
OpenStreetMap. The license is only visible if you click a second time ("map
data legal notices"), while the "© OpenStreetMap" text could be even seen
as misleading (because the license if not presented at the same level).

Whether this is actually a copyright infringement of the license may be up
to a legal decision, although in my interpretation of 4.3 "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,
Derivative Database, or the Database as part of a Collective Database, and
that it is available under this License." it clearly is not making any
person that is exposed to the work aware that it is from OSM nor of the
license. But it is clear that it is not in line with the OSMF
interpretation of the requirements, we have delineated here:
https://www.openstreetmap.org/copyright/
*"For a browsable electronic map, the credit should appear in the corner of
the map."*

This is a very essential thing for OSM, it is the guarantee that our word
is spread, users are becoming familiar with our name and ultimately that
our community will grow.
Other widespread online mapping services also require this kind of *attribution
on the map*, usually even more prominently (brand logo with much bigger
size than our textual example).

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


Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

2020-11-06 Per discussione Christian Quest
C'est celui que j'utilise car le click-and-collect correspond à la vente 
à emporter par opposition à la livraison.


Je complète autant que possible avec phone/email/website.

Su ma petite carte, les POI de ce type sont désormais en orange quand on 
zoome, et les infos sont indiquées.



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

Les petits commerçants se mettent au "click and collect".
Un articles des Inrocks à ce sujet : Voici une carte interactive 
des librairies proposant le service “click and collect” 


(avec une carte Google)

Je ne sais pas si le tag takeaway:covid19 
 est adapté 
pour ça.


Et je pense que *CRO manque* vraiment car il était *fédérateur*, et 
l'affichage des POI par CRO et leur filtrage étaient adaptés :)


__
Yves



--
Ce message a été vérifié par *MailScanner* 
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

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


--
Christian Quest - OpenStreetMap France

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


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

2020-11-06 Per discussione Martin Koppenhoefer
Am Mo., 27. Apr. 2020 um 19:52 Uhr schrieb Alexandre Oliveira <
rockyt...@gmail.com>:

> Hello!
>
> I'll try to be brief and explain the main problems that exist with
> OSM's way of handling lack of (proper) attribution.
>
> According to the wiki page[0]:
>
> > Our requested attribution is "© OpenStreetMap contributors".
> > You must also make it clear that the data is available under the Open
> Database Licence. This can be achieved by providing a "License" or "Terms"
> link which links to www.openstreetmap.org/copyright or
> www.opendatacommons.org/licenses/odbl.
> >
> > This credit needs to appear in a place reasonable to the medium you are
> utilising. In other words, you should expect to credit OpenStreetMap in the
> same way and with the same prominence as would be expected by any other map
> supplier. Therefore:
> >- For a browsable electronic map (e.g. embedded in a web page or
> mobile phone application), the credit should appear in the corner of the
> map, as commonly seen with map APIs/libraries such as Google Maps.
> >- For a printed map, the credit should appear beside the map if that
> is where other such credits appear, and/or in the "acknowledgements"
> section of the publication (often at the start of a book or magazine).
>
> Now, let's take a look at a few projects that use OSM and don't abide
> by our own guidelines:
>
> Facebook: I've seen some complaints over the course of the last year
> regarding lack of attribution from the company. I decided to take a
> look myself this year and was surprised, they actually attribute
> OpenStreetMap, but not in the way described in the wiki page. On
> desktop, there's an information button on the bottom-right corner of
> the map, where the attribution should be, and when you click it
> there's the attribution text. Note that the icon is barely visible and
> I presume most people simply ignore it because it's barely
> noticeable[1].
>
> You may think "well, it's fine". Except it's not. On the mobile
> version of the Facebook page, there's no attribution at all, simply a
> map. And worse, it redirects to Google Maps when you click on it. I
> brought this issue to the IRC channel #osm on OFTC and I was shocked
> at the attitude of some members that "it was fine" and that Facebook's
> attribution cannot be considered a case of "no attribution". I
> disagree. If this is the position of the majority of the OSM
> Foundation and members of the project, we have a problem, and I'll
> explain below. Honestly, it seems to me that because Facebook is a
> sponsor of the project, they can do attribution in whichever way
> they'd like to, or even remove attribution, something like "I pay for
> this project so its rules doesn't apply to me". And from what I've
> gathered by my own research, it looks like the OSMF doesn't even care
> about Facebook's lack of proper attribution.




I am interested in knowing about facebook's reply to the OSMF
notifications, that they are not complying with the attribution
requirements and that they must either attribute in a way that is
compatible with the license, or cease publicly performing works based on
our data. Has there been any reply? What is a reasonable response time for
large scale copyright infringement?

These are screenshots I just took right now, illustrating the issue:
https://i.ibb.co/M2gp82H/Screenshot-2020-11-06-at-10-31-40.png
https://i.ibb.co/rcSHmK3/Screenshot-2020-11-06-at-10-31-51.png

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


Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

2020-11-06 Per discussione Yves P.
Les petits commerçants se mettent au "click and collect".
Un articles des Inrocks à ce sujet : Voici une carte interactive des librairies 
proposant le service “click and collect” 

(avec une carte Google)

Je ne sais pas si le tag takeaway:covid19 
 est adapté pour ça.

Et je pense que CRO manque vraiment car il était fédérateur, et l'affichage des 
POI par CRO et leur filtrage étaient adaptés :)

__
Yves


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


[talk-cz] WeeklyOSM CZ 535

2020-11-06 Per discussione Tom Ka
Ahoj, je dostupné vydání 535 týdeníku WeeklyOSM:

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

* Časová omezení.
* Rozcestníky nebo chaty?
* Vchody v OsmAnd.
* Man nebo human?
* Stromy na Sahaře.
* Metriky kvality.
* Chcete pohlednici?
* Steve Coast a OSMF.
* Postup TIGERa.
* Mappeři OSN.
* Mikrogranty Facebooku.
* Sledování letadel.
* Fanoušci Potlachu?
* Radar na smetí.
* Zvuky lesa.

Pěkné počtení ...

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


Re: [Talk-lv] Ziņas par kartes izmaiņām

2020-11-06 Per discussione pec...@gmail.com
Manuprāt laba ideja.

Pēteris.

piektd., 2020. g. 6. nov., plkst. 07:50 — lietotājs Rihards (<
riha...@nakts.net>) rakstīja:

> Labdien listē.
> Ja mums būtu iespēja saņemt info par izmaiņām, kādas nepieciešamas kartē
> (piemēram, satiksmes organizācija utt), vai būtu OK, ja tās tiktu sūtītas
> šajā listē?
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
>


-- 
mortigi tempo
Pēteris Krišjānis
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv


Re: [Talk-it] disservizio Wikipedia - OSM

2020-11-06 Per discussione Luca Delucchi
On Wed, 28 Oct 2020 at 15:10, Nicolò Balzarotti  wrote:
>
> Ok se hai poco tempo allora faccio il possibile e poi nell'ora al
> massimo rivediamo le modifiche assieme.
>
> Per ora sono "a buon punto", ma ho un problema anche con lo script
> python2:
>
> CERTIFICATE_VERIFY_FAILED all'indirizzo [1]
>
> Aprendo da browser vedo che [2] non funziona e mi rimanda a [3] che non
> funziona.
>
> Ne sai qualcosa?

No mi spiace, io stavo facendo girare gli script ma non ne sono l'autore

>
> Grazie, Nicolò
>

-- 
ciao
Luca

www.lucadelu.org

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


Re: [OSM-talk-fr] Comment indiquer une séparation centrale sur une rue ?

2020-11-06 Per discussione leni

Bonjour

Le 06/11/2020 à 00:26, Vincent de Château-Thierry a écrit :

Bonsoir,

Le 05/11/2020 à 23:43, Lionel Allorge a écrit :

Sur la rue suivante : https://www.openstreetmap.org/way/150276616

une petite surélévation en béton empèche les voitures de doubler, 
comme  un terre-plein central mais bien plus petit.


Comment l'indiquer ?


Et du fait de sa présence j'aurais tendance à dessiner un way par sens 
de circulation plutôt qu'un seul way centré... sur le terre-plein.


vincent


si la séparation est longue, je fais comme Vincent, si elle est courte 
https://wiki.openstreetmap.org/wiki/Tag:traffic_calming%3Disland


cordialement

leni


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


Re: [Talk-lv] Ziņas par kartes izmaiņām

2020-11-06 Per discussione Rihards
Šie abi esot pamatīgi data mining rīki - un vajadzētu kaut ko tādu, kur
organizācijām būtu viegli sniegt ziņas (neinstalējot aplikācijas utt).
Tā varētu būt vai nu šī liste, vai arī atsevišķa mailingliste, kur sūtītu
tikai info par izmaiņām.

On Fri, 6 Nov 2020 at 10:05, Marat  wrote:

> Čau! Varbūt varam labāk organizēt Discord vai Telegram kanālu? :)
>
> On Fri, 6 Nov 2020, 09:50 Rihards,  wrote:
>
>> Labdien listē.
>> Ja mums būtu iespēja saņemt info par izmaiņām, kādas nepieciešamas kartē
>> (piemēram, satiksmes organizācija utt), vai būtu OK, ja tās tiktu sūtītas
>> šajā listē?
>> ___
>> Talk-lv mailing list
>> Talk-lv@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-lv
>>
>
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv


Re: [Talk-lv] Ziņas par kartes izmaiņām

2020-11-06 Per discussione Marat
Čau! Varbūt varam labāk organizēt Discord vai Telegram kanālu? :)

On Fri, 6 Nov 2020, 09:50 Rihards,  wrote:

> Labdien listē.
> Ja mums būtu iespēja saņemt info par izmaiņām, kādas nepieciešamas kartē
> (piemēram, satiksmes organizācija utt), vai būtu OK, ja tās tiktu sūtītas
> šajā listē?
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
>
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv