[Talk-us] Whole-US Garmin Map update - 2020-02-02

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-02-02

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-02-02/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-02-02

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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

[talk-au] Airborne Research Australia South Australia Bushfire Imagery

[Andrew Harvey]

Airborne Research Australia has been flying aerial imagery around Adelaide
Hills and Kangaroo Island released under CC BY-NC-SA 4.0
https://www.airborneresearch.org.au/fires-2020.

I've sent an email with the imagery tracing waiver to ask for permission to
use for tracing into OSM. I'll update here if I hear back.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Australian guidelines for mapping landuse-landcover?

[Andrew Harvey]

I'm for just deleting this page.

While I agree the Australian Tagging Guidelines is getting long, I'd be
concerned splitting it up would make it harder to find content, so I'm on
the fence on that.

On Wed, 5 Feb 2020 at 13:28, Warin <61sundow...@gmail.com> wrote:

> Hi,
>
>  There is a page on the wiki for mapping landuse in Australia..
>
> https://wiki.openstreetmap.org/wiki/Mapping_Landuse_in_Australia
>
> It is rather dated, carries little information and appears to have no real 
> Australian content.
>
> And it does not link to the Australian pages.
>
> The page  https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines
>
> is getting rather large, I would not suggest adding landuse to it, rather a 
> link to the other page and up date it to something better?
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[talk-au] Australian guidelines for mapping landuse-landcover?

[Warin]

Hi,

There is a page on the wiki for mapping landuse in Australia..

https://wiki.openstreetmap.org/wiki/Mapping_Landuse_in_Australia  


It is rather dated, carries little information and appears to have no real 
Australian content.

And it does not link to the Australian pages.

The pagehttps://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines

is getting rather large, I would not suggest adding landuse to it, rather a 
link to the other page and up date it to something better?

 

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

Re: [talk-ph] Street or road name suffixes

[Erwin Olario]

I disagree with adding abbreviations to street names. The observation that
map renders automatically render them are limited to certain styles, and
won't apply to OSM data used elsewhere.

Notwithstanding the on-the-ground rule of the thumb, the standing
convention for abbreviations is ** don't do it**.
https://osmorg/wiki/Names#Abbreviation_.28don.27t_do_it.29



- - - - - - - - - - - - - - - - - - -
» email: erwin@ *n**gnu**it**y**.xyz*
 | gov...@gmail.com
» mobile: https://t.me/GOwin
» OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B


On Tue, Feb 4, 2020 at 11:14 AM Jherome Miguel 
wrote:

> Our present convention on street/road name suffixes, contributed by Rally
> since 2015, is to better not include them on the name if they could just
> create unnecessary clutter, but since there are already map renderers that
> can automatically abbreviate them, I think we should be changing this view.
> We should preferably stick on the on-the-ground rule on road/street names:
> if the signs (official road signs or shop signs) show a suffix, we should
> be including them rather than dropping them because there are no software
> that can handle such "map clutter" yet.
>
> -TagaSanPedroAko
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk-fr] Proposition de mise à jour : la population des communes

[Donat ROBAUX]

Hello,

Juste pour info, on est actuellement à 70.32%!!!
Il est peut-être temps de finir ca par une édition en masse VdCT? Histoire
d'être prêt pour les municipales, non?
A moins que d'autres contributeurs soient encore intéressés pour contribuer
à ce sujet?

Mais on me dit dans l'oreillette qu'un Projet du mois se prépare sur un
autre sujet...

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-GB] Still too many universities in Cambridge

[Paul Berry]

Indeed, so long as you ignore https://www.openstreetmap.org/way/52528295,
https://www.openstreetmap.org/way/134635221, etc ;)

Feel free to adjust the mapping!

Regards,
*Paul*

> By the way, there is at least one "sensibly mapped" university in
> Cambridge:
>
> https://www.openstreetmap.org/way/3987047
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[rainerU]

Am 04.02.20 um 16:42 schrieb Christian Quest:


Rue Luchino Visconti 661365195R
Rue Georges Claude 661361048H


661363128U RUE LOUIS VISCONTI
661360858B AV GEORGES ET CLAUDE CAUSTIER



La DGFiP ne modifie semble-t-il jamais un libellé, mais préfère annuler 
l'ancienne entrée dans FANTOIR et en créer une nouvelle, ce qui est visiblement 
le cas pour les deux exemples cités.




Dans les deux cas, il s'agit d'une suppression. Il y a eu une rue Louis Visconti 
(architecte français), puis on a créé la rue Luchino Visconti (réalisateur 
italien). On a du s'apercevoir que d'avoir deux rues Visconti n'était pas une 
bonne idée et on a supprimé la rue Luchino Visconti. Pareil pour Georges et 
Claude Caustier, sauf que là on a supprimé la rue George Claude (scientifique) 
existante pour pouvoir créer la rue Georges et Claude Caustier (industriels 
locaux). Comme les deux noms supprimés figurent toujours sur le plan cadastral 
quelqu'un les a saisi dans OSM.



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

Re: [Talk-GB] Still too many universities in Cambridge

[Russ Garrett]

On Tue, 4 Feb 2020 at 21:37, Alan Mackie  wrote:
> On a completely unrelated note. Does any software actually support site 
> relations?

openinframap.org does, for power plants (wind farms etc). I suspect it
may be the only one.

-- 
Russ Garrett
r...@garrett.co.uk

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

Re: [Talk-GB] Still too many universities in Cambridge

[Alan Mackie]

On Tue, 4 Feb 2020 at 15:46, Mateusz Konieczny via Talk-GB <
talk-gb@openstreetmap.org> wrote:

>
>
>
> Feb 4, 2020, 16:37 by talk-gb@openstreetmap.org:
>
> >> (Ironically, the current tagging makes it hard for me to search to see
> >> if there's a "proper" amenity=university in there somewhere, e.g. as a
> >> relation or area covering a large swathe of them.)
> >
> >There isn't, I'm afraid.. it's a right hotchpotch
> IMHO, it would be a waste of time, if you tried to create a single area
> object (do I mean "closed way"?) to be the university.
>
> Or multipolygon, like for https://www.openstreetmap.org/relation/3830877
>
> The University is a collection of colleges, so could be a relation...
>  ...except that each college is probably in several buildings and they may
> not be in a contiguous area, so each college might have to be a relation of
> buildings.  So you would have a hierarchy of relations.
>
> Or areas that belong to multipolygon of college and multipolygon of
> university (?)
>
> We used to enjoy the look of puzzlement on the faces of (mostly American)
> tourists, who stood in the middle of town, surrounded by colleges, mixed in
> with shops, offices and other buildings, and asked which way to go to the
> University.
>
> :) In this case university multipolygon (or closed way) covering most of
> city center
> sounds correct and would help OSM-using tourists.
> 
>

Isn't this what site relations are for? That way POI nodes etc also
belonging to the University can be included.

On a completely unrelated note. Does any software actually support site
relations?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Semafori per allerta meteo

[Stefano]

Il giorno mar 4 feb 2020 alle ore 19:07 Mannivu  ha
scritto:

> Recentemente nella mia città sono stati installati due "semafori" per
> l'allera meteo. [1][2] Praticamente, vengono utilizzati quando la
> Protezione civile emana un comunicato di allerta meteo e segnalano se la
> strada è percorribile oppure no. Il mio dubbio è: che tag dovrei
> utilizzare per mapparli correttamente?
>

Ciao,
uno di quelli di Genova era stato mappato da Ale_Zena come emergency=alarm
https://www.openstreetmap.org/node/3811705822


>
> Manuel
>

Stefano


>
>
> [1] https://i.imgur.com/qHrV1vC.jpg
> [2] https://i.imgur.com/hDuT7ta.jpg
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[Jérôme Seigneuret]

Bon ben c'est bien ça ! Au moins on a la totale côté voirie

Le mar. 4 févr. 2020 à 19:04, Vincent de Château-Thierry 
a écrit :

>
> > De: "Jérôme Seigneuret" 
>
> > On a déjà fait quelques chose pour les codes Fantoir mis sur OSM mais
> > non reconnu dans la dernière version de FANTOIR? Vu que certains les
> > mettent un peu en automatique. Osmose ou autre?
>
> Ils sont visibles ici :
> http://dev.cadastre.openstreetmap.fr/fantoir/fantoir_errone.html
>
> vincent
>
> ___
> 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] Semafori per allerta meteo

