[Talk-at] Pro Revert von Massenedits (Öffnungszeiten Massenedit)

[thomas hulka]

wer ein grosses umfassendes changeset eincheckt, riskiert den revert des 
gesamten checkins wenn auch nur eine kleine kleinigkeit falsch ist. es gibt 
keinen grund hier die vernichtung von viel arbeit zu sehen. denn massenedits 
werden wohl immer automatisiert, programmatisch erstellt. es sollten dann eben 
möglichst kleine changesets eingecheckt werden, um reverts feingranular 
durchführen zu können.

einen massenedit wegen kleiner fehler rückgängig zu machen ist daher kein 
problem
1. hätte mapper kleine changesets machen sollen
2. kann mapper das changeset nach dem revert ohne grossen aufwand neu erstellen 
und ohne die problematischen änderungen nochmals eintüten.

snupo


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


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

[Talk-us] MO Stare Road Classifications.

[idnwys]

I was thinking of using MODOT Functional classification maps to set roads to.  
Basically the following:

MODOT : OSM

Interstate : motorway
Freeway and Expressway : trunk
Other Principal Arterial : primary
Minor Arterial : secondary
Major Collector : tertiary
Minor Collector : unclassified
Local : residential

You can see maps here:
http://www.modot.org/newsandinfo../functionalclassificationmaps

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

[OSM-talk] MapRoulette down, disk full

[Martijn van Exel]

Hi, 

The MapRoulette server’s disk ran out of space. 

Please accept my apologies for the downtime while I work to get it back up.

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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[Alecs]

In Lombardia mi sembrano abbastanza aggiornate, dovrebbe essere 2015,
senz'altro meno nitide delle precedenti e abbastanza disallineate, da
verificare meglio. Ci sono delle "isole" di qualità e allineamento molto
migliori nelle città maggiori, come lo erano già da qualche tempo, almeno ho
visto Milano, Firenze e Roma.

Alessandro



--
View this message in context: 
http://gis.19327.n8.nabble.com/Nuove-Immagini-Satellitari-Bing-tp5892404p5892421.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[carlo folini]

Ciao,
Anche in Valtellina le foto NON sono state aggiornate e sono spostate di un
paio di metri.

Il 04 mar 2017 7:03 PM, "Damjan Gerl"  ha scritto:

> 04.03.2017 - 18:30 - scratera:
>
>> ...pure in trentino sono una cosa inguardabile...
>>
>
> In fvg - provincia di Trieste le foto sono marzo 2016 :-) e sono spostate
> di 3 metri e mezzo in confronto con le mapbox e pcn. Sono quindi aggiornate
> ma le vecchie erano multo più contrastate e quindi erano visibili molti più
> dettagli specialmente nei boschi (anche se c'erano più ombre)...
>
> Sapete se mapbox si aggiornerà anche e possiamo tenerlo come alternativa?
> Per dir la verità io usavo sempre mapbox perché erano un po' meglio
> allineate che bing.
>
> Damjan
>
> ___
> 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-be] Where has Brussels UrbIS 2015 aerial imagery gone?

[Jonathan Beliën]

And I also submitted PULL REQUEST to update iD Editor baselayers : 
https://github.com/osmlab/editor-layer-index/pulls/jbelien


Just have to wait that those pull requests are "accepted".


Jonathan


Le 04-03-17 à 18:32, Jonathan Beliën a écrit :
I fixed every URL's for UrbIS (aerial + basemap) and added 2016 aerial 
imagery for JOSM settings : 
https://josm.openstreetmap.de/wiki/Maps/Belgium



Jonathan


Le 03-03-17 à 14:06, Jonathan Beliën a écrit :

You're welcome ! :)

And indeed Ortho2016 is available :

wms:http://geoservices-urbis.irisnet.be/geoserver/ows/?SERVICE=WMS=1.3.0=GetMap=image%2Fpng=true=Urbis%3AOrtho2016={width}={height}=EPSG%3A3857=={bbox} 



Excellent idea to update 
https://github.com/osmlab/editor-layer-index/tree/gh-pages/sources/europe/be
It will be really useful because the quality of CIRB orthophotos is 
better than the one from AGIV (for Brussels only of course ^^). So I 
would set "best=true" for the Brussels area.

If you need any hlep with this, feel free to ask :)
Thanks !

Jonathan Beliën
GEO-6

-Message d'origine-
De : Yves bxl-forever [mailto:bxl-fore...@linuxmail.org]
Envoyé : vendredi 3 mars 2017 13:46
À : talk-be@openstreetmap.org
Objet : Re: [OSM-talk-be] Where has Brussels UrbIS 2015 aerial 
imagery gone?


Thanks a lot for this.  Indeed, not only does this URL work but 2016 
aerial views are now available too.
I am also following Joost’s suggestion and am preparing a GeoJSON 
file to upload onto the list of Belgian imagery (set as "best=false" 
to avoid clashing with other layers).


Cheers.
Yves


On Wed, 1 Mar 2017 14:09:26 +0100
Jonathan Beliën  wrote:


Hi Yves,

If I remember correctly, I think you use the old URL.

The new URL should be :

wms:http://geoservices-urbis.irisnet.be/geoserver/ows/?SERVICE=WMS=1.3.0=GetMap=image%2Fpng=true=Urbis%3AOrtho2015={width}={height}=EPSG%3A3857=={bbox} 



:)

Jonathan Beliën

-Message d'origine-
De : Yves bxl-forever [mailto:bxl-fore...@linuxmail.org]
Envoyé : mercredi 1 mars 2017 13:48
À : talk-be@openstreetmap.org
Objet : [OSM-talk-be] Where has Brussels UrbIS 2015 aerial imagery 
gone?


Hello,

The most recent set of aerial imagery for Brussels comes from 
low-altitude flights commissioned by the Region.
Very useful to map public space in Brussels and it integrates 
perfectly in JOSM.
The layer with images taken during Spring 2015 used to be available 
here: 
wms:http://www.gis.irisnet.be/arcgis/rest/services/basemap/ortho2015/MapServer/export?f=image=jpeg=False={proj}=3857=3857={bbox}={width},{height}


It’s been a few days where this data seems to have been removed from 
their server.

Apparently, only the 2004 and 2012 aerial views are still available.
http://www.gis.irisnet.be/arcgis/rest/services/basemap

Does anyone know of an alternative location to get this data?
I wrote to CIRB-CIBG, the Brussels institute in charge of this, but 
no reply so far.



Cheers.
Yves

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


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

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


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



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



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

[Talk-es] Resolución portal transparencia

[Santiago Crespo]

Hola,

Hice una solicitud a la Presidencia del Gobierno preguntando si podemos
usar los datos publicados en el portal de transparencia para mejorar OSM
y esta es la respuesta de la Directora General de Gobernanza Pública:

https://osm.org/wiki/File:RESOLUCION_11044.pdf

La modalidad que aplican es la descrita en el apartado "a)" del artículo
4, punto 2:

"a) Reutilización de documentos puestos a disposición del público sin
sujeción a condiciones."

Podían haber optado por otra modalidad más restrictiva, como la "b)"

"b) Reutilización de documentos puestos a disposición del público con
sujeción a condiciones establecidas en licencias-tipo."

La ley en cuestión:

https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-7731

El pdf está censurado por privacidad, pero como pongo en la descripción
en la wiki: si cualquier miembro del equipo legal o del consejo de la
OSMF quiere verificar el documento puedo enviarles el pdf original con
el código de verificación para validarlo en un sitio web del gobierno.

Saludos,
Santiago Crespo

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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[Damjan Gerl]

04.03.2017 - 18:30 - scratera:

...pure in trentino sono una cosa inguardabile...


In fvg - provincia di Trieste le foto sono marzo 2016 :-) e sono 
spostate di 3 metri e mezzo in confronto con le mapbox e pcn. Sono 
quindi aggiornate ma le vecchie erano multo più contrastate e quindi 
erano visibili molti più dettagli specialmente nei boschi (anche se 
c'erano più ombre)...


Sapete se mapbox si aggiornerà anche e possiamo tenerlo come 
alternativa? Per dir la verità io usavo sempre mapbox perché erano un 
po' meglio allineate che bing.


Damjan

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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[girarsi_liste]

Il 04/03/2017 18:30, scratera ha scritto:
> ...pure in trentino sono una cosa inguardabile...
> 


Perchè io da dove scrivevo.. O_o


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [OSM-talk-be] Where has Brussels UrbIS 2015 aerial imagery gone?

[Jonathan Beliën]

I fixed every URL's for UrbIS (aerial + basemap) and added 2016 aerial 
imagery for JOSM settings : https://josm.openstreetmap.de/wiki/Maps/Belgium



Jonathan


Le 03-03-17 à 14:06, Jonathan Beliën a écrit :

You're welcome ! :)

And indeed Ortho2016 is available :

wms:http://geoservices-urbis.irisnet.be/geoserver/ows/?SERVICE=WMS=1.3.0=GetMap=image%2Fpng=true=Urbis%3AOrtho2016={width}={height}=EPSG%3A3857=={bbox}

Excellent idea to update 
https://github.com/osmlab/editor-layer-index/tree/gh-pages/sources/europe/be
It will be really useful because the quality of CIRB orthophotos is better than the one 
from AGIV (for Brussels only of course ^^). So I would set "best=true" for the 
Brussels area.
If you need any hlep with this, feel free to ask :)
Thanks !

Jonathan Beliën
GEO-6

-Message d'origine-
De : Yves bxl-forever [mailto:bxl-fore...@linuxmail.org]
Envoyé : vendredi 3 mars 2017 13:46
À : talk-be@openstreetmap.org
Objet : Re: [OSM-talk-be] Where has Brussels UrbIS 2015 aerial imagery gone?

Thanks a lot for this.  Indeed, not only does this URL work but 2016 aerial 
views are now available too.
I am also following Joost’s suggestion and am preparing a GeoJSON file to upload onto the 
list of Belgian imagery (set as "best=false" to avoid clashing with other 
layers).

Cheers.
Yves


On Wed, 1 Mar 2017 14:09:26 +0100
Jonathan Beliën  wrote:


Hi Yves,

If I remember correctly, I think you use the old URL.

The new URL should be :

wms:http://geoservices-urbis.irisnet.be/geoserver/ows/?SERVICE=WMS=1.3.0=GetMap=image%2Fpng=true=Urbis%3AOrtho2015={width}={height}=EPSG%3A3857=={bbox}

:)

Jonathan Beliën

-Message d'origine-
De : Yves bxl-forever [mailto:bxl-fore...@linuxmail.org]
Envoyé : mercredi 1 mars 2017 13:48
À : talk-be@openstreetmap.org
Objet : [OSM-talk-be] Where has Brussels UrbIS 2015 aerial imagery gone?

Hello,

The most recent set of aerial imagery for Brussels comes from low-altitude 
flights commissioned by the Region.
Very useful to map public space in Brussels and it integrates perfectly in JOSM.
The layer with images taken during Spring 2015 used to be available here: 
wms:http://www.gis.irisnet.be/arcgis/rest/services/basemap/ortho2015/MapServer/export?f=image=jpeg=False={proj}=3857=3857={bbox}={width},{height}

It’s been a few days where this data seems to have been removed from their 
server.
Apparently, only the 2004 and 2012 aerial views are still available.
http://www.gis.irisnet.be/arcgis/rest/services/basemap

Does anyone know of an alternative location to get this data?
I wrote to CIRB-CIBG, the Brussels institute in charge of this, but no reply so 
far.


Cheers.
Yves

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


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

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


___
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: [Talk-it] Nuove Immagini Satellitari Bing

[scratera]

...pure in trentino sono una cosa inguardabile...



--
View this message in context: 
http://gis.19327.n8.nabble.com/Nuove-Immagini-Satellitari-Bing-tp5892404p5892416.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Allevamento galline ovaiole

[girarsi_liste]

Il 04/03/2017 17:15, Alberto ha scritto:
> Secondo il wiki, farmland [1] si può usare anche dove pascolano gli animali, 
> mentre meadow [2] si usa per indicare che c'è erba, l'uso a pascolo si può 
> dedurre da meadow=agricultural, che però si usa anche quando l'erba viene 
> tagliata per farne foraggio.
> Probabilmente farmland è più adatto per terreni adibiti sempre a pascolo, 
> meadow per terreni utilizzati come pascolo occasionalmente oppure dove l'erba 
> viene tagliata per foraggio.
> Però ammetto che c'è sovrapposizione dei tag e non è buono.
> Chi ha voglia di cominciare a mettere giù qualche pagina da guida sui tag 
> agricoli, così poi da discuterne in tagging? :-)
> Io purtroppo in questo periodo non riesco.
> 
> Alberto
> 
> 
> [1] http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarmland
> [2] http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dmeadow
> 

Purtroppo con l'inglese vado male.

Ragionando sulle due pagine, farmland è per foraggio o pascolo, purchè
terreno coltivato, mentre meadow su terreno con foraggio o altro di tipo
spontaneo.

Per le galline,ragionando sull'esempio della foto riportata nel landuse
=farmland direi che ci sta un farmyard, perchè le galline da allevamento
di solito sono circoscritte in un recinto accanto un edificio che funge
da riparo e raccolta uova ecc..

Farmland e meadow le vedo più una cosa "libera", vale nel caso di
galline lasciate in libertà, lontane dall'edificio, no n circoscritto ad
esso.


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [OSM-talk-be] Fwd: [iRail] Job positions in open data not being filled in

[Jo]

Java is also not my cup of tea

On Mar 4, 2017 5:31 PM, "Karel Adams"  wrote:

> Ik heb recentelijks bij IMEC gesolliciteerd (weliswaar niet in een
> opendata-context) en - beleefd blijvend - was de ontvangst daar niet van
> zo'n aard dat ik in dat bedrijf verder nog interesse heb.
>
> MIVB heeft mij bedankt, droogweg maar wel correct.
>
> Meer algemeen: het lijkt me dat kandidaat-werkgevers de lat erg hoog
> leggen, dezer dagen. Dan moeten ze niet klagen hé, dat ze geen geschikte
> kandidaten vinden.
>
> Karel
>
> On 04/03/17 11:03, Ben Abelshausen wrote:
>
> Hi,
>
> Anyone here who can help Pieter?
>
> Cheers,
>
> Ben
>
> -- Forwarded message --
> From: Pieter Colpaert 
> Date: Sat, Mar 4, 2017 at 12:00 PM
> Subject: [iRail] Job positions in open data not being filled in
> To: iRail list 
>
>
> Hi all,
>
> I have 2 open positions at imec to work on open data:
>  * https://www.iminds.be/en/about-us/jobs/jobs-overview/open-da
> ta-researcher-smart-flanders
>  * https://www.iminds.be/en/about-us/jobs/jobs-overview/vacancy
> -for-big-andtransport-data-projects
>
> I also see that MIVB-STIB has an open position to work on the Open Data
> Platform:
>  * https://www.linkedin.com/jobs/view/257410408/
>
> It’s currently very hard to find people willing to work on Open Data
> publishing for a living. Any ideas how to find the right people? Is there
> anyone in your network that might be trained to work on Open Data?
>
> Kind regards,
>
> Pieter
> ___
> iRail mailing list
> ir...@list.irail.be
> https://lists.okfn.org/mailman/listinfo/irail
>
>
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Fwd: [iRail] Job positions in open data not being filled in