[Mannivu]

Recentemente nella mia città sono stati installati due "semafori" per 
l'allera meteo. [1][2] Praticamente, vengono utilizzati quando la 
Protezione civile emana un comunicato di allerta meteo e segnalano se la 
strada è percorribile oppure no. Il mio dubbio è: che tag dovrei 
utilizzare per mapparli correttamente?


Manuel


[1] https://i.imgur.com/qHrV1vC.jpg
[2] https://i.imgur.com/hDuT7ta.jpg

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

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[Vincent de Château-Thierry]

> De: "Jérôme Seigneuret" 

> On a déjà fait quelques chose pour les codes Fantoir mis sur OSM mais
> non reconnu dans la dernière version de FANTOIR? Vu que certains les
> mettent un peu en automatique. Osmose ou autre?

Ils sont visibles ici : 
http://dev.cadastre.openstreetmap.fr/fantoir/fantoir_errone.html

vincent

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

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[Jérôme Seigneuret]

On a déjà fait quelques chose pour les codes Fantoir mis sur OSM mais non
reconnu dans la dernière version de FANTOIR? Vu que certains les mettent un
peu en automatique. Osmose ou autre?

Le mar. 4 févr. 2020 à 16:49,  a écrit :

>
> Le 04/02/2020 à 16:42, Christian Quest - cqu...@openstreetmap.fr a écrit :
> > La DGFiP ne modifie semble-t-il jamais un libellé, mais préfère
> > annuler l'ancienne entrée dans FANTOIR et en créer une nouvelle, ce
> > qui est visiblement le cas pour les deux exemples cités.
>
> Intéressante gestion de version. C'est bon à savoir ! Donc si jamais ils
> voient qu'on a noté une erreur, on va avoir un nouveau numéro FANTOIR
> qui avec un peu de chance sera reconnecté automatiquement à la bonne
> voie. Oui, je sais, les erreurs qu'on note ne sont pas
> remontées, il faudrait que Christian remonte son service Minitel pour
> qu'ils sachent y accéder^^.
>
> Jean-Yvon
>
>
>
> ___
> 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-se] Hosting my own Hydda tileset

[Anders Jonsson]

On 2020-02-03 10:40, Thibaut Estublier via Talk-se wrote:

Hello,

I'm the main developer of a website hosted in France, using a map with 
Openstreetmap + Leaflet.


Actually, our map tiles are all provided by external servers. We're 
mainly using the Hydda Tileset you provide.


We've been gradually growing, and would now like to host our own tile 
server. We'd like to be able to maintain our own infrastructure, and 
also host it in France to provide a faster browsing experience to our 
customers.


Furthermore, if our user base goes up, I don't want to saturate 
someone's server bandwith or impact everyone's usage. I guess hosting 
my own tileset is the way to go.



Is the Hydda tileset available to download? Does the license authorize 
such a use of your tileset?


Is this the repository you are looking for? In that case it's Apache 
License 2.0: 
https://github.com/karlwettin/tilemill-style-hydda/blob/master/LICENSE





Thanks in advance,


- Thibaut


Regards,
Anders

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

Re: [OSM-talk-fr] wiki JOSM : Mise en Forme de la page Fr:Help/Action/Help modifiée par anonyme

[Philippe Verdy]

Le wiki de JOSM effectivement n'utilise pas Mediawiki mais un autre
logiciel avec son balisage proche (Trackwiki), mais un peu différent de
Mediawiki.

Cependant j'ai des gros doutes sur ":*" pour imbriquer un élément tabulé
dans une éléments de liste à puce, et je ne crois pas que la logique soit
différente.

Pour le wiki Trackwiki de JOSM le ":" ne sert pas à indenter, ce sont des
espaces en tête de ligne. Si on utilise "*" on va créer une
sous-liste (ce logiciel wiki n'utilise pas les "**" multiples comme
Mediawiki pour indiquer le niveau, c'est l'indentation du code source qui
le fait, on ne met qu'une seule "*" pour chaque élément de liste ou de
sous-liste).

Pour indenter un bloc *dans* un élément sans rompre la liste dont fait
partie l'élément dans Trackwiki, on ne met alors que des espaces en
indentant davantage le paragraphe que la puce précédente, et rien d'autre,
donc alors que des espaces.

L'indentation de bloc de Trackwiki utilise "::" (accolés) pour une liste de
définitions, juste après le terme défini (optionnel).

On pourrait donc utiliser "::" pour
continuer l'élément précédent commençant par un "*" moins indenté.



Le mar. 4 févr. 2020 à 17:50, leni  a écrit :

> Ce que tu dis fonctionne sur le wiki osm, mais ne semble pas fonctionner
> sur celui de josm, les commandes semblent être différentes
>
>
> Le 26/01/2020 à 11:39, Philippe Verdy a écrit :
>
> Non, c'est bien "*:" car les marqueurs de listes imbriqués conservent leur
> ordre du niveau de base au niveau imbriqué.
> "*:" signifie que c'est un élément de sous-liste (liste de définition)
> dans un élément de liste à puce (commencé aux lignes précédentes).
> si tu mets ":*" tu auras une sous-liste à puce dans une nouvelle liste
> indentée, et tu romps la liste à puces commencée à la ligne précédente.
>
> Le dim. 26 janv. 2020 à 11:02, leni  a écrit :
>
>>
>> Le 20/01/2020 à 01:05, Philippe Verdy a écrit :
>> > Je ne vois pas de changement de "mise en forme" hormis une
>> > wikification de liste avec des "*" (puces) au lieu des numéros (qui
>> > supposerait un ordre)
>> > C'est somme toute mineur, et ça reste malgré tout une traduction
>> conforme.
>> qui risque disparaitre s'il y a une modification de la page anglaise,
>> j'espérais que la personne était sur la liste et ferait la modif
>> également sur la page originale
>> > Ceci dit ce n'est pas une "liste" valide puisque les éléments
>> > détaillés ont été "indentés" hors liste.
>> > On peut proposer le changement correct (supprimer les numéros non
>> > significatifs par des puces, et non pas indenter le détail avec des
>> > espaces (qui créent un bloc de code) après chaque liste limitée à un
>> > seul item mais avec "*:", afin de conserver la liste non rompue, et en
>> > profiter pour supprimer les barres obliques inverses en fin de ligne)
>> > dans la page anglaise
>> > Sans doute quelqu'un qui ne connait pas bien la syntaxe wiki et croit
>> > pouvoir l'utiliser correctement, mais à moitié en ne voyant pas que
>> > cela ne crée pas une vraie liste mais trois séparées, suivies chacune
>> > d'un bloc indenté.
>>
>> Ce ne serait pas plutôt ":*" ?
>>
>> Je n’arrives pas à faire ce dont tu parles ; pourrais-tu me l'indiquer
>> sur cet extrait ?
>>
>>   1. With the {{{F1}}} key anywhere.\\
>> This invokes the help topic for the screen element under the mouse
>> pointer.
>> If that element has no own help topic, then the request is passed
>> downwards to the surrounding screen element.
>> Finally search ends at the [wikitr:/Help/MapView Map view] or
>> [wikitr:/Help Main help] pages as last resorts.\\
>>
>> ___
> 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] wiki JOSM : Mise en Forme de la page Fr:Help/Action/Help modifiée par anonyme

[leni]

Ce que tu dis fonctionne sur le wiki osm, mais ne semble pas fonctionner 
sur celui de josm, les commandes semblent être différentes



Le 26/01/2020 à 11:39, Philippe Verdy a écrit :
Non, c'est bien "*:" car les marqueurs de listes imbriqués conservent 
leur ordre du niveau de base au niveau imbriqué.
"*:" signifie que c'est un élément de sous-liste (liste de définition) 
dans un élément de liste à puce (commencé aux lignes précédentes).
si tu mets ":*" tu auras une sous-liste à puce dans une nouvelle liste 
indentée, et tu romps la liste à puces commencée à la ligne précédente.


Le dim. 26 janv. 2020 à 11:02, leni > a écrit :