[Karel Adams]

Ik heb recentelijks bij IMEC gesolliciteerd (weliswaar niet in een 
opendata-context) en - beleefd blijvend - was de ontvangst daar niet van 
zo'n aard dat ik in dat bedrijf verder nog interesse heb.


MIVB heeft mij bedankt, droogweg maar wel correct.

Meer algemeen: het lijkt me dat kandidaat-werkgevers de lat erg hoog 
leggen, dezer dagen. Dan moeten ze niet klagen hé, dat ze geen geschikte 
kandidaten vinden.


Karel


On 04/03/17 11:03, Ben Abelshausen wrote:

Hi,

Anyone here who can help Pieter?

Cheers,

Ben

-- Forwarded message --
From: *Pieter Colpaert* >
Date: Sat, Mar 4, 2017 at 12:00 PM
Subject: [iRail] Job positions in open data not being filled in
To: iRail list >


Hi all,

I have 2 open positions at imec to work on open data:
 * 
https://www.iminds.be/en/about-us/jobs/jobs-overview/open-data-researcher-smart-flanders 

 * 
https://www.iminds.be/en/about-us/jobs/jobs-overview/vacancy-for-big-andtransport-data-projects 



I also see that MIVB-STIB has an open position to work on the Open 
Data Platform:
 * https://www.linkedin.com/jobs/view/257410408/ 



It’s currently very hard to find people willing to work on Open Data 
publishing for a living. Any ideas how to find the right people? Is 
there anyone in your network that might be trained to work on Open Data?


Kind regards,

Pieter
___
iRail mailing list
ir...@list.irail.be 
https://lists.okfn.org/mailman/listinfo/irail 





___
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: [Talk-it] Allevamento galline ovaiole

[Alberto]

>strano...ho sempre usato landuse=meadow per i terreni dove si lasciano 
>pascolare/crescere/riprodurre animalifarmland l'ho usato solo >per i 
>terreni coltivati...
>quindi ho taggato sbagliato fino ad ora?

Secondo il wiki, farmland [1] si può usare anche dove pascolano gli animali, 
mentre meadow [2] si usa per indicare che c'è erba, l'uso a pascolo si può 
dedurre da meadow=agricultural, che però si usa anche quando l'erba viene 
tagliata per farne foraggio.
Probabilmente farmland è più adatto per terreni adibiti sempre a pascolo, 
meadow per terreni utilizzati come pascolo occasionalmente oppure dove l'erba 
viene tagliata per foraggio.
Però ammetto che c'è sovrapposizione dei tag e non è buono.
Chi ha voglia di cominciare a mettere giù qualche pagina da guida sui tag 
agricoli, così poi da discuterne in tagging? :-)
Io purtroppo in questo periodo non riesco.

Alberto


[1] http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarmland
[2] http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dmeadow


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [OSM-talk] Fixing broken multipolygons

[Jochen Topf]

On Sat, Mar 04, 2017 at 11:03:26AM +, molto...@gmail.com wrote:
> You should also look out for MPs with tags on the outer ring but
> should actually only be on the realtion. Having the same tags on inner
> and outer is a nice heuristic that QA tools detect, but is not the
> only way that old-style polygons (which AFAIU wont be supported by
> osm2pgsql at some stage) can happen.

I do.

https://github.com/osmlab/fixing-polygons-in-osm/blob/master/doc/problems.md#old-style-tagging
http://area.jochentopf.com/stats/#old_style_multipolygons

Same tags on inner and outer is just a subset of the old-style polygons.

Currently I am concentrating on actually broken polygons, the old-style
polygons are next and I will create challenges for them, too.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [OSM-talk] Fixing broken multipolygons

[Jochen Topf]

On Sat, Mar 04, 2017 at 10:50:41AM +0100, Martin Koppenhoefer wrote:
> > On 4 Mar 2017, at 08:49, Jochen Topf  wrote:
> > 
> > Looking at the graphs on http://area.jochentopf.com/stats you can see
> > that the number of (multi)polygons is growing steadily, while the number
> > of errors has been more or less flat over the last half year.
> 
> 
> nice stats and good results.
> I want to point out though that "
> Errors: Inner rings with same tags as outer rings"
> 
> are not necessarily errors, and should not be "fixed" unless you know
> very well the situation and can tell that there's indeed a
> redundancy/data problem. E.g. you can have a building or building:part
> inside another building or building:part. These could be tagged still
> "incompletely" hence having just the same tags for the moment but be
> different objects nonetheless. Similarly woods inside woods, etc.

"Inner rings with same tags as outer rings" is a subset of old-style
multipolygons. Well, as you correctly point out, some of them might be
okay, but most of them are especially "bad" cases of old-style
multipolygons. And they are another good reason why we need to get rid
of old-style multipolygons. There is just no way to figure out
automatically, what's right here and what's not. So humans have to fix
those. I'll create Maproulette challenges for these too at some point.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[Federico Cortese]

Sono corso a vedere le foto "nuove" nella mia zona ma sono identiche
alle vecchie come data (2009-2013) ma più sfocate e molto più shiftate
(almeno 6 metri di sfasamento).
Ora prevedo che gli utenti id cominceranno a spostare tutte le strade
e i fabbricati
La cosa è grave :-(

Ciao,
Federico

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

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[James]

If every license was perfect, we wouldnt need lawyers...

On Mar 4, 2017 10:03 AM, "Stewart C. Russell"  wrote:

> On 2017-03-04 09:09 AM, James wrote:
> > As the LWG said, it's not a blanket acceptance of all OGL variants, but
> > if future licenses we come across are exactly the same(kdiff of text or
> > something as proof) except the city/entity name. We will have a strong
> > case that it is compatible with ODbL.
>
> Yes, it would definitely help to show that the text of a new licence is
> only trivially different from an accepted one. We'd still need to run it
> past the LWG, though. Any new licence creates new obligations for the
> Foundation. Sometimes these new obligations are trivial, but they need
> to be recognized.
>
> > So if future cities are looking to change their license they can use
> > Ottawa license as an example so they are sure it's compatible
>
> Ottawa's licence isn't exactly a shining example. It was good they
> changed their licence from a grievously incompatible one after you
> contacted them about it.
>
> Annoyances with the Ottawa licence include:
>
> * it still includes the third party rights exemption that was brought
>   over from the UK licence. I don't see any way that this will go away
>   for existing data.
>
> * it doesn't have the statement on compatibility that the UK OGL
>   licence includes. This would definitely ease adoption.
>
> cheers,
>  Stewart
>
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-es] Bienes de Interés Cultural en España

[Javier Sánchez Portero]

Muy buena aportación.

El 4 de marzo de 2017, 10:24, dcapillae  escribió:

> Saludos,
>
> He documentado la  etiqueta para referenciar Bienes de Interés Cultural en
> España   . Agradecería
> cualquier aportación al wiki que sirviese para corregir o completar la
> documentación sobre convenciones de etiquetado de Bienes de Interés
> Cultural
> en España.
>
> En el wiki existe una página dedicada a los  Bienes de Interés Cultural en
> Canarias
>  C3%A9s_Cultural_en_Canarias>
> , también en  Córdoba
>  C3%A9s_Cultural_de_C%C3%B3rdoba>
> y  Granada
>  C3%A9s_Cultural_de_Granada>
> , muy interesantes ambas para informarse sobre cómo se etiquetan estos
> bienes. Personalmente he empezado a mapear los  Bienes de Interés Cultural
> en Málaga
>  A1laga=1431545#Patrimonio_hist.C3.B3rico_y_cultural>
> .
>
> En el foro existe ya un hilo relacionado con el asunto de los BIC, aunque
> centrado en el  Proyecto BICs de Canarias
> 
> .
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/Bienes-de-Interes-Cultural-en-Espa-a-tp5892400.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[Stewart C. Russell]

On 2017-03-04 09:09 AM, James wrote:
> As the LWG said, it's not a blanket acceptance of all OGL variants, but
> if future licenses we come across are exactly the same(kdiff of text or
> something as proof) except the city/entity name. We will have a strong
> case that it is compatible with ODbL.

Yes, it would definitely help to show that the text of a new licence is
only trivially different from an accepted one. We'd still need to run it
past the LWG, though. Any new licence creates new obligations for the
Foundation. Sometimes these new obligations are trivial, but they need
to be recognized.

> So if future cities are looking to change their license they can use
> Ottawa license as an example so they are sure it's compatible

Ottawa's licence isn't exactly a shining example. It was good they
changed their licence from a grievously incompatible one after you
contacted them about it.

Annoyances with the Ottawa licence include:

* it still includes the third party rights exemption that was brought
  over from the UK licence. I don't see any way that this will go away
  for existing data.

* it doesn't have the statement on compatibility that the UK OGL
  licence includes. This would definitely ease adoption.

cheers,
 Stewart




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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[girarsi_liste]

Il 04/03/2017 15:50, Marco ha scritto:
> Se a qualcuno interessa, qua si vede la data delle immagini
> 
> http://mvexel.dev.openstreetmap.org/bing/
> 
> 

Infatti, la zona che io ho guardato è maggio 2010 - settembre 2015,
esattamente come riferito dalle prorietà del layer su Josm.

Volevo vedere se c'era un iccolo tratto di strada nuovo, dell'anno
scorso, ma non c'è, rimangono le stesse foto per quanto riguarda la mia
zona.

-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[James]

Weird there was the same thing yesterday in Ottawa with open.canada.ca

On Mar 4, 2017 9:39 AM, "Stewart C. Russell"  wrote:

> On 2017-03-04 08:20 AM, Bjenk Ellefsen wrote:
> >
> > We can follow the same steps and workflow in the future if we
> potentially move to another city.
> > This is also something municipalities can use in defining their open
> data licenses.
>
> Yup - for that reason, I will be asking the LWG about the licences for
> Ontario, Toronto and Toronto Public library (yup, all different).
>
> For the record:
>
>  1) LWG's decision on Ottawa doesn't immediately open up all Canadian
> open data to be imported into OSM. The LWG, for now at least, plans
> to review them on a case by case base.
>
>  2) If you're wishing to get a new licence approved, the timeline from
> approaching the LWG to getting approval was about two months.
> Please build that delay into any critical path
>
> And belated happy Open Data Day! The reason I was late posting this (LWG
> gave me access to the draft minutes mid-afternoon) that I was in an
> all-day session with Government of Ontario open data people in Toronto.
> Government of Ontario has some very committed open data people.
>
> cheers,
>  Stewart
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] Nuove Immagini Satellitari Bing

[Marco]

Se a qualcuno interessa, qua si vede la data delle immagini

http://mvexel.dev.openstreetmap.org/bing/


Il 04/03/2017 15:15, dan980 ha scritto:

Da ieri (03.03.2017) le immagini satellitari di Bing sono state aggiornate
per l'Italia. Sono molto recenti (2016?).
In Josm potete fare il confronto utilizzando il layer di Bing e quello di
Mapbox Satellite (che ha ancora le vecchie immagini del 2011). Nelle zone di
espansione residenziale è possibile apprezzare i nuovi edifici.



-
--
confronto navigatori basati su OSM:
https://docs.google.com/spreadsheets/d/1xmhQ15bQ5eH_8U7kCzwi5xoNtT8e8JxDUEz05px-Vog/pubhtml

--
View this message in context: 
http://gis.19327.n8.nabble.com/Nuove-Immagini-Satellitari-Bing-tp5892404.html
Sent from the Italy General mailing list archive at Nabble.com.

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



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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[girarsi_liste]

Il 04/03/2017 15:15, dan980 ha scritto:
> Da ieri (03.03.2017) le immagini satellitari di Bing sono state aggiornate
> per l'Italia. Sono molto recenti (2016?).
> In Josm potete fare il confronto utilizzando il layer di Bing e quello di
> Mapbox Satellite (che ha ancora le vecchie immagini del 2011). Nelle zone di
> espansione residenziale è possibile apprezzare i nuovi edifici.
> 
> 

Nella mia zona sono ancora quelle vecchie.


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[Stewart C. Russell]

On 2017-03-04 08:20 AM, Bjenk Ellefsen wrote:
> 
> We can follow the same steps and workflow in the future if we potentially 
> move to another city.
> This is also something municipalities can use in defining their open data 
> licenses. 

Yup - for that reason, I will be asking the LWG about the licences for
Ontario, Toronto and Toronto Public library (yup, all different).

For the record:

 1) LWG's decision on Ottawa doesn't immediately open up all Canadian
open data to be imported into OSM. The LWG, for now at least, plans
to review them on a case by case base.

 2) If you're wishing to get a new licence approved, the timeline from
approaching the LWG to getting approval was about two months.
Please build that delay into any critical path

And belated happy Open Data Day! The reason I was late posting this (LWG
gave me access to the draft minutes mid-afternoon) that I was in an
all-day session with Government of Ontario open data people in Toronto.
Government of Ontario has some very committed open data people.

cheers,
 Stewart


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

Re: [Talk-it] Nuove Immagini Satellitari Bing

[Francesco Pelullo]

Anni di cache da gettare via...
:-)

Ciao
/niubii/


Il 04 mar 2017 15:16, "dan980"  ha scritto:

> Da ieri (03.03.2017) le immagini satellitari di Bing sono state aggiornate
> per l'Italia. Sono molto recenti (2016?).
> In Josm potete fare il confronto utilizzando il layer di Bing e quello di
> Mapbox Satellite (che ha ancora le vecchie immagini del 2011). Nelle zone
> di
> espansione residenziale è possibile apprezzare i nuovi edifici.
>
>
>
> -
> --
> confronto navigatori basati su OSM:
> https://docs.google.com/spreadsheets/d/1xmhQ15bQ5eH_
> 8U7kCzwi5xoNtT8e8JxDUEz05px-Vog/pubhtml
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/Nuove-Immagini-Satellitari-Bing-tp5892404.html
> Sent from the Italy General mailing list archive at Nabble.com.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nuove Immagini Satellitari Bing