Le 20/01/2020 à 01:05, Philippe Verdy a écrit :
> Je ne vois pas de changement de "mise en forme" hormis une
> wikification de liste avec des "*" (puces) au lieu des numéros (qui
> supposerait un ordre)
> C'est somme toute mineur, et ça reste malgré tout une traduction
conforme.
qui risque disparaitre s'il y a une modification de la page anglaise,
j'espérais que la personne était sur la liste et ferait la modif
également sur la page originale
> Ceci dit ce n'est pas une "liste" valide puisque les éléments
> détaillés ont été "indentés" hors liste.
> On peut proposer le changement correct (supprimer les numéros non
> significatifs par des puces, et non pas indenter le détail avec des
> espaces (qui créent un bloc de code) après chaque liste limitée
à un
> seul item mais avec "*:", afin de conserver la liste non rompue,
et en
> profiter pour supprimer les barres obliques inverses en fin de
ligne)
> dans la page anglaise
> Sans doute quelqu'un qui ne connait pas bien la syntaxe wiki et
croit
> pouvoir l'utiliser correctement, mais à moitié en ne voyant pas que
> cela ne crée pas une vraie liste mais trois séparées, suivies
chacune
> d'un bloc indenté.

Ce ne serait pas plutôt ":*" ?

Je n’arrives pas à faire ce dont tu parles ; pourrais-tu me
l'indiquer
sur cet extrait ?

  1. With the {{{F1}}} key anywhere.\\
    This invokes the help topic for the screen element under the
mouse
pointer.
    If that element has no own help topic, then the request is passed
downwards to the surrounding screen element.
    Finally search ends at the [wikitr:/Help/MapView Map view] or
[wikitr:/Help Main help] pages as last resorts.\\

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

Re: [Talk-GB] Still too many universities in Cambridge

[Andy Townsend]

On 04/02/2020 15:37, Peter Neale via Talk-GB wrote:

>There isn't, I'm afraid.. it's a right hotchpotch

IMHO, it would be a waste of time, if you tried to create a single 
area object (do I mean "closed way"?) to be the university.  That 
would just be most of the city centre.


The University is a collection of colleges, so could be a relation... 
 ...except that each college is probably in several buildings and they 
may not be in a contiguous area, so each college might have to be a 
relation of buildings.  So you would have a hierarchy of relations.



... or, if the general feeling is to go ahead with this change, just add 
a node in the vicinity of the Senate House / St Mary's Church for it.  
It'd be no less wrong.


By the way, there is at least one "sensibly mapped" university in Cambridge:

https://www.openstreetmap.org/way/3987047

Best Regards,

Andy



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

Re: [Talk-us] Mapping for emergency services

[Simon Poole]

Just a general remark: we have active fire fighters contributing and using OSM 
in many places around the globe maybe it's time for a global exchange of ideas 
and a common forum for that?

Simon

PS: unluckily HOT and FOSM are already taken so a acronym will need some work 
:-)

Am 4. Februar 2020 15:57:57 MEZ schrieb Paul Johnson :
>On Mon, Feb 3, 2020 at 8:58 AM Mike Thompson 
>wrote:
>
>> Mike,
>>
>> That is a very compelling story.  Thanks to you and the other OSM
>folks
>> involved for making it happen and to you for writing the diary entry.
> I
>> have often thought that OSM would be a great resource emergency
>responders
>> because in some areas it contains data that no one else has, but
>generally
>> the reaction that I have gotten when I have suggested this to such
>> officials was "we have our own data", "we have already invested in
>xyz
>> system" (sunk cost fallacy), or "how can we trust OSM?".  The
>exception was
>> a search and rescue group that used OSM to help locate missing people
>in
>> the back country because OSM contains trails that no other source
>has.
>>
>> Is this being publicised outside of the OSM community?  There are
>probably
>> associations for fire fighters and other emergency response
>professionals
>> and perhaps someone from the FD involved could speak about this
>project at
>> one of their conferences to get agencies in other parts of the
>country (or
>> world) interested.
>>
>
>I've been to a few furry conventions in Oklahoma where firefighters
>have
>attended and cartography has come up.  Oddly enough, for the rural
>firefighters?  Osmand with Microsoft Earth imagery as the background is
>their most popular pick because it works brilliantly offline and we
>have
>better map data than the state itself does.  The E911 system (where
>available) spits 'em a set of coordinates, so punch that in and go. 
>Hit
>the destination distance button to cache in the imagery around where
>they're going in case the exact driveway or building hasn't been mapped
>yet.

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

[Talk-in] Fwd: Maps-l Digest, Vol 101, Issue 1

[Pradeep Mohandas]

Hello,

Apologies for cross-posting. This may be mostly for your information,etc.

Sincerely,
Pradeep

-- Forwarded message -
From: 
Date: Tue, 4 Feb 2020 at 17:31
Subject: Maps-l Digest, Vol 101, Issue 1
To: 


--

Message: 1
Date: Mon, 3 Feb 2020 19:48:28 +
From: Pine W 
To: Wiki Research-l ,  Map
integration ,
"wikitec...@lists.wikimedia.org" 
Subject: [Maps-l] Fwd: [OSM-talk] W3C Maps on the Web workshop
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Forwarding.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


-- Forwarded message -
From: Rushforth, Peter (NRCan/RNCan) 
Date: Tue, Jan 28, 2020 at 9:46 PM
Subject: [OSM-talk] W3C Maps on the Web workshop
To: t...@openstreetmap.org 


Dear Open Street Map community,



I apologize if you are seeing this email for a second time. I sent it
originally to the talk-ca list, and I was advised that this list might
be more appropriate.



My name is Peter Rushforth, and I’m with the Canada Centre for Mapping
and Earth Observation, at Natural Resources Canada (a Canadian
government department).  We are planning a World Wide Web Consortium
(W3C) workshop on maps in the Web platform (specifically HTML),
together with the W3C and the Open Geospatial Consortium (OGC).  The
workshop will be collocated with the OGC Technical Committee meeting,
June 15-17 2020 in Montreal, Quebec.



I am sending this email to see if Open Street Map (especially the Web
client development teams) might be interested in being invited to
participate (by presenting a short position paper, in person) in this
workshop on the concept of better integrating mapping into the Web
platform standards, and if so, how does Open Street Map see this.
Even if you believe that the Web platform standards are already good
enough for mapping, it might be worthwhile staking that out as a
position. If you are interested, though, we would certainly welcome
OSM to also be part of the program committee.



The objective of the workshop will be to start the conversation
between the geospatial (and geospatial standards) and Web platform
communities, about how Web standards could better serve the needs of
Web mapping and most especially users of Web maps and the Web in
general.



Some topics of potential interest include:



a native map viewer, similar to that provided for video content
standards for how such a map widget might integrate with map services and
APIs
accessibility of browser maps
privacy of user location information
security of browser-based maps
Integration / relationship of maps and location with other browser
APIs, e.g. geo-video, geolocation API, forms, SVG
crawling, indexing and searching map information
standardized browser elements and APIs
CSS styling of maps and map features
Map feature creation / input forms
federated map services with linking - aka the Web



Mostly the agenda will be driven by position papers, and what
organizations like yours want to discuss.  If OSM is interested in
sending one or two people to present a position, please reply directly
to me, and I will ensure that you / they are invited.





Sincerely,

Peter





Peter Rushforth



Technology Advisor

Canada Centre for Mapping and Earth Observation

Natural Resources Canada / Government of Canada

peter.rushfo...@canada.ca / Tel: 613-759-7915



Conseiller technique

Centre canadien de cartographie et d’observation de la Terre

Ressources naturelles Canada / Gouvernement du Canada

peter.rushfo...@canada.ca / Tél: 613-759-7915



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



--

Subject: Digest Footer

___
Maps-l mailing list
map...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/maps-l


--

End of Maps-l Digest, Vol 101, Issue 1
**
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[osm . sanspourriel]

Le 04/02/2020 à 16:42, Christian Quest - cqu...@openstreetmap.fr a écrit :

La DGFiP ne modifie semble-t-il jamais un libellé, mais préfère
annuler l'ancienne entrée dans FANTOIR et en créer une nouvelle, ce
qui est visiblement le cas pour les deux exemples cités.


Intéressante gestion de version. C'est bon à savoir ! Donc si jamais ils
voient qu'on a noté une erreur, on va avoir un nouveau numéro FANTOIR
qui avec un peu de chance sera reconnecté automatiquement à la bonne
voie. Oui, je sais, les erreurs qu'on note ne sont pas
remontées, il faudrait que Christian remonte son service Minitel pour
qu'ils sachent y accéder^^.