[Davide Sandona']

nella mia zona erano piu' nitide le precedenti :(

Davide.

Il giorno 4 marzo 2017 15:15, dan980  ha scritto:

> Da ieri (03.03.2017) le immagini satellitari di Bing sono state aggiornate
> per l'Italia. Sono molto recenti (2016?).
> In Josm potete fare il confronto utilizzando il layer di Bing e quello di
> Mapbox Satellite (che ha ancora le vecchie immagini del 2011). Nelle zone
> di
> espansione residenziale è possibile apprezzare i nuovi edifici.
>
>
>
> -
> --
> confronto navigatori basati su OSM:
> https://docs.google.com/spreadsheets/d/1xmhQ15bQ5eH_
> 8U7kCzwi5xoNtT8e8JxDUEz05px-Vog/pubhtml
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/Nuove-Immagini-Satellitari-Bing-tp5892404.html
> Sent from the Italy General mailing list archive at Nabble.com.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Nuove Immagini Satellitari Bing

[dan980]

Da ieri (03.03.2017) le immagini satellitari di Bing sono state aggiornate
per l'Italia. Sono molto recenti (2016?).
In Josm potete fare il confronto utilizzando il layer di Bing e quello di
Mapbox Satellite (che ha ancora le vecchie immagini del 2011). Nelle zone di
espansione residenziale è possibile apprezzare i nuovi edifici.



-
--
confronto navigatori basati su OSM:
https://docs.google.com/spreadsheets/d/1xmhQ15bQ5eH_8U7kCzwi5xoNtT8e8JxDUEz05px-Vog/pubhtml

--
View this message in context: 
http://gis.19327.n8.nabble.com/Nuove-Immagini-Satellitari-Bing-tp5892404.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[James]

As the LWG said, it's not a blanket acceptance of all OGL variants, but if
future licenses we come across are exactly the same(kdiff of text or
something as proof) except the city/entity name. We will have a strong case
that it is compatible with ODbL. The problem lies when cities decide to add
lines/restrictions that can make it non-open.

So if future cities are looking to change their license they can use Ottawa
license as an example so they are sure it's compatible

On Mar 4, 2017 8:50 AM, "john whelan"  wrote:

> I assume then this means that other municipalities that use the municipal
> 2.0 version of the Treasury Board Open Data License can now have their bus
> stops imported if the local mappers wish to do so?
>
> Thanks John
>
> On 3 March 2017 at 21:15, Stewart C. Russell  wrote:
>
>> I just got access to the OSMF LWG draft minutes from yesterday, and I
>> have good news: Ottawa ODL 2.0 data *can* be included in the OSM
>> database.
>>
>> The minutes link - https://docs.google.com/docume
>> nt/d/1KyTLbQWSmo1rdoppqlFGTB3by-qVAzjLo_LPml3Ri9Y/edit - is still draft
>> so may not be generally readable, so I've included the text in full below:
>>
>> *5. Statement on Ottawa Open Data Licence Version 2.0 compatibility*
>>
>> Approval of the following statement:
>>
>> ---
>>
>> The LWG has been asked to determine the compatibility of Ottawa Open
>> Data, Licence Version 2.0 (Ottawa ODL 2.0) with the ODbL 2.0 in conjunction
>> with importing so licensed data. The text of the Ottawa ODL 2.0 can be
>> found here
>> 
>> *http://ottawa.ca/en/city-hall/get-know-your-city/open-data#open-data-licence-version-2-0*
>> 
>>
>> The Ottawa ODL 2.0 is a localised version of the OGL Canada
>> 
>> *http://open.canada.ca/en/open-government-licence-canada*
>>  which in turn
>> is loosly based on the UK OGL. The changes relative to the OGL Canada due
>> to localisation are the licensor (the City of Ottawa) and reference to the
>> definition of "personal information" as defined in the "Ontario Municipal
>> Freedom of Information and Protection of Privacy Act",
>>
>> The LWG has determined
>>
>>-
>>
>>that the attribution requirements of the Ottawa ODL 2.0 can be met by
>>adding the required text to the wiki contributor page and corresponding
>>changeset source attribute values, and that there is no downstream
>>attribution requirement,
>>-
>>
>>that we are not using "Personal Information" as defined in the
>>licence and referenced legislation,
>>
>> and that so licensed material can be included in the OpenStreetMap
>> dataset and distributed on ODbL 1.0 terms.
>>
>> In the past the local variants of the OGL Canada have varied widely and
>> have in some cases included additional terms that have made them
>> incompatible with the ODbL and in some instances non-open. For this reason
>> we are not making a blanket statement on other such localised versions of
>> the OGL at this point in time and will continue to review them on a case by
>> case base.
>>
>> ---
>>
>> Approved with 4 yes, 1 abstain.
>>
>>
>> I've also updated the wiki page.
>>
>> Have a great weekend!
>>  Stewart
>>
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[john whelan]

I assume then this means that other municipalities that use the municipal
2.0 version of the Treasury Board Open Data License can now have their bus
stops imported if the local mappers wish to do so?

Thanks John

On 3 March 2017 at 21:15, Stewart C. Russell  wrote:

> I just got access to the OSMF LWG draft minutes from yesterday, and I have
> good news: Ottawa ODL 2.0 data *can* be included in the OSM database.
>
> The minutes link - https://docs.google.com/document/d/
> 1KyTLbQWSmo1rdoppqlFGTB3by-qVAzjLo_LPml3Ri9Y/edit - is still draft so may
> not be generally readable, so I've included the text in full below:
>
> *5. Statement on Ottawa Open Data Licence Version 2.0 compatibility*
>
> Approval of the following statement:
>
> ---
>
> The LWG has been asked to determine the compatibility of Ottawa Open Data,
> Licence Version 2.0 (Ottawa ODL 2.0) with the ODbL 2.0 in conjunction with
> importing so licensed data. The text of the Ottawa ODL 2.0 can be found here
> 
> *http://ottawa.ca/en/city-hall/get-know-your-city/open-data#open-data-licence-version-2-0*
> 
>
> The Ottawa ODL 2.0 is a localised version of the OGL Canada
> 
> *http://open.canada.ca/en/open-government-licence-canada*
>  which in turn
> is loosly based on the UK OGL. The changes relative to the OGL Canada due
> to localisation are the licensor (the City of Ottawa) and reference to the
> definition of "personal information" as defined in the "Ontario Municipal
> Freedom of Information and Protection of Privacy Act",
>
> The LWG has determined
>
>-
>
>that the attribution requirements of the Ottawa ODL 2.0 can be met by
>adding the required text to the wiki contributor page and corresponding
>changeset source attribute values, and that there is no downstream
>attribution requirement,
>-
>
>that we are not using "Personal Information" as defined in the licence
>and referenced legislation,
>
> and that so licensed material can be included in the OpenStreetMap dataset
> and distributed on ODbL 1.0 terms.
>
> In the past the local variants of the OGL Canada have varied widely and
> have in some cases included additional terms that have made them
> incompatible with the ODbL and in some instances non-open. For this reason
> we are not making a blanket statement on other such localised versions of
> the OGL at this point in time and will continue to review them on a case by
> case base.
>
> ---
>
> Approved with 4 yes, 1 abstain.
>
>
> I've also updated the wiki page.
>
> Have a great weekend!
>  Stewart
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing with Statistics Canada (Ottawa ODL 2.0 is go!)

[Bjenk Ellefsen]

This is fantastic news!

Thank you everyone for your help!

We can follow the same steps and workflow in the future if we potentially move 
to another city.
This is also something municipalities can use in defining their open data 
licenses. 

Bjenk Ellefsen
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ko] Fixing laguage-mixed name tag in Korean region