Jean-Yvon



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

Re: [Talk-GB] Still too many universities in Cambridge

[Mateusz Konieczny via Talk-GB]

Feb 4, 2020, 16:37 by talk-gb@openstreetmap.org:

> >> (Ironically, the current tagging makes it hard for me to search to see
> >> if there's a "proper" amenity=university in there somewhere, e.g. as a
> >> relation or area covering a large swathe of them.)
> >
> >There isn't, I'm afraid.. it's a right hotchpotch
> IMHO, it would be a waste of time, if you tried to create a single area 
> object (do I mean "closed way"?) to be the university.  
>
Or multipolygon, like for https://www.openstreetmap.org/relation/3830877

> The University is a collection of colleges, so could be a relation...   
> ...except that each college is probably in several buildings and they may not 
> be in a contiguous area, so each college might have to be a relation of 
> buildings.  So you would have a hierarchy of relations.
>
Or areas that belong to multipolygon of college and multipolygon of university 
(?)

> We used to enjoy the look of puzzlement on the faces of (mostly American) 
> tourists, who stood in the middle of town, surrounded by colleges, mixed in 
> with shops, offices and other buildings, and asked which way to go to the 
> University.
>
:) In this case university multipolygon (or closed way) covering most of city 
center 
sounds correct and would help OSM-using tourists.

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

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[Christian Quest]

Le 04/02/2020 à 08:42, Vincent de Château-Thierry a écrit :

Bonjour,

Le 04/02/2020 à 08:02, rainerU a écrit :


J'ai constaté que dans la liste des voies inconnues dans FANTOIR on 
trouve des rues qui sont bien dans liste brute FANTOIR. Exemples pour 
la ville de Perpignan 66136 :


Rue Luchino Visconti 661365195R
Rue Georges Claude 661361048H


Pour les rapprochements je ne tiens pas compte des voies FANTOIR 
annulées. Dans tes 2 cas ce sont des voies ayant été annulées dans 
FANTOIR. Pour chacune on a des rues au nom très proche, c'est 
peut-être une raison de leur annulation pour éviter les confusions :


661363128U RUE LOUIS VISCONTI
661360858B AV GEORGES ET CLAUDE CAUSTIER



La DGFiP ne modifie semble-t-il jamais un libellé, mais préfère annuler 
l'ancienne entrée dans FANTOIR et en créer une nouvelle, ce qui est 
visiblement le cas pour les deux exemples cités.



--
Christian Quest - OpenStreetMap France


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

Re: [Talk-GB] Still too many universities in Cambridge

[Mateusz Konieczny via Talk-GB]

Feb 4, 2020, 15:14 by talk-gb@openstreetmap.org:

> Hi
> There was a discussion 5 years ago. There may have been others.
> https://lists.openstreetmap.org/pipermail/talk-gb/2015-May/017455.html
>
> Many amenity=university tags were added unnecessarily to building=yes
> A contributor had converted these to building=university, in accordance with 
> the wiki. https://wiki.openstreetmap.org/wiki/Tag:building%3Duniversity
>
> https://www.openstreetmap.org/changeset/40649767
> This allows the removal of the amenity tags without loss of data.
>
+1

I assume that individual buildings are not separate universities? I would expect
one area (maybe multipolygon) for one university.

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

Re: [Talk-GB] Still too many universities in Cambridge

[Peter Neale via Talk-GB]

>> (Ironically, the current tagging makes it hard for me to search to see
>> if there's a "proper" amenity=university in there somewhere, e.g. as a
>> relation or area covering a large swathe of them.)
>
>There isn't, I'm afraid.. it's a right hotchpotch

IMHO, it would be a waste of time, if you tried to create a single area object 
(do I mean "closed way"?) to be the university.  That would just be most of the 
city centre.   
The University is a collection of colleges, so could be a relation...   
...except that each college is probably in several buildings and they may not 
be in a contiguous area, so each college might have to be a relation of 
buildings.  So you would have a hierarchy of relations.
Then, I assume that there will be some buildings that belong to the University, 
but not to any college.  That was certainly true of my Uni (it lies about 70 
miles West of Cambridge and is a darker blue), where the Engineering Building, 
Physics labs, Museum, Examination Halls were all University assets. We used to 
enjoy the look of puzzlement on the faces of (mostly American) tourists, who 
stood in the middle of town, surrounded by colleges, mixed in with shops, 
offices and other buildings, and asked which way to go to the University.
Regards,Peter

On Tuesday, 4 February 2020, 15:15:38 GMT, Dave F via Talk-GB 
 wrote:  
 
 On 04/02/2020 14:28, Dan S wrote:
> Hi Dave,
>
> I agree with what you suggest. Can we be a bit precise though about
> what you propose? You're proposing to remove amenity=university from
> building=university in Cambridge, and make no other tagging changes?

That's correct. I'm going to load the 1050 return by this overpass query 
into JOSM:
[bbox:{{bbox}}];
nwr[amenity=university][building=university];
out meta geom;

plus another 7 which are still tagged as building=yes.

> (Ironically, the current tagging makes it hard for me to search to see
> if there's a "proper" amenity=university in there somewhere, e.g. as a
> relation or area covering a large swathe of them.)

There isn't, I'm afraid.. it's a right hotchpotch

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

These are the remaining 117 amenity=university which will need to be 
rectified at a later date..

Cheers
DaveF
> Op di 4 feb. 2020 om 14:15 schreef Dave F via Talk-GB
> :
>> Hi
>> There was a discussion 5 years ago. There may have been others.
>> https://lists.openstreetmap.org/pipermail/talk-gb/2015-May/017455.html
>>
>> Many amenity=university tags were added unnecessarily to building=yes
>> A contributor had converted these to building=university, in accordance
>> with the wiki. https://wiki.openstreetmap.org/wiki/Tag:building%3Duniversity
>>
>> https://www.openstreetmap.org/changeset/40649767
>> This allows the removal of the amenity tags without loss of data.
>>
>> The user who created his disparate tagging schema has had plenty of time
>> to rectify.  I think this should be performed now.
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb


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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[marc marc]

if the primary goal is to render according to gender, shouldn't the
workflow sort the streets according to the available information (all
the "Virginia A. streets" are probably female, right?) in order to
target first the streets where the gender is unknown (no first name or
abbreviation to expend in osm).

i find it very difficult to find the etymology of a street : it's not
because there is a very well known "Jean de la Fontaine" that all the
"Rue Jean de la Fontaine" talk about him. we risk adding supposed
information which would destroy the interest of the tag
name:etymology:wikidata when it's not necessary for gender rendering.

Le 04.02.20 à 15:41, Midgard a écrit :
> I'd strongly suggest including an easy default path for when people aren't 
> sure.
> If you use a completion metric, choosing "not sure" should imo also increase 
> the completion
> percentage, so that people are less psychologically pushed to add such data.
> 
> Additionally, if someone chose "not sure" and a second person chooses "not 
> sure", I would avoid
> showing it to any more people.
> 
> Why?
> 
> Adding name:etymology:wikidata is not that trivial. It requires some 
> dedication. In the examples
> below, I'm afraid that people who are given just the goal of completing 
> gender will be inclined to
> just pick one. That's harmful to the data quality.
> 
> Some examples from my experience Wikidatafying Blankenberge:
> There's just a surname:
> - Mametstraat: David, Zosia, Raymond, Clara, Magda, Julien...
> 
> or an initial letter and surname:
> - J. De Meyerstraat: lots of people match that
> 
> or the street has first and last name, but there are multiple people 
> called like that:
> - Maurits Sabbepad: a writer, but also a theologian
> 
> or you can't find any information:
> - Frans Feverystraat: The top search results for "Frans Fevery" are 
> about the street. :p
>   You could create a Wikidata item for them, see 
> the last paragraph.
> 
> I was planning to bother my municipality to make them help me 
> disambiguating those, based on
> the records of the street name decision process.
> 
> Some other challenges:
> Different spellings (should be added to "also known as" in Wikidata when 
> found):
> - Albert Ruzettelaan: in Wikidata as "Albéric Ruzette"
> This could result in duplicate entries.
> 
> Often you have to take into account the context:
> - Albertstraat and Elisabethstraat running in parallel: Albert I and 
> his wife
> - lots of surnames of painters in same neighbourhood
> 
> Streets named after non-persons. If you use completion metric, how will 
> you deal with them? In
> Blankenberge, I have been adding the thing they're named after.
> - Vissersstraat: fisher
> 
> But sometimes, it's just not clear what they're named after:
> - Duindistellaan: I can't find any indication that this is a real 
> plant. Just a thistle
>   that happens to grow in the dunes?
> - Colombus (not Columbus)
> 
> If it's clear a person has no item yet, one should be created. It's nice if 
> some research is done:
> what made them famous enough to get a street name? Sometimes you find 
> something, sometimes you
> don't. In the latter case you can create a rather uninformative item with 
> just "instance of: human"
> and "sex or gender". But when there's information available on the web, imo 
> it would be a shame not
> to add it.
> 
> Kind regards,
> Midgard
> 
> Quoting Santens Seppe (2020-02-04 12:52:57)
>> True, but of course a nice thing to do.
>>
>> Van: Pieter Vander Vennet [mailto:pieterv...@posteo.net]
>> Verzonden: dinsdag 4 februari 2020 12:23
>> Aan: winfi...@gmail.com; OpenStreetMap Belgium
>> Onderwerp: Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data
>>
>> Hey Jo,
>>
>> Afaik there is no need to create an wikidata for the street.
>> Met vriendelijke groeten,
>> Pieter Vander Vennet
>> On February 4, 2020 12:06:46 PM GMT+01:00, Jo  wrote:
>> Hi,
>>
>> I did this for one street in Evere: 
>> https://www.openstreetmap.org/way/523050554/history
>>
>> Took me more than half an hour for a single street (no automation). I 
>> created a wikidata entry both for the person and for the street itself. 
>> Things are complicated by the bilingual nature of the city and because this 
>> street also had an old name.
>>
>> Is that what we will be doing? Or did I somehow misunderstand?
>>
>> Polyglot
>>
>> On Mon, Feb 3, 2020 at 4:34 PM Santens Seppe  wrote:
>> Hi community,
>>
>> Open Knowledge Belgium, OpenStreetMap Belgium and Wikimedia Belgium want to 
>> map all the streetnames by gender in Brussels, as a first step to change the 
>> imbalance in reality. We need your help on 17/02 to get the OSM data linked 
>> to wikidata.
>> Register here to join the mapping effort: 
>> 

Re: [Talk-GB] Still too many universities in Cambridge

[Dave F via Talk-GB]

On 04/02/2020 14:28, Dan S wrote:

Hi Dave,

I agree with what you suggest. Can we be a bit precise though about
what you propose? You're proposing to remove amenity=university from
building=university in Cambridge, and make no other tagging changes?


That's correct. I'm going to load the 1050 return by this overpass query 
into JOSM:

[bbox:{{bbox}}];
nwr[amenity=university][building=university];
out meta geom;

plus another 7 which are still tagged as building=yes.


(Ironically, the current tagging makes it hard for me to search to see
if there's a "proper" amenity=university in there somewhere, e.g. as a
relation or area covering a large swathe of them.)


There isn't, I'm afraid.. it's a right hotchpotch

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

These are the remaining 117 amenity=university which will need to be 
rectified at a later date..


Cheers
DaveF

Op di 4 feb. 2020 om 14:15 schreef Dave F via Talk-GB
:

Hi
There was a discussion 5 years ago. There may have been others.
https://lists.openstreetmap.org/pipermail/talk-gb/2015-May/017455.html

Many amenity=university tags were added unnecessarily to building=yes
A contributor had converted these to building=university, in accordance
with the wiki. https://wiki.openstreetmap.org/wiki/Tag:building%3Duniversity

https://www.openstreetmap.org/changeset/40649767
This allows the removal of the amenity tags without loss of data.

The user who created his disparate tagging schema has had plenty of time
to rectify.  I think this should be performed now.

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



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

Re: [Talk-us] Mapping for emergency services

[Paul Johnson]

On Mon, Feb 3, 2020 at 8:58 AM Mike Thompson  wrote:

> Mike,
>
> That is a very compelling story.  Thanks to you and the other OSM folks
> involved for making it happen and to you for writing the diary entry.  I
> have often thought that OSM would be a great resource emergency responders
> because in some areas it contains data that no one else has, but generally
> the reaction that I have gotten when I have suggested this to such
> officials was "we have our own data", "we have already invested in xyz
> system" (sunk cost fallacy), or "how can we trust OSM?".  The exception was
> a search and rescue group that used OSM to help locate missing people in
> the back country because OSM contains trails that no other source has.
>
> Is this being publicised outside of the OSM community?  There are probably
> associations for fire fighters and other emergency response professionals
> and perhaps someone from the FD involved could speak about this project at
> one of their conferences to get agencies in other parts of the country (or
> world) interested.
>

I've been to a few furry conventions in Oklahoma where firefighters have
attended and cartography has come up.  Oddly enough, for the rural
firefighters?  Osmand with Microsoft Earth imagery as the background is
their most popular pick because it works brilliantly offline and we have
better map data than the state itself does.  The E911 system (where
available) spits 'em a set of coordinates, so punch that in and go.  Hit
the destination distance button to cache in the imagery around where
they're going in case the exact driveway or building hasn't been mapped
yet.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Midgard]

I'd strongly suggest including an easy default path for when people aren't sure.
If you use a completion metric, choosing "not sure" should imo also increase 
the completion
percentage, so that people are less psychologically pushed to add such data.

Additionally, if someone chose "not sure" and a second person chooses "not 
sure", I would avoid
showing it to any more people.

Why?

Adding name:etymology:wikidata is not that trivial. It requires some 
dedication. In the examples
below, I'm afraid that people who are given just the goal of completing gender 
will be inclined to
just pick one. That's harmful to the data quality.

Some examples from my experience Wikidatafying Blankenberge:
There's just a surname:
- Mametstraat: David, Zosia, Raymond, Clara, Magda, Julien...

or an initial letter and surname:
- J. De Meyerstraat: lots of people match that

or the street has first and last name, but there are multiple people called 
like that:
- Maurits Sabbepad: a writer, but also a theologian

or you can't find any information:
- Frans Feverystraat: The top search results for "Frans Fevery" are 
about the street. :p
  You could create a Wikidata item for them, see 
the last paragraph.

I was planning to bother my municipality to make them help me 
disambiguating those, based on
the records of the street name decision process.

Some other challenges:
Different spellings (should be added to "also known as" in Wikidata when 
found):
- Albert Ruzettelaan: in Wikidata as "Albéric Ruzette"
This could result in duplicate entries.

Often you have to take into account the context:
- Albertstraat and Elisabethstraat running in parallel: Albert I and 
his wife
- lots of surnames of painters in same neighbourhood

Streets named after non-persons. If you use completion metric, how will you 
deal with them? In
Blankenberge, I have been adding the thing they're named after.
- Vissersstraat: fisher

But sometimes, it's just not clear what they're named after:
- Duindistellaan: I can't find any indication that this is a real 
plant. Just a thistle
  that happens to grow in the dunes?
- Colombus (not Columbus)

If it's clear a person has no item yet, one should be created. It's nice if 
some research is done:
what made them famous enough to get a street name? Sometimes you find 
something, sometimes you
don't. In the latter case you can create a rather uninformative item with just 
"instance of: human"
and "sex or gender". But when there's information available on the web, imo it 
would be a shame not
to add it.

Kind regards,
Midgard