[Robert Helvie]

The ideas here are good, but I have a problem with the idea that the Korean
names "should" be translated.

I have come across numerous examples where a street name COULD be
translated, for example something like "대학로" could be translated to
"University street"; however, the English on the actual street sign is not
translated and says "Daehak-ro".
In a situation like this, shouldn't the name:en tag still exist and be
"Daehak-ro"? In this case, the name:ko_rm=romanized would be the same, but
certainly not in all cases.

There is at least one service I know of that uses the name:en tag to create
maps using OSM data. And, I expect future renderers will need to access
specific language tags when things get to the point where you can choose a
language and have the map rendered on the fly in your language.

If you just start translating all street names and POI names, then anyone
using an English rendered map to find places in Korea is going to have a
pretty hard time unless they speak Korean. Sure, it will obviously take
time to get the actual signage into OSM, but I think that route is better
than just translating things and entering a lot of unrepresentative data.

Robert


*"We should give meaning to life, not wait for life to give us meaning. "*
~ unknown
---

On Sat, Mar 4, 2017 at 8:45 PM, 느림보  wrote:

> It might be useful for foreigners to have combination name as 한국어
> (English). However, as a local mapper I don’t want see (English) because
> they don’t give additional information to Korean people, as well as they
> block displaying of other POIs by taking additional space. To make matters
> worse, English name is longer than original Korean name, generally.
>
>
>
> Andrew said that “…as an English speaker living in Korea it is very useful
> for me…”. So, I looked after several online services and OsmAnd to see how
> they looks. In most cases, they are using local name (name tag) only.
> MapQuest prefer English than local name and OsmAnd has function override
> language, but they don’t give two languages, too.
>
>
>
> I also found two sites displaying two languages (Max already introduced
> one of them.) They display Korean name and ‘foreign name’ line-by-line. For
> me, it is more readable than wrapping English name by parenthesis and looks
> like more proper way handling name tags.
>
> https://www.openstreetmap.de/karte.html?zoom=10=49.
> 99303=18.83157=B000TT
>
> http://maps.sputnik.ru/?lat=37.536410466671626=127.
> 00847625732423=12
>
>
>
>> name=한국어 and name:ko=한국어 are kind of redudnant, but it is probably
>> neccessary to help transitioning. Also it is the same way in Japan.
>>
>
> Agree, I hesitated making duplicated data at the first time but I accepted
> this rule for that reason. It looks like that it is accepted globally. More
> than half of 20 busiest airports have duplicated name tags.
>
>
>
>> ko_rm should actually be renamed in bulk to ko-Latn, possibly in
>> cooperation and discussion with the japanese community who have the same
>> problem with ja_rm that should be ja-Latn
>>
>> See here: https://wiki.openstreetmap.org/wiki/Names#Localization
>> the next paragraph in this wiki page is interesting too. We should avoid
>> transliterations. According to this rule 90% of the name:ko_rm and name:en
>> tags should go.
>>
>
> I think Romanized name is useful when the name doesn’t have meaning part.
> If a name doesn’t have meaning part, then there will be no proper
> translated name, too. In this case, only ko-Latn tag (or ko_rm) holds
> foreigner friendly characters properly. In this reason, I don’t hesitate to
> add ko-Latn to administrative units. However, I think Romanization should
> be avoided if a name has meaning part. (I already expressed my opinion in
> previous thread, but again…)
>
> 1) Romanization of Korean is not simple transliteration. It is
> difficult to guarantee correctness of Romanized name. First principle of
> Romanization is “Romanization is based on standard Korean pronunciation.”
> Finding proper pronunciation of Korean words is difficult job even native
> Koreans. As well as, “Proper names such as personal names and those of
> companies may continue to be written as they have been previously.” Only
> owner of the property can give proper Romanized name.
> See http://www.korean.go.kr/front_eng/roman/roman_01.do
>
> 2) Even it is my personal experiment, translated name is readable
> than Romanized name. I think it is better to encourage translate rather
> than Romanize.
>
> 2017-03-04 18:09 GMT+09:00 Max :
>
>> On 2017년 03월 04일 09:39, Andrew Errington wrote:
>>
>>> I agree that name tagging should be fixed, but I don't agree that we
>>> have a solution yet.
>>>
>> Indeed
>>
>> Firstly, name=* might not be in Korean language.  I can give several
>>> examples where the name of something in Korea (for example, a shop, or a
>>> restaurant) is in Chinese, English, or French.  So, I think we should
>>> not insist that 

Re: [OSM-talk] Fixing broken multipolygons

[moltonel]

On 4 March 2017 9:50:41 AM GMT+00:00, Martin Koppenhoefer 
>I want to point out though that "
>Errors: Inner rings with same tags as outer rings"
>
>are not necessarily errors, and should not be "fixed" unless you know
>very well the situation and can tell that there's indeed a
>redundancy/data problem. E.g. you can have a building or building:part
>inside another building or building:part. These could be tagged still
>"incompletely" hence having just the same tags for the moment but be
>different objects nonetheless. Similarly woods inside woods, etc.
>


You should also look out for MPs with tags on the outer ring but should 
actually only be on the realtion. Having the same tags on inner and outer is a 
nice heuristic that QA tools detect, but is not the only way that old-style 
polygons (which AFAIU wont be supported by osm2pgsql at some stage) can happen.

Sometimes it's tricky: I recently fixed a MP with no tag, 1 inner, 1 outer, and 
the outer taged as natural=wood leisure=park. Turned out the park was mostly 
wood with a clearing, so moved only natural=wood to the relation.


-- 
Sent from my internet

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

Re: [OSM-talk-ie] Gnerating visualisations from a set of OSM XML files.

[moltonel]