Quoting Santens Seppe (2020-02-04 12:52:57)
> True, but of course a nice thing to do.
> 
> Van: Pieter Vander Vennet [mailto:pieterv...@posteo.net]
> Verzonden: dinsdag 4 februari 2020 12:23
> Aan: winfi...@gmail.com; OpenStreetMap Belgium
> Onderwerp: Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data
> 
> Hey Jo,
> 
> Afaik there is no need to create an wikidata for the street.
> Met vriendelijke groeten,
> Pieter Vander Vennet
> On February 4, 2020 12:06:46 PM GMT+01:00, Jo  wrote:
> Hi,
> 
> I did this for one street in Evere: 
> https://www.openstreetmap.org/way/523050554/history
> 
> Took me more than half an hour for a single street (no automation). I created 
> a wikidata entry both for the person and for the street itself. Things are 
> complicated by the bilingual nature of the city and because this street also 
> had an old name.
> 
> Is that what we will be doing? Or did I somehow misunderstand?
> 
> Polyglot
> 
> On Mon, Feb 3, 2020 at 4:34 PM Santens Seppe  wrote:
> Hi community,
> 
> Open Knowledge Belgium, OpenStreetMap Belgium and Wikimedia Belgium want to 
> map all the streetnames by gender in Brussels, as a first step to change the 
> imbalance in reality. We need your help on 17/02 to get the OSM data linked 
> to wikidata.
> Register here to join the mapping effort: 
> https://eventbrite.co.uk/e/towards-equal-street-names-with-open-data-registration-92536026747.
>  And let us know if you can help with the framework.
> 
> 
> more info: 
> https://be.okfn.org/2020/02/03/towards-equal-street-names-with-open-data/
> 
> Please spread the word!
> -Twitter: https://twitter.com/OpenKnowledgeBE/status/1224291464496193538
> -Facebook: https://www.facebook.com/events/2852981998057886/
> -Eventbrite: http://equalstreetnamesbrussels.eventbrite.co.uk/
> 
> 
> Seppe

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

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Michael Reichert]

Hi,

Am 04/02/2020 um 15.25 schrieb Frederik Ramm:
> Hm, the wording is a bit unfortunate really. Of course this "internal
> use only" applies to the personal data in the file which according to
> (the LWG's interpretation of) the GDPR is ok to use for OSM's own
> purposes but not for blasting it out into the world. The
> non-personal-data history is free for everyone to use, and Geofabrik
> *could* actually make two different history files available, one with
> and one without user data, it's just that these files are a niche
> interest anyway so we thought one version is sufficient.
> 
> This means that if you derive anything like an animated map from the
> data, that's totally fine; only if you were to publish something that
> involves user data should you think twice about your data protection
> regulations.

You can strip the history files from osm-internal.download.geofabrik.de
using the following Osmium command to get OSM data with fewer legal
risks in terms of personal data:

osmium cat --output-format pbf,metadata=version+timestamp \
  -o output.osh.pbf input.osh.pbf

Best regards

Michael



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

Re: [Talk-GB] Still too many universities in Cambridge

[Dan S]

Hi Dave,

I agree with what you suggest. Can we be a bit precise though about
what you propose? You're proposing to remove amenity=university from
building=university in Cambridge, and make no other tagging changes?

(Ironically, the current tagging makes it hard for me to search to see
if there's a "proper" amenity=university in there somewhere, e.g. as a
relation or area covering a large swathe of them.)

Best
Dan

Op di 4 feb. 2020 om 14:15 schreef Dave F via Talk-GB
:
>
> Hi
> There was a discussion 5 years ago. There may have been others.
> https://lists.openstreetmap.org/pipermail/talk-gb/2015-May/017455.html
>
> Many amenity=university tags were added unnecessarily to building=yes
> A contributor had converted these to building=university, in accordance
> with the wiki. https://wiki.openstreetmap.org/wiki/Tag:building%3Duniversity
>
> https://www.openstreetmap.org/changeset/40649767
> This allows the removal of the amenity tags without loss of data.
>
> The user who created his disparate tagging schema has had plenty of time
> to rectify.  I think this should be performed now.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Frederik Ramm]

Hi,

On 04.02.20 14:10, Colin Smale wrote:
>> The Geofabrik download server has full history files for every region it
>> offers. Unlike the non-history extracts. these files are only available
>> for users who log in with their OSM user name.
 
> Aah, thanks Frederik, I didn't know about this. But the text on the site
> seems to imply that it is only for "internal use" and I cannot use this
> data for a public service, e.g. a website to animate changes in admin
> boundaries. Can I get round that by cleaning out certain data?

Hm, the wording is a bit unfortunate really. Of course this "internal
use only" applies to the personal data in the file which according to
(the LWG's interpretation of) the GDPR is ok to use for OSM's own
purposes but not for blasting it out into the world. The
non-personal-data history is free for everyone to use, and Geofabrik
*could* actually make two different history files available, one with
and one without user data, it's just that these files are a niche
interest anyway so we thought one version is sufficient.

This means that if you derive anything like an animated map from the
data, that's totally fine; only if you were to publish something that
involves user data should you think twice about your data protection
regulations.

Bye
Frederik

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

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

[Talk-GB] Still too many universities in Cambridge

[Dave F via Talk-GB]

Hi
There was a discussion 5 years ago. There may have been others.
https://lists.openstreetmap.org/pipermail/talk-gb/2015-May/017455.html

Many amenity=university tags were added unnecessarily to building=yes
A contributor had converted these to building=university, in accordance 
with the wiki. https://wiki.openstreetmap.org/wiki/Tag:building%3Duniversity


https://www.openstreetmap.org/changeset/40649767
This allows the removal of the amenity tags without loss of data.

The user who created his disparate tagging schema has had plenty of time 
to rectify.  I think this should be performed now.


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

Re: [OSM-talk-fr] Import massif dans OSM

[Jérôme Seigneuret]

Oui c'est faisable sous Josm et en important les données osm existante avec
overpass. Le plugin conflate est ton ami

Le sam. 1 févr. 2020 à 10:12, Cédric Frayssinet  a
écrit :

> Bonjour à tous,
>
> Les 2 associations lyonnaises Pleinlavue et RAP ont obtenu de la part de
> la Métropole de Lyon, le fichier des implantations des panneaux
> publicitaires (joliment appelé mobilier urbain), notamment JCDecaux :
> https://data.grandlyon.com/jeux-de-donnees/mobilier-urbain-metropole-lyon/donnees
>
> C'est très complet. Actuellement, nous en sommes là au niveau cartographie
> : https://openadvertmap.pavie.info/#15/45.7649/4.8400 (que nous réalisons
> avec MapContrib).
>
> Nous aimerions injecter ce fichier dans OSM pour compléter l'existant,
> tout en n'écrasant par les différents POI qui pourraient exister.
>
> Question 1 : est-ce faisable ?
>
> Question 2 : qui aurait une expertise là dessus pour nous aider ?
>
> Merci d'avance,
>
> Cédric
> --
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> 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] weeklyOSM #497 2020-01-21-2020-01-27

[Colin Smale]

On 2020-02-04 13:36, Frederik Ramm wrote:

> Hi,
> 
> On 04.02.20 13:22, Colin Smale wrote: 
> 
>> Correct me if I am wrong, but I don't remember ever seeing
>> regional full history files.
> 
> The Geofabrik download server has full history files for every region it
> offers. Unlike the non-history extracts. these files are only available
> for users who log in with their OSM user name.

Aah, thanks Frederik, I didn't know about this. But the text on the site
seems to imply that it is only for "internal use" and I cannot use this
data for a public service, e.g. a website to animate changes in admin
boundaries. Can I get round that by cleaning out certain data? 

> that will be millions of API calls to get the full history
> of every node, way and relation involved. If it has to be, then it has
> to be.
> Famous last words before being blocked on the API ;)

At least I would only have to do it once, throttle the rate and leave it
running for a few days, and then keep it updated with the periodical
diffs.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Cercasi traduttore per una frase

[Martin Koppenhoefer]

Am Di., 4. Feb. 2020 um 13:53 Uhr schrieb stefano campus :

> liste_girarsi wrote
> > Questa mappa utilizza i dati raccolti dai volontari di OpenStreetMap.org
> >
> > Disponibile sotto la licenza Open Database Licence. Per maggiori
> > informazioni consultare il sito https://osm.org/copyright/de.
>
> perdonate, ma tutte le traduzioni proposte mettono "Disponibile" con la D
> maiuscola, senza che prima ci sia un punto.
> a parte il "proudly", dopo OpenStreetMap.org continuerei con: "ed è
> disponibile sotto licenza  ...:"



c'è un'omissione volontaria del punto dopo la URL perché altrimente
potrebbe non funzionare bene la URL.

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

Re: [Talk-it] [evento] FOSS4G Italia 2020

[stefano campus]

ciao a tutti,
vi chiediamo la cortesia di iscrivervi nel sito ufficiale dell'evento anche
se partecipate al solo evento OSMit.
ci permetterete così di avere un quadro più realistico delle presenze totali
e ci tariamo per la pizza & birra.

grazie mille

s.

https://foss4g-it2020.gfoss.it



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

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

Re: [Talk-it] Cercasi traduttore per una frase