On 2 March 2017 7:07:21 PM GMT+00:00, Peter Mooney  
wrote:
>Hello everyone,
>
>At the Dept of Computer Science here in Maynooth University I currently
>have two undergraduate students working with me on an internship
>project.
>One of the key tasks in this project is to update existing data and
>contribute new data to OpenStreetMap in the University. Our focus is
>mapping the changes around the two campus from local knowledge and
>on-the-ground survey. So we are mapping everything from our new
>buildings
>to litter bins, trees, lampposts and sundials! In summary Barry [
>http://hdyc.neis-one.org/?barry23] and Stephen [
>http://hdyc.neis-one.org/?Stephen_Fay] have really embraced the
>challenge.


As it happens, I've done a bit of geometry cleanups via Bing/Mapillary around 
the Maynooth campuses recently.

While there's clearly a lot of great local knowledge in the current data, the 
geometries are messy: areas that should be unglued from highways, overlaping 
landuses (whether that's a error depends on the landuse type), too many closed 
ways at one spot that should be converted to MP relations, bad alignment and 
orthogonalisation, and outdated data (bing is from 2011, so I trust any object 
that's newer, but most are from 2009).

I'll do more fixup work in the coming days (roughly going from east to west), 
but the more you can fix as you go along adding local knowledge, the better :)


-- 
Vdp
Sent from a phone.

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

[OSM-talk-be] Fwd: [iRail] Job positions in open data not being filled in

[Ben Abelshausen]

Hi,

Anyone here who can help Pieter?

Cheers,

Ben

-- Forwarded message --
From: Pieter Colpaert 
Date: Sat, Mar 4, 2017 at 12:00 PM
Subject: [iRail] Job positions in open data not being filled in
To: iRail list 


Hi all,

I have 2 open positions at imec to work on open data:
 * https://www.iminds.be/en/about-us/jobs/jobs-overview/open-
data-researcher-smart-flanders
 * https://www.iminds.be/en/about-us/jobs/jobs-overview/vacancy
-for-big-andtransport-data-projects

I also see that MIVB-STIB has an open position to work on the Open Data
Platform:
 * https://www.linkedin.com/jobs/view/257410408/

It’s currently very hard to find people willing to work on Open Data
publishing for a living. Any ideas how to find the right people? Is there
anyone in your network that might be trained to work on Open Data?

Kind regards,

Pieter
___
iRail mailing list
ir...@list.irail.be
https://lists.okfn.org/mailman/listinfo/irail
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

semanárioOSM Nº 345 21/02/2017-27/02/2017

[weeklyteam]

Bom dia,

O semanárioOSM Nº 345, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado em português:

http://www.weeklyosm.eu/pb/archives/8796/

Aproveite!

semanarioOSM?
Quem?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Onde?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[Talk-es] Bienes de Interés Cultural en España

[dcapillae]

Saludos,

He documentado la  etiqueta para referenciar Bienes de Interés Cultural en
España   . Agradecería
cualquier aportación al wiki que sirviese para corregir o completar la
documentación sobre convenciones de etiquetado de Bienes de Interés Cultural
en España.

En el wiki existe una página dedicada a los  Bienes de Interés Cultural en
Canarias

 
, también en  Córdoba

  
y  Granada

 
, muy interesantes ambas para informarse sobre cómo se etiquetan estos
bienes. Personalmente he empezado a mapear los  Bienes de Interés Cultural
en Málaga

 
.

En el foro existe ya un hilo relacionado con el asunto de los BIC, aunque
centrado en el  Proyecto BICs de Canarias
  .



-
Daniel Capilla
OSM user: dcapillae 
--
View this message in context: 
http://gis.19327.n8.nabble.com/Bienes-de-Interes-Cultural-en-Espa-a-tp5892400.html
Sent from the Spain mailing list archive at Nabble.com.

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

Re: [OSM-talk] Fixing broken multipolygons

[Martin Koppenhoefer]

sent from a phone

> On 4 Mar 2017, at 08:49, Jochen Topf  wrote:
> 
> Looking at the graphs on http://area.jochentopf.com/stats you can see
> that the number of (multi)polygons is growing steadily, while the number
> of errors has been more or less flat over the last half year.


nice stats and good results.
I want to point out though that "
Errors: Inner rings with same tags as outer rings"

are not necessarily errors, and should not be "fixed" unless you know very well 
the situation and can tell that there's indeed a redundancy/data problem. E.g. 
you can have a building or building:part inside another building or 
building:part. These could be tagged still "incompletely" hence having just the 
same tags for the moment but be different objects nonetheless. Similarly woods 
inside woods, etc.

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

Re: [OSM-talk] Fixing broken multipolygons

[Jochen Topf]

Hi!

You all have been very busy fixing my challenges, so here are some more:
http://area.jochentopf.com/fixing.html#self-intersecting-polygon-ways

I have started to keep an ongoing "blog" where I'll post news and
information about the effort to fix the (multi)polygons:

https://github.com/osmlab/fixing-polygons-in-osm/issues/15

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [OSM-talk-nl] Maproulette challenge voor dubbele amenity's

[Maarten Deen]

Dan moet je inloggen op maproulette (rechtsboven). Dat doe je met je OSM 
account, je wordt dan naar de OSM site geleid die vraagt of Maproulette 
toestemming mag hebben om je account te gebruiken.


Groeten,
Maarten

On 2017-03-04 09:27, taede terpstra wrote:

Krijg een 401 unauthorized fout op de link

Verzonden vanaf Samsung-tablet.

 Oorspronkelijk bericht 
Van: Maarten Deen 
Datum: 04-03-17 08:59 (GMT+01:00)
Aan: talk-nl@openstreetmap.org
Onderwerp: [OSM-talk-nl] Maproulette challenge voor dubbele amenity's

Bij de AND import zijn er een aantal nodes aangemaakt die amenity=,
amenity_1= enz. hadden. Die zijn later gecombineerd tot één amenity
tag
als amenity=parking;fuel.
Deze worden niet gerenderd op de kaart, ze staan meestal op de
verkeerde
plek (ook als onderdeel van een way) en zullen tegenwoordig ook wel in

de buurt goed gemapt zijn.

Ik heb een maproulette challenge gemaakt zodat deze nodes een keer
opgelost kunnen worden: http://maproulette.org/ui/metrics/1501

Groeten,
Maarten

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


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

Re: [Talk-ko] Fixing laguage-mixed name tag in Korean region

[Andrew Errington]

Hello,

I agree that name tagging should be fixed, but I don't agree that we have a
solution yet.

Firstly, name=* might not be in Korean language.  I can give several
examples where the name of something in Korea (for example, a shop, or a
restaurant) is in Chinese, English, or French.  So, I think we should not
insist that name=* must always be Korean.

However, it is useful to make a record of the Korean name in name:ko=* even
if it is the same as name=*.  The reason for this is so that we can make a
multilingual map.

I agree that if name=* is a combination of "Korean (English)" it should be
changed, but as an English speaker living in Korea it is very useful for
me, so I am reluctant to make that change.  And if it's useful for me, it
is probably useful for other people.

This brings me to another important point, we must think of the people who
will be using the data.  We must provide data which is properly tagged so
that the map renderer can choose the correct tag to label every road or
street or building for the language chosen by the user.  I think the reason
why name=* was a combination of "Korean (English)" was because we didn't
have renderers that could render in different languages.  Maybe we still
don't, but we should be thinking of the future, as well as the present.

I think we have to have a full discussion before you run your automated
script.  We should also remember that there is no urgency, and we should
not be hasty.

Best wishes,

Andrew


On Mar 4, 2017 4:36 PM, "느림보"  wrote:

I opened new thread to discuss automatic modification of name tag.

For of all, I want to describe background.

Many POIs in Korean region have their name tag in *한국어 (English)* form.
That form had been required for several years for some technical issue (I
don’t the technical issue exactly.) However, the rule was changed on Oct.
2014 by adopting Changwoo’s suggestion.

> It's time to change the policy of name
> =* back to the global rule;
> discard " (English)" and use Korean local name only. Problems of bi-lingual
> "한글 (English)" format are:
>
>- It is against the global rule.
>- It makes map internationalization process difficult, because its
>value cannot be used as default local name.
>- Its bi-lingual format is often not appropriate for default labels.
>- Source: http://wiki.openstreetmap.org/wiki/Talk:Korea_Naming_
>Convention
>
> Rule was changed but there was no action for modifying legacy names. It
was the biggest harassment when I joined the community: “There are two
naming rules. *한국어 (English)* form is using without any documented
guideline. Which style should I follow? Can I modify *한국어 (English)* form
to *한국어* form?”



Finally, I decided to write automated script to rename legacy style with
new one.

There must be no losing of information during automated modification. So, I
defined condition of POIs like below:

1) A Korean POI has at least one Hangeul character (and is in Korean
region.)

2) If name tag of a Korean POI is equal to “name:ko (name:en)” then it
is legacy style.