[stefano campus]

liste_girarsi wrote
> Questa mappa utilizza i dati raccolti dai volontari di OpenStreetMap.org
> 
> Disponibile sotto la licenza Open Database Licence. Per maggiori
> informazioni consultare il sito https://osm.org/copyright/de.

perdonate, ma tutte le traduzioni proposte mettono "Disponibile" con la D
maiuscola, senza che prima ci sia un punto.
a parte il "proudly", dopo OpenStreetMap.org continuerei con: "ed è
disponibile sotto licenza  ...:"

s.





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

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

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Frederik Ramm]

Hi,

On 04.02.20 13:22, Colin Smale wrote:
> Correct me if I am wrong, but I don't remember ever seeing
> regional full history files.

The Geofabrik download server has full history files for every region it
offers. Unlike the non-history extracts. these files are only available
for users who log in with their OSM user name.

> that will be millions of API calls to get the full history
> of every node, way and relation involved. If it has to be, then it has
> to be.

Famous last words before being blocked on the API ;)

Bye
Frederik

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

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

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Colin Smale]

I wonder how many users actually need a planet-wide planet file. Surely
there are loads of cases where a regional extract would suffice for the
use case in hand. How about encouraging people to consider using a
regional download? 

Something else, only slightly off-topic: I have often had ideas in my
head about looking at the dynamics of particular bits of data - i.e. OSM
histories. Correct me if I am wrong, but I don't remember ever seeing
regional full history files. I think there is a download available for
the entire planet with full history, but that is going to be a monster
and a real challenge to keep up-to-date. But it's the only way to get
historical data, except through the API. If I want to trace for example
the history of changes to county boundaries in the UK, or the alignment
of motorways, that will be millions of API calls to get the full history
of every node, way and relation involved. If it has to be, then it has
to be.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Santens Seppe]

True, but of course a nice thing to do.

Van: Pieter Vander Vennet [mailto:pieterv...@posteo.net]
Verzonden: dinsdag 4 februari 2020 12:23
Aan: winfi...@gmail.com; OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

Hey Jo,

Afaik there is no need to create an wikidata for the street.
Met vriendelijke groeten,
Pieter Vander Vennet
On February 4, 2020 12:06:46 PM GMT+01:00, Jo  wrote:
Hi,

I did this for one street in Evere: 
https://www.openstreetmap.org/way/523050554/history

Took me more than half an hour for a single street (no automation). I created a 
wikidata entry both for the person and for the street itself. Things are 
complicated by the bilingual nature of the city and because this street also 
had an old name.

Is that what we will be doing? Or did I somehow misunderstand?

Polyglot

On Mon, Feb 3, 2020 at 4:34 PM Santens Seppe  wrote:
Hi community,

Open Knowledge Belgium, OpenStreetMap Belgium and Wikimedia Belgium want to map 
all the streetnames by gender in Brussels, as a first step to change the 
imbalance in reality. We need your help on 17/02 to get the OSM data linked to 
wikidata.
Register here to join the mapping effort: 
https://eventbrite.co.uk/e/towards-equal-street-names-with-open-data-registration-92536026747.
 And let us know if you can help with the framework.


more info: 
https://be.okfn.org/2020/02/03/towards-equal-street-names-with-open-data/

Please spread the word!
-Twitter: https://twitter.com/OpenKnowledgeBE/status/1224291464496193538
-Facebook: https://www.facebook.com/events/2852981998057886/
-Eventbrite: http://equalstreetnamesbrussels.eventbrite.co.uk/


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

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Simon Poole]

We are talking literally about a one command "pipeline" that already does 
everything right and consumes 1% of the volume of a weekly download of the 
planet. 

Not to mention that you get a daily (or whatever you want) updated planet out 
of it that contains a defined set of diffs (contrary to the planet dump).

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

[talk-latam] Canal de XMPP: OSM en Español

[Felix Delattre via talk-latam]

Hola todes:

Quisiera invitarles para unirse al chat de XMPP/Jabber para
OpenStreetMap: xmpp:openstreet...@salas.suchat.org?join

Es la mejor alternativa para las personas quienes quisieran salir de
servicios de comunidades enjauladas, cómo Telegram, etc.

Nos vemos por allá.
Saludos,
Felix



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

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Pieter Vander Vennet]

Hey Jo,

Afaik there is no need to create an wikidata for the street.
Met vriendelijke groeten,
Pieter Vander Vennet

On February 4, 2020 12:06:46 PM GMT+01:00, Jo  wrote:
>Hi,
>
>I did this for one street in Evere:
>https://www.openstreetmap.org/way/523050554/history
>
>Took me more than half an hour for a single street (no automation). I
>created a wikidata entry both for the person and for the street itself.
>Things are complicated by the bilingual nature of the city and because this
>street also had an old name.
>
>Is that what we will be doing? Or did I somehow misunderstand?
>
>Polyglot
>
>On Mon, Feb 3, 2020 at 4:34 PM Santens Seppe 
>wrote:
>
>> Hi community,
>>
>>
>>
>> Open Knowledge Belgium, OpenStreetMap Belgium and Wikimedia Belgium want
>> to map all the streetnames by gender in Brussels, as a first step to change
>> the imbalance in reality. We need your help on 17/02 to get the OSM data
>> linked to wikidata.
>>
>> Register here to join the mapping effort:
>> https://eventbrite.co.uk/e/towards-equal-street-names-with-open-data-registration-92536026747.
>> And let us know if you can help with the framework.
>>
>>
>>
>>
>>
>> more info:
>> https://be.okfn.org/2020/02/03/towards-equal-street-names-with-open-data/
>>
>>
>>
>> Please spread the word!
>>
>> -Twitter: https://twitter.com/OpenKnowledgeBE/status/1224291464496193538
>> -Facebook: https://www.facebook.com/events/2852981998057886/
>> -Eventbrite: http://equalstreetnamesbrussels.eventbrite.co.uk/
>>
>>
>>
>>
>>
>> Seppe
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] 17/02: Towards Equal Street Names with Open Data

[Jo]

Hi,

I did this for one street in Evere:
https://www.openstreetmap.org/way/523050554/history

Took me more than half an hour for a single street (no automation). I
created a wikidata entry both for the person and for the street itself.
Things are complicated by the bilingual nature of the city and because this
street also had an old name.

Is that what we will be doing? Or did I somehow misunderstand?

Polyglot

On Mon, Feb 3, 2020 at 4:34 PM Santens Seppe 
wrote:

> Hi community,
>
>
>
> Open Knowledge Belgium, OpenStreetMap Belgium and Wikimedia Belgium want
> to map all the streetnames by gender in Brussels, as a first step to change
> the imbalance in reality. We need your help on 17/02 to get the OSM data
> linked to wikidata.
>
> Register here to join the mapping effort:
> https://eventbrite.co.uk/e/towards-equal-street-names-with-open-data-registration-92536026747.
> And let us know if you can help with the framework.
>
>
>
>
>
> more info:
> https://be.okfn.org/2020/02/03/towards-equal-street-names-with-open-data/
>
>
>
> Please spread the word!
>
> -Twitter: https://twitter.com/OpenKnowledgeBE/status/1224291464496193538
> -Facebook: https://www.facebook.com/events/2852981998057886/
> -Eventbrite: http://equalstreetnamesbrussels.eventbrite.co.uk/
>
>
>
>
>
> Seppe
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[rainerU]

Am 04.02.20 um 08:42 schrieb Vincent de Château-Thierry:
Pour les rapprochements je ne tiens pas compte des voies FANTOIR annulées. Dans 
tes 2 cas ce sont des voies ayant été annulées dans FANTOIR. Pour chacune on a 
des rues au nom très proche, c'est peut-être une raison de leur annulation pour 
éviter les confusions :


661363128U RUE LOUIS VISCONTI
661360858B AV GEORGES ET CLAUDE CAUSTIER


Merci. Cela confirme l'utilité de cet outil.


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

Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR

[Jérôme Seigneuret]

Merci Vincent

Bonne journée

Le mar. 4 févr. 2020 à 08:42, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> Le 04/02/2020 à 08:02, rainerU a écrit :
> >
> > J'ai constaté que dans la liste des voies inconnues dans FANTOIR on
> > trouve des rues qui sont bien dans liste brute FANTOIR. Exemples pour la
> > ville de Perpignan 66136 :
> >
> > Rue Luchino Visconti 661365195R
> > Rue Georges Claude 661361048H
>
> Pour les rapprochements je ne tiens pas compte des voies FANTOIR
> annulées. Dans tes 2 cas ce sont des voies ayant été annulées dans
> FANTOIR. Pour chacune on a des rues au nom très proche, c'est peut-être
> une raison de leur annulation pour éviter les confusions :
>
> 661363128U RUE LOUIS VISCONTI
> 661360858B AV GEORGES ET CLAUDE CAUSTIER
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] weeklyOSM #497 2020-01-21-2020-01-27

[Jorge Sanz]

A similar discussion has happened recently when BitTorrent downloads were
announced as an experimental feature (wiki discussion
, twitter
, reddit
,
yc ) and the reception seems
to be pretty good. My understanding is that there's a use case for projects
that don't need to have a permanently updated planet but want to do a full
update in a low pace frequency (say twice per year or so). Helping those
projects to achieve that part using a parallel download through several
mirrors (or BitTorrent) makes sense to me. The increase of bandwidth, and
eventually the need for more mirrors/peers could be considered a
correlation with the increase of adoption of OSM data, right?

Also, this tool is also meant to help to automate the download of data from
other extract sources (geofabrik, openstreetmap fr, bbbike) for smaller
areas, which is also useful in itself for projects aiming at a smaller
geographical context.

On Tue, 4 Feb 2020 at 01:42, Yuri Astrakhan  wrote:

> Andy, I agree that being frugal with bandwidth is important.  Yet, there
> is a significant operations cost involved here, that I suspect very few
> will actually be willing to spend, unless it is made trivial -- the cost of
> setting up an independent planet file update pipeline - i.e. a docker image
> that could be pointed to a planet file, and has an easy way to suspend and
> resume update when the file needs to be static during the loading process.
>
> I think having an optimized download tool that can both download+validate
> planet/areas, and could provide other services like diff updating would
> solve both goals.  If the current process is manually pick a mirror,
> manually validate, and re-download if failed, vs use a dedicated tool that
> will optimize the download and crash recovery, all the better. Especially
> if it offers us a way to add more functionality later, like patch updating.
>
> Also, lets not fall into the premature optimization trap, as that only
> achieves local rather than global maximums.  As a theoretical example -
> what is better - wider OSM adaption with higher number of planet downloads
> (i.e. some wasted bandwidth), or lower adaption and more optimized download
> process?  I would think OSM project would be better off from wider adaption
> at a cost of a 10-50% extra bandwidth, right?  If the startup cost (human
> hours) is lower, more people would participate.  My numbers could be
> totally off, but keeping the eyes on bigger picture is very important when
> deciding such matters.  Convenience/low manual labor cost is a big
> contributor to wider adaption.
>
> P.S. Am I correct to assume that every data consumer would need to
> download each diff file twice -- once for planet file update, and once to
> update the PostgreSQL database?
>
>
> On Sun, Feb 2, 2020 at 4:17 PM Andy Townsend  wrote:
>
>> ... that's why I said "... and there are ways of keeping a *.pbf* up to
>> date" in my message. - the idea is to avoid large downloads wherever
>> possible (emphasis new in this message; won't make it to plain text
>> archive).
>>
> Andy,
>
>
>> For more info see:
>>
>> https://docs.osmcode.org/pyosmium/latest/tools_uptodate.html
>>
>> or if that's somehow not an option:
>>
>>
>> https://wiki.openstreetmap.org/wiki/User:EdLoach#Osmosis_to_keep_a_local_copy_of_a_.osm_file_updated
>>
>> (from a few years back)
>>
>> * Automation / easy adaptation.  Providing an out-of-the box way to set
>> up your own server is much easier if you have a tool that automatically
>> downloads and validates the planet file or a portion of it,
>>
>> Sure - an automated process is much easier to follow than a manual
>> do-it-yourself one, but the fact that a process is automated doesn't mean
>> that it has to be wasteful.  Ultimately, someone's paying for the bandwidth
>> that downloads from each of the mirrors at
>> https://wiki.openstreetmap.org/wiki/Planet.osm#Planet.osm_mirrors use,
>> so it seems only fair to not be profligate with it.
>>
>> Best Regards,
>>
>> Andy
>>
>>
>>
>> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>


-- 
Jorge Sanz
http://twitter.com/xurxosanz
http://jorgesanz.net
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-gb-westmidlands] Mappa Mercia this Thursday

[Ian Caldwell via Talk-gb-westmidlands]

I hope to be there.

Ian


On Sun, 2 Feb 2020 at 18:14, Brian Prangle  wrote:

> Good for me - I'll be there
>
> On Sun, 2 Feb 2020 at 13:12, Rob Nickerson 
> wrote:
>
>> Hi all,
>>
>> By my calendar it is the next meetup this coming Thursday. I am assuming
>> central Birmingham, likely at The Bull...?
>>
>> *Rob*
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [talk-au] traffic_calming=choker and table

[Sebastian S.]

Hallo, 
I saw that you update the wiki with the link.
Before I sign up to that website to download that pdf... Are there images that 
show this?
I read the text but am lacking the imagination...

Are other traffic_calming options mentioned and missing in the wiki?

On 4 February 2020 4:20:16 pm AEDT, Alex Sims  wrote:
>Hi,
>
>I obviously hang around with the wrong type of people, council people,
>traffic engineers, community groups etc. It’s a commonly used term,
>particularly in Local Government. To quote Austroads guide to Local
>Area Traffic Management,
>https://austroads.com.au/publications/traffic-management/agtm08/selection-of-latm-devices/horizontal-deflection-devices/driveway-links
>(free but registration required)
>
>“Description of driveway links
>
>Driveway links take the form of a single‑lane two-way meandering road
>extending over the length of two or more property frontages. They are
>an extended form of a slow point that generally provides a greater
>visual and physical impact on the street and the amount of traffic
>using it. Passing points may be required along the link if it is either
>very long or it is curved such that approaching drivers cannot see to
>the far end. Driveway links are particularly effective in reducing
>through traffic. Consideration needs to be given to maintaining
>drainage paths and providing bypasses for bicycles where possible”.
>
>A chicane is something you’ll find on a racetrack, best not to get them
>confused.
>
>Alex
>
>
>From: Warin <61sundow...@gmail.com>
>Date: Tuesday, 4 February 2020 at 1:34 pm
>To: "talk-au@openstreetmap.org" 
>Subject: Re: [talk-au] traffic_calming=choker and table
>
>On 4/2/20 8:23 am, Graeme Fitzpatrick wrote:
>Yep, choked_table sounds good.
>
>From that wiki page, though, I notice that a chicane is "Called a
>driveway link in Australia"? Maybe so, but for 40+ years of driving in
>Australia, I've only ever known them as chicanes!
>
>
>
>Who calls a chicane a "driveway link'??? Not I.
>
>
>
>Arr Alex Sims in South Australia added it .. message sent.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-se] Hosting my own Hydda tileset

[Thibaut Estublier via Talk-se]

Hello,

I'm the main developer of a website hosted in France, using a map with 
Openstreetmap + Leaflet.


Actually, our map tiles are all provided by external servers. We're 
mainly using the Hydda Tileset you provide.


We've been gradually growing, and would now like to host our own tile 
server. We'd like to be able to maintain our own infrastructure, and 
also host it in France to provide a faster browsing experience to our 
customers.


Furthermore, if our user base goes up, I don't want to saturate 
someone's server bandwith or impact everyone's usage. I guess hosting my 
own tileset is the way to go.



Is the Hydda tileset available to download? Does the license authorize 
such a use of your tileset?



Thanks in advance,


- Thibaut


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

[talk-cz] WeeklyOSM CZ 496

[Tom Ka]

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

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

* Tutoriál pro JOSM?
* Vlastní mapy na freemap.sk.
* Nepoužívané budovy v JOSM.
* Vrstva Mapillary pro iD.
* Google SoC 2020.
* SWOT analýza OSM.
* Problematická jména v Nepálu.
* Stipendia pro SotM v JARu.
* Mapa ulic města.
* Testování webu osm.org.
* Oblíbené výzvy MapRoulette.
* Bobří rybník.
* Mapy TomTom pro Huawei.
* Jak deformuje Mercator?

Pěkné počtení ...

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