3) If name tag of a Korean POI ends with “(name:en)” then it might be
legacy style.

4) If name tag of a Korean POI is made of “first-part (second part)”,
the first-part contains Hangeul, and the second part doesn’t contain
Hangeul, the it might be legacy style.

Before regional filtering the number of items are

1) 336,336

2) 55,989

3) 84,764

4) 11,621

Detailed review will be required for 4) case, but 11,621 items are not big
for that for me.

Please leave messages If you have any concern or opinion for my suggestion.



느림보 (Nrimbo)

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

Re: [OSM-talk-nl] Maproulette challenge voor dubbele amenity's

[taede terpstra]

Krijg een 401 unauthorized fout op de link



Verzonden vanaf Samsung-tablet.


 Oorspronkelijk bericht 
Van: Maarten Deen 
Datum: 04-03-17 08:59 (GMT+01:00)
Aan: talk-nl@openstreetmap.org
Onderwerp: [OSM-talk-nl] Maproulette challenge voor dubbele amenity's

Bij de AND import zijn er een aantal nodes aangemaakt die amenity=,
amenity_1= enz. hadden. Die zijn later gecombineerd tot één amenity tag
als amenity=parking;fuel.
Deze worden niet gerenderd op de kaart, ze staan meestal op de verkeerde
plek (ook als onderdeel van een way) en zullen tegenwoordig ook wel in
de buurt goed gemapt zijn.

Ik heb een maproulette challenge gemaakt zodat deze nodes een keer
opgelost kunnen worden: http://maproulette.org/ui/metrics/1501

Groeten,
Maarten

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

Re: [Talk-ko] Fixing laguage-mixed name tag in Korean region

[Max]

On 2017년 03월 04일 08:35, 느림보 wrote:

I opened new thread to discuss automatic modification of name tag.



Many POIs in Korean region have their name tag in /한국어(English)/form.
Rule was changed but there was no action for modifying legacy names. It
was the biggest harassment when I joined the community: “There are two
naming rules. /한국어(English)/form is using without any documented
guideline. Which style should I follow? Can I modify /한국어(English)
/form to /한국어/form?”


I wouldn't say that there was no action. New items since have been added 
in the new scheme and some of the old ones have been modified to match 
the new scheme.


I also believe the process is kind of slow and unsatisfying. May be some 
kind of (semi-)automated process of conversion would indeed be good.


That said, I think there are valid objections to it too.
1. From what I have been seeing in the main talk list there is a great 
opposition against automated edits, and a strong belief in the crowd 
approach.
2. Many POIs in Korea are outdated and not valid any more. In the 
problematic import, there are all kinds of hospitals and clinics that 
are closed by now. Editing those would "mark them like new" and it would 
not be visible immedately that they might not be valid any more
3. There are other related issues that should be discussed and adressed 
too and possibly solved at the same time.


The current scheme is not perfect either. There are some issues to be 
discussed.


name=한국어
name:ko=한국어
name:en=Roman-ized
name:ko_rm=romanized

name=한국어 and name:ko=한국어 are kind of redudnant, but it is probably 
neccessary to help transitioning. Also it is the same way in Japan.


name:en=Roman-ized and name:ko_rm=romanized ok, I made a little joke, 
because in 80% of the cases they are identical and they should not.
That something is written in Latin characters doesn't make it English. 
Even if you capitalize it and write it in several words.
In my opinion the field en thould not be there if it isn't English. I 
regulary delete this field if it is identical to ko_rm


There are some elements like country, city or some subwaystations that 
have their name written in all kinds of languages in the OSM database, 
but this practice is questionable, It might be handled better in 
something like wikidata.


ko_rm should actually be renamed in bulk to ko-Latn, possibly in 
cooperation and discussion with the japanese community who have the same 
problem with ja_rm that should be ja-Latn


See here: https://wiki.openstreetmap.org/wiki/Names#Localization
the next paragraph in this wiki page is interesting too. We should avoid 
transliterations. According to this rule 90% of the name:ko_rm and 
name:en tags should go.


My opersonal rule of thumb is that I add the name:en tag only if the 
romanization could not be done automatically, or the original name is 
indeed English (most of the time it's both actually) like a Starbucks 
for example.


Most of the time the romanization follows a strict rule, meaning it can 
be done much better and accurately if done by the renderer and doesn't 
need to swell the database.


TL;DR
I agree, there should be some automatic or maybe semi-automatic process 
to clean up the map/database, but we need to discuss the issues here 
before and maybe even drag this discussion to the main email list to get 
a feedback..


m.







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

[Talk-de] Re: Re: Technische Frage ÖPNV-Karte / Mapnik-Karte

[goegeo]

Hallo zusammen,

kann Entwarnung geben, momentan stellen sich sukzessive Änderungen ein. 
Allerdings sind davon bisher nur die die Standardkarten betroffen (egal 
ob Deutscher- oder Mapnik-Stil). Auf der Verkehrskarte und ÖPNV-Karte 
sind die Änderungen allerdings noch nicht verarbeitet. Entschuldige mich 
auch für die offensichtliche Ungeduld. Die letzten Änderungen (unter 
anderem eben auch die Namensänderungen sind doch noch nicht Wochen her, 
sondern erst einige Tage). Hatte aber schon mal vor einiger Zeit 
ähnliche Probleme im Bereich Langenhorn (Nordfriesland). Da hatte ich 
bestehende Nodes verschieben müssen, da nach dem BING-Satellitenbild die 
Haltestelle anderswo lag und ich für PTv2 beide Fahrtrichtung mit 
getrennten Haltestellen-Haltepunkten erfassen wollten.


Zur Info die betroffenen Haltestellen:

Husum (Nordsee) Brücke (letzter Änderungssatz: 46471657)
Husum (Nordsee) Gewoba (letzter Änderungssatz: 46201699)
Husum (Nordsee) Volkshochschule (letzter Änderungssatz: 46471110)

außerdem weitere im Bereich Husum-Schobüll.

Wie schon gesagt: Ich warte jetzt erst einmal ab. Trotzdem Danke für 
Eure Tipps.


Beste Grüße

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

Re: [Talk-cz] nahrávání fotek rozcestníků

[Marián Kyral]

Dne 4.3.2017 v 07:27 Zdeněk Pražák napsal(a):
Při nahrávání fotek rozcestníků a informačních tabulí přes 
http://map.openstreetmap.cz/osmcz/ jsem si všiml, že přestože při 
nahrávání zvolím položku informační tabule, tak nahraná fotografie 
neobsahuje tag infotabule a objeví se tedy v seznamu nepoužitých 
rozcestníků na

http://osm.fit.vutbr.cz/OsmHiCheck/gp/?img=petr1888

jedná se např o  fotky s Id 11357, 11358 a další
Pražák



To je proto, že ten přepínač prostě nic nedělá a jen vyvolává mylný 
dojem, že by snad mohl něco dělat. Walley to prostě nenaimlementoval. A 
asi to už opravovat nebude, když chystá nové nahrávátko. Ale nevím, jak 
na tom je. Asi zatím nijak :-(


Marián


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