Re: [Talk-at] Gefahr durch Internet-Bergrouten

[Max Berger]

Hallo,

kleine Anmerkung: opentopomap.org berücksichtigt sac_scale, jedenfalls
in 3 Gruppen (T1-2 oder gar nix / T3-4 / T5-6 oder via_ferrata_scale>0)
mit unterschiedlicher Punktierung. trail_visibility wird auch ein
bisschen dargestellt durch blassere Punkte.

Hier eine Gegend mit allen Arten von sac_scales:
https://opentopomap.org/#map=16/47.44846/11.78192

Hier ein Weg, der zwischendrin trail_visibility=bad ist:
https://opentopomap.org/#marker=16/47.56030/11.56659

Diskussion dazu gabs hier:
https://github.com/der-stefan/OpenTopoMap/issues/66

Is halt ein bisschen schwierig, das alles dazustellen, wenn man nicht
gerade eine reine Bergwegebene mit roten Strichen über die Karte legen
will, mit eigener Symbolik für Schwierigkeit und kleinen Leitern für
Klettersteige. Diskutiert wurde das hier:
https://github.com/der-stefan/OpenTopoMap/issues/66


Noch eine Karte, die es darstellt wäre der Renderer von Komoot, laut
Legende in der Abstufung T1/T2-3/T4-6
https://www.komoot.de/plan/@47.4486458,11.7846715,16z
und eigenen Symbolen für Klettersteige:
https://www.komoot.de/plan/@47.2692735,11.2701125,19z


Grüße
    Max



Am 19.09.20 um 15:29 schrieb Marcus MERIGHI:
> hallo, 
> 
> fuer mich ist das thema nicht eingeschlafen... hatte aber einiges
> nachzudenken:
> 
> 1) ich kenne jetzt sechs faelle, in denen menschen auf von mir
>eingetragenen steigen in bergnot gerieten. zum (und mit) glueck in
>keinem fall (ganz) schlimme folgen.
> 2) ich tagge, soweit mit OSM-tags moeglich, so genau es geht.
> 3) wenn ich weiss, dass mein handeln (mapping) unerwuenschte folgen
>(bergnot) hat, kann ich dann mein handeln fortsetzen?
> 4) das mapping ist nicht das problem, sondern das rendering. 
>wenn markierte wanderwege auf der gerenderten landkarte gleich
>aussehen, wie wilde(ste) steige, dann fuehrt das in die irre 
>(siehe 3!).
> 5) ich moechte weitermappen, muss also versuchen, das rendering zu
>verbessern.
> 
> ich habe mir zu diesem zweck eine liste mit mir bekannten renderern
> angelegt und mir angesehen, ob diese unterschiede in den tags sac_scale
> und trail_visibility darstellen (nix=keine unterscheidung):
> 
> +++
> ( https://wiki.openstreetmap.org/wiki/List_of_OSM-based_services )
> 
> openstreetmap.org nix
> geofabrik.de standard nix
> 
> thunderforest.com/gravitystorm
> https://www.thunderforest.com/maps/outdoors/ gut
> https://www.thunderforest.com/maps/opencyclemap/ nix
> https://www.thunderforest.com/maps/landscape/ nix
> https://www.thunderforest.com/maps/transport/ nix
> 
> wanderreitkarte.de gut
> outdooractive.com OSM (free) strichstaerke
> öpnvkarte.de nix
> opentopomap.org nix
> hikebikemap.org nix
> mapy.cz nix
> bergfex.at OSM nix (und alt)
> +++
> 
> bitte gebt bekannt was ich alles vergessen habe!
> 
> mein plan ist, die "hersteller" freundlichst anzuschreiben und auf die
> problematik hinzuweisen. 
> 
> ich wuerde das schreiben zuvor hier vorlegen.
> 
> was sagt ihr zum vorhaben und zu den details?
> 
> pfirt'eich, marcus
> 
> sk...@ostblock.org (Stefan Kopetzky), 2020.08.29 (Sat) 18:34 (CEST):
>> On 27.08.20 19:37, Marcus MERIGHI wrote:
>>> Wir hatten hier schonmal eine Diskussion, was in Sachen weglose Anstiege
>>> zu bedenken ist:
>>>
>>> http://osm-talk-at.1116557.n5.nabble.com/Talk-at-Weglose-Anstiege-auf-Berge-eintragen-td2497.html
>>
>> War eine gute Diskussion, damals.
>>
>> Das damalige Beispiel (uvm.) hat sich irgendein "User" mit genau einem
>> Änderungssatz zu Herzen genommen und da einfach vor kurzem wild
>> reingelöscht, was er(?) für keine offiziellen Wege hält
>> https://www.openstreetmap.org/changeset/88569171), was ich persönlich
>> so, ganz ohne Diskussion für eine grobe Missachtung der Arbeit der
>> Vormapper und wg. dem Sockenpupperlaccount, eigentlich für eine Sauerei
>> halte.
>>
>> Ich wär hier für einen Revert. Nicht dass die Wege vorher unstrittig
>> wären (access=private, width=0 etc.), aber so ists "keine Art", wie man
>> hier sagt.
>>
>> Lg,
>> Stefan
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
> 

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

Re: [Talk-us] USFS Roads - name and ref

[Max Erickson]

Abbreviations are predominant in US highway refs, so I think that it is
fine to use one in USFS road refs.

At some point in time I had used ref=USFS xxx but changed stuff that I had
edited to ref=FS xxx. The usage of FS in Michigan is largely a product of
either my editing directly or my discussion with other mappers (and looking
at Overpass Turbo and Taginfo, something like 45% of all refs with the
string "FS" in them...).

I don't remember really, but I think I started with USFS because it was
nearly entirely unambiguous, and then I switched because the usage of FS
was more common.

ref:usfs=FS looks wrong to me, if usfs is in the key, then it doesn't
belong repeated in the value (unless there's 2 reference systems in use,
which there are, https://en.wikipedia.org/wiki/Forest_Highway is not the
same thing as the Forest Service logging roads)).

The use of ref:usfs also has the problem that it hides useful data on
general purpose maps that don't specifically use it.

If ref is to be used, I expect you won't arrive at any real consensus about
what to use as a prefix, because it's easy to have an opinion about it
(bikeshedding basically). I guess if enough people pick one we might get
close.


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

[Talk-us] Townships, Counties, Great Lakes

[Max Erickson]

I've recently been working on adding administrative boundaries for
townships in Michigan (old USGS paper maps show the boundaries, I'm tracing
those). Previously I've concluded that counties in Michigan don't really
extend into the Great Lakes. The sheriff has jurisdiction on the water
(extending into the water near adjacent counties), but that's about the end
of it. For the most part Michigan counties are modeled like that, using the
shoreline as part of the boundary.

What I am wondering about is whether townships should also use the
shoreline, splitting it into quite a few more pieces than currently exist.
The alternative would be a ways that share nodes with the shoreline. I'm
leaning in that direction but I figure it will be a pretty noisy change, so
I'm asking what people think before proceeding.


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

Re: [Talk-us] Great Lakes Circle (Tours, bicycle) GIS-folk?

[Max Erickson]

In the UP, USBR 10 isn't much more than the shoulder of US 2. It's
mostly paved, and every year there are fewer extremely narrow
sections! I guess there are probably a few signs, but not many.

Max

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

Re: [Talk-us] Great Lakes Circle (Tours, bicycle) GIS-folk?

[Max Erickson]

I live in Michigan and regularly drive US 2 in the Upper Peninsula.
The Lake Michigan route isn't signed in any sort of meaningful way.

Max

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

Re: [Talk-it] panettone di cemento

[Max]

Spero di non andare OT ma recentemente mi si è presentata una situazione
simile: un grosso masso posto al centro di una strada agricola posto per
impedire il transito ai mezzi a 4 ruote.
Come si dovrebbe mappare una situazione del genere?

Il giorno mar 26 mar 2019 alle ore 16:46 Volker Schmidt 
ha scritto:

> Dipende dove si mette. L'ho visto utilizzato anche per impedire le auto di
> entrare in una strada in questo caso potrebbe anche essere considerato come
> bollard.
> Lungo la strada non saprei neanche come taggare. Sia block sia bollard si
> riferiscono a una strada che si blocca parzialmante o completamante (nel
> caso del block è possibile anche questo)
>
> On Tue, 26 Mar 2019 at 16:40, liste_girarsi 
> wrote:
>
>> Il 26 Marzo 2019 16:16:55 CET, demon_box  ha
>> scritto:
>> >ciao, quale tag per questo panettone di cemento che in italiano viene
>> >chiamato (anche) dissuasore di sosta?
>> >
>> >
>> >
>> >grazie
>> >
>> >--enrico
>> >
>> >
>> >
>> >
>> >--
>> >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
>>
>> barrier=block
>>
>> --simone girardelli--
>> ##
>> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Max Erickson]

There's lots of discussion of these points as a mapping resource.

The thing is, they don't need to exist as current OSM objects for
mappers to use them as a resource, there's lots of other ways to use
them as a reference. The deleted points can be extracted from the
mechanical edit changesets or processed out of a current GNIS dump or
whatever.


Max

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

Re: [Talk-de] Suche einfache Android App nur um Punkte aufzunehmen

[Max]

Finger weg von Smartphone im PKW.
Mache automatische Fotosequenzen mit GPS tags. Nutze dazu mapillary oder 
OpenStreetCam. Da werden dann auch die Straßenschilder schon automatisch 
erkannt.



On 19.03.19 17:25, Heinz-Jürgen Oertel wrote:

Hallo,

wie im Betreff gesagt. Oder, wie macht ihr das, beim Fahren mit Pkw, also
höherer Geschwindigkeit, ohne anzuhalten, die Position von Schilder an der
Straße aufnehmen. Im einfachsten Fall ist das Handydisplay eine einzige
Schaltfläche. Ein Tipp, eine Position.
Besser noch eine konfigurierbare Fläche, für z.B.
Geschwindigkeitsbegrenzungen, Überholverbot etc. aber immer groß genug um beim
Fahren ohne Ablenkung bedient zu werden. Noch besser, wenn man dann noch per
Spracheingabe weitere Angaben zum Punkt machen kann.

Über Empfehlungen dankbar




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

Re: [Talk-us] Michigan Forest Land

[Max Erickson]

The US forum is pretty low traffic (a couple posts this year), so I
guess a topic wouldn't bother anyone:

https://forum.openstreetmap.org/viewforum.php?id=20

There's also a michigan channel on the osm us slack.

( https://slack.openstreetmap.us/ )

On Wed, Mar 13, 2019 at 10:58 PM Kevin Kenny  wrote:
>
> (Is there a Michigan-specific forum that we could take this to? We're
> probably boring the daylights out of most of talk-us.)
>
> On Wed, Mar 13, 2019 at 9:16 PM Max Erickson  wrote:
>
> > The management units in the data are subunits of the state forests
> > still. For instance, "Gwinn Forest Management Unit" is/was part of the
> > Escanaba River State Forest.
> >
> > The question is which data is better to present to the average end
> > user. I guess if the state isn't using the state forest names anymore
> > it makes sense to have the management units in OSM. But then because
> > people know the older names, does it make sense to also have the state
> > forests?
>
> What I see in the data doesn't match your description.  'Unit_name'
> appears to be one of sixteen large rectangular regions, and then
> 'management_name' is a fairly small region.
>
> I've sliced the data both ways, and put the results in
> https://kbk.is-a-geek.net/tmp/mi_sf.zip, so that you can open the data
> in JOSM and see what's up with it. DO NOT IMPORT - the translation is
> very rough and doesn't even pass JOSM's validation - I'm simply
> sharing it so that locals can see whether either division makes any
> sense in the local context.
>
> Simply coalescing the data led to topological problems, as I
> anticipated. I did some jiggery-pokery with ST_Buffer in PostGIS to
> force the topology to be consistent. The result is that every parcel's
> boundary is set back 2.5 metres from where it was in the original data
> set. This is surely no big deal as far as the map is concerned, but
> cuts way back on the validation errors.

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

Re: [Talk-us] Michigan Forest Land

[Max Erickson]

On Wed, Mar 13, 2019 at 11:20 AM Kevin Kenny  wrote:

>>
>> Complicating things, the state seems to have moved away from saying
>> much about the top level state forests. But I think they are probably
>> still the right thing for a general purpose map.
>
>
> Right. That's why I was talking about coalescing compartments that have the 
> same management type and name. The table in my earlier message shows the 
> number of compartments to be combined for each facility.

The management units in the data are subunits of the state forests
still. For instance, "Gwinn Forest Management Unit" is/was part of the
Escanaba River State Forest.

The question is which data is better to present to the average end
user. I guess if the state isn't using the state forest names anymore
it makes sense to have the management units in OSM. But then because
people know the older names, does it make sense to also have the state
forests?


Max

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

Re: [Talk-us] Michigan Forest Land

[Max Erickson]

The compartments likely aren't the right data for a general purpose
map; I'm not entirely sure, but they seem to be the basic management
unit for state forest land, so when they consider a cut or whatever
they consider it for that area. For OSM, the right things is probably
to have individual objects for each state forest, game area, park,
etc.

Complicating things, the state seems to have moved away from saying
much about the top level state forests. But I think they are probably
still the right thing for a general purpose map.


Max

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

Re: [OSM-talk] Google deletes map of Kurdistan - can we do better?

[Max]

I think it's a false equivalence to ask for Kurdistan in OSM when in the 
case of Google it was a users shared outline. The equivalent would be a 
uMap.  Here, I made one:


https://umap.openstreetmap.fr/de/map/kurdistan_281832

(I uploaded the .kml of the google user map)

I doubt this will enrage Turkish officials as much as a google branded 
one, but who knows, maybe they will protest with the french abassador, 
after all it is a .fr domain. /s


m.


On 10.01.19 22:36, Andreas Vilén wrote:

Hi!

The Turkish government has forced Google to delete a user made map of 
Kurdistan. I read this in a Swedish news article here: 
https://www.dn.se/nyheter/varlden/google-raderade-kurdistan-karta/ This 
is the best English source I can find: 
https://www.almasdarnews.com/article/google-forced-to-delete-custom-made-map-of-kurdistan-amid-pressure-from-turkey/


They were forced to delete it for Turkish citizens but chose to delete 
it completely anyway ("technical reasons"), but have since restored it 
for the rest of the world: 
https://www.google.com/maps/d/u/0/viewer?ie=UTF8=h=UTF8=0=1umTU2XPOmzQ245YY40dF_NNTpVc=36.21402763739052%2C39.249140445657076=9


This got me thinking: how does OSM display Kurdistan? It seems, we 
don't. This relation covers the Iranian province of Kurdistan: 
https://www.openstreetmap.org/relation/5392650 However there doesn't 
seem to be any map that covers the entire area.


I realize that it might be hard to map this since the region has no 
official border, right? I have no local knowledge at all, so I'm really 
just rising the topic for discussion. Also, there's no way to know if 
the Turkish government will crack down on OSMF if we do this.


Opinions?

Regards Andreas

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




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

Re: [Talk-ko] Result of survey about Korean name of railway station.

[Max]

Good idea! I think both challenges are relatively easy and fun.

max


On 30.11.18 19:27, Martijn van Exel wrote:

Perhaps this thread helps remind people :D

I can ‘feature’ one of them for a while if you think that may help?

Martijn


On Nov 30, 2018, at 11:24 AM, Max  wrote:

On 30.11.18 17:23, Martijn van Exel wrote:

By the way, there are currently 2 Korea specific challenges on MapRoulette, are 
these still relevant?
Bridges: https://maproulette.org/mr3/browse/challenges/403
Junctions: https://maproulette.org/mr3/browse/challenges/1460


Yes they are, but it is just so much work, they never seem to get any closer to 
be completed...

___
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




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

Re: [Talk-ko] Result of survey about Korean name of railway station.

[Max]

On 30.11.18 17:23, Martijn van Exel wrote:
By the way, there are currently 2 Korea specific challenges on 
MapRoulette, are these still relevant?

Bridges: https://maproulette.org/mr3/browse/challenges/403
Junctions: https://maproulette.org/mr3/browse/challenges/1460


Yes they are, but it is just so much work, they never seem to get any 
closer to be completed...


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

Re: [Talk-us] Forest Routes

[Max Erickson]

As other have mentioned, there are many numbered roads managed by the
USFS. They range in development from closed, abandoned log roads to
well maintained pavement. I map them using the FS prefix.

For the general public one of the main uses is the publication of
motor vehicle access conditions:

https://www.fs.fed.us/recreation/programs/ohv/ohv_maps.shtml


Max

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

Re: [Talk-it] Inserimento dati CAI

[Max]

Grazie per i consigli Alfredo, non avevo mai preso in considerazione il
Protlach, lo proverò e sulla base dei feedback di quest'anno sceglierò
l'editor più adatto per il corso del prossimo anno.

Anche sul Locus si ha la possibilità di importare layer WMS, e quindi di
usare carte tecniche regionali e carta IGM 25000, molto importante per noi
a sud dal momento che qui quasi non esistono carte escursionistiche di
facile reperibilità.

Riguardo la scelta dell'app su cui basare il corso nella mia sezione CAI,
ho preferito il Locus per una feature molto importante per fare rilievi sul
campo ai fini della mappatura su OSM: durante la registrazione della
traccia è possibile aggiungere in modo semplice e rapido waypoint di tipo
vocale, fotografico o video, con possibilità di esportare traccia e
waypoint in un unico package KMZ. Non sono riuscito a trovare una
funzionalità analoga e altrettanto comoda su Oruxmap, Alpine Quest, ecc. ma
magari mi sbaglio...

Altri punti di forza di Locus rispetto ai suoi competitor (tutti ottimi a
dire il vero) sono la possibilità di georeferenziare rapidamente e
utilizzare come layer scansioni o fotografie di mappe (per esempio foto
scattate al volo su pannelli informativi), e una funzione di pianificazione
del percorso molto ben fatta che consente ad esempio di verificare sul
campo i tempi di percorrenza di un percorso alternativo durante
l'escursione.

Max

Il giorno mar 6 nov 2018 alle ore 13:09 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> Ce ne sono si e se qualcuno e' abituato con quelle continui pure. Io in
> fase di pianificazione uso molto Orxumap perche' ci carico sotto tutte le
> CTR della mia regione e vedo dove sono vecchi tracciati che ora sono
> invisibile. Georesq pero' ha il vantaggio che per l'attivita'
> escursionistica e per il semplice rilievo di chi fa monitoraggio e' piu'
> semplice ed immediato. Ora poi che sono stati risolti i problemi di consumo
> batteria e ci sono anche le mappe off-line va decisamente bene.
>
> Alfredo
>
> On Tue, Nov 6, 2018 at 11:55 AM Max  wrote:
>
>> Si, ho consigliato di usare sempre il GeoResQ in background e in modalità
>> tracciamento oltre che per le richieste di aiuto, ma per mappe e strumenti
>> GPS disponibili IMHO ci sono app più funzionali e complete come il locus
>> map da usare in foreground rispetto al GeoResQ.
>>
>> ___
> 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] Inserimento dati CAI

[Max]

Si, ho consigliato di usare sempre il GeoResQ in background e in modalità
tracciamento oltre che per le richieste di aiuto, ma per mappe e strumenti
GPS disponibili IMHO ci sono app più funzionali e complete come il locus
map da usare in foreground rispetto al GeoResQ.


Il giorno mar 6 nov 2018 alle ore 11:01 Luca Delucchi 
ha scritto:

> On Tue, 6 Nov 2018 at 10:35, Max  wrote:
> >
> > Ciao Alessandro,
> > Ti ringrazio per i validi consigli, purtroppo il corso [0] è già
> iniziato. Prenderò in considerazione JOSM per la prossima edizione del
> corso.
> >
>
> parlagli almeno di GeoResQ [1] che è disponibile gratuitamente per
> tutti i soci CAI e ha una vestizione dedicata ai percorsi CAI
>
> > [0]
> http://www.caigioiadelcolle.it/blog/2018/09/9-ottobre-2018-corso-gps-su-locus-map-solo-android-e-openstreetmap/
> >
>
> [1] https://wp.georesq.it/
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Inserimento dati CAI

[Max]

Ciao Alessandro,
Ti ringrazio per i validi consigli, purtroppo il corso [0] è già iniziato.
Prenderò in considerazione JOSM per la prossima edizione del corso.

[0]
http://www.caigioiadelcolle.it/blog/2018/09/9-ottobre-2018-corso-gps-su-locus-map-solo-android-e-openstreetmap/


Il giorno mar 6 nov 2018 alle ore 09:12 Alessandro P. 
ha scritto:

> Il 06/11/18 00:35, Luca Delucchi ha scritto:
> > On Mon, 5 Nov 2018 at 23:42, Max  wrote:
> >>
> >> non ha nessun vantaggio, ma a differenza del WMS il TMS è compatibile
> anche con l'editor iD, per i motivi che spiegavo in precedenza.
> >>
> > a meno di richiesta esplicita dal CAI di creare un TMS il WMS/WFS è
> > abbastanza per le nostre esigenze.
> >
> > comunque per il lavoro che andremo a fare credo sia meglio JOSM e che
> > ad effettuarlo siano persone un minimo esperte
> >
>
> Ciao,
> forse Alfredo non sarà completamente d'accordo, ma per un corso
> consiglierei di partire subito da JOSM: ha più strumenti disponibili e
> può utilizzare il preset CAI che mostra maschere di inserimento dati
> molto intuitive.
> Partendo da https://learnosm.org/it/josm/start-josm/ trovate una guida
> passo passo scaricabile anche in formato pdf.
>
> Alessandro Ale_Zena_IT
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Inserimento dati CAI

[Max]

Il giorno lun 5 nov 2018 alle ore 23:21 Luca Delucchi 
ha scritto:

>
> perchè anche un TMS? quali vantaggi vedi rispetto il WMS?
> comunque per ora non è nei piani
>
>
non ha nessun vantaggio, ma a differenza del WMS il TMS è compatibile anche
con l'editor iD, per i motivi che spiegavo in precedenza.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Inserimento dati CAI

[Max]

 Seguo con interesse l'evoluzione del progetto e mi metto a disposizione
per le regioni Puglia, Basilicata e Calabria.
Riguardo al formato voto per lo Shapefile, abbastanza comodo per essere
importato con il plugin Open Data.
Se oltre al WMS fosse disponibile anche un TMS sarebbe comodo, presso la
sede CAI di Gioia del Colle sto tenendo un corso per soci di avvicinamento
a OSM usando l'editor iD, decisamente più facile per chi è alle prime armi.
Consiglio anche di mettere a conoscenza la lista talk-it-cai.


Il giorno lun 5 nov 2018 alle ore 16:52 Luca Delucchi 
ha scritto:

> Ciao a tutti,
>
> in relazione del bando CAI [0] volevo informarvi che è stato vinto dal
> sottoscritto attraverso il mio datore di lavoro la Fondazione Edmund Mach.
> Nel prossimo anno andremo ad inserire e uniformare quanti più "Percorsi
> CAI"
> possibili all'interno di OSM e dopo di che i dati saranno riportati
> nell'infrastruttura CAI denominata Infomont. Per uniformita' di
> terminologia
> il CAI gia' da tempo si riferisce ai sentieri come "percorsi
> escursionistici"
> in quanto il "sentiero" puo' essere anche solo una parte del percorso
> insieme
> ad una mulattiera, una strada, etc.
>
> Poichè è impensabile riuscire a coprire tutta Italia in un solo anno si è
> pensato che sarebbe molto utile il supporto della comunità sia di
> OpenStreetMap
> sia del CAI.
>
> Abbiamo pensato di utilizzare il Task Manager, creando un task per ogni
> regione,
> e di distribuire i dati disponibili  tramite servizi WMS/WFS (il WMS è già
> visibile in JOSM, invece per il WFS con QGIS è possibile convertire in
> un formato
> apribile in JOSM tramite il plugin OpenData, inoltre è stato aperto un
> ticket [1]
> per supportare i WFS direttamente in JOSM, vediamo se verrà
> implementato in tempo)
>
> La procedura che vogliamo seguire è la seguente:
> - selezionare un'area nel Task Manager
> - caricare il WMS (o il WFS quando disponibile) e aggiornare i dati. I dati
>   disponibili sono eterogenei, ci sono zone come ad esempio il Piemonte
> che sono
>   ricche di informazioni contenute nelle schede excel allegate alle
> tracce. In
>   quel caso e' necessario consultare le schede ed assicurarsi di aver
> inserito
>   tutti i dati disponibili circa la surface, la tipologia di tratta
> (track, path,
>   etc) e possibili punti di interesse (rifugi, bivacchi, fontane, etc).
>   La disponibilità delle schede, e come accedervi, verrà segnalato
> sulla descrizione
>   del Task Manager di quella determinata regione
> - modificare i percorsi seguendo lo schema CAI [2] e quando si è conclusa
> l'area
>   confermare il task. Se sono aree senza dati lasciare non confermato
> - a questo punto aggiornare la pagine sul wiki relativa ai sentieri [3]
>
> L'attivazione di nuovi task con relativa copertura dei dati CAI può essere
> fatta tramite la mailing list talk-it-cai oppure al mio indirizzo di lavoro
> luca.deluc...@fmach.it.
>
> Inoltre la mattina di tutti i venerdì sarà possibile avere supporto
> telefonico
> al numero 3386812277
>
> [0] http://www.cai.it/index.php?id=1916=0
> [1] https://josm.openstreetmap.de/ticket/16880
> [2] https://wiki.openstreetmap.org/wiki/CAI
> [3] https://wiki.openstreetmap.org/wiki/WikiProject_Italy/Sentieri
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] TIGER place confusion

[Max Erickson]

Just comparing relations with place= tags to the corresponding nodes works:

http://overpass-turbo.eu/s/CjI

Obviously not an OSM place=city there.


Max

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

[Talk-us] TIGER place confusion

[Max Erickson]

Many of the administrative boundaries imported from TIGER have a
place= tag that reflects the legal type of incorporation of the
municipality rather than a sensible value for the OSM place tag (which
would give some hint about the relative prominence of the place).

This confusion has gone under the radar, as openstreetmap-carto
doesn't render place labels from ways and relations:

https://github.com/gravitystorm/openstreetmap-carto/pull/2816

Deleting the imported place= values (or perhaps moving them to some
other tag, say something like incorporation=) would directly make the
data more accurate and improve maps that render place areas without
accounting for the confusion in the data.

What do people think about deleting (or adjusting) the place tag from
imported US administrative boundaries?


Max

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

Re: [OSM-talk] anonymous notes spam?

[Max]

On 20.07.2018 11:32, maning sambale wrote:

I'm getting several single letter notes comments since yesterday.
Example: https://www.openstreetmap.org/note/562375
Are people noticing the same?



yes

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

Re: [OSM-talk] WMF: "Interactive maps, now in your language"

[Max]

"Add the missing names to OSM in your language."

That is inflating the OSM database with something that Wikidata has 
solved already in a much better way. Why would someone from wikimedia 
recommend to create a less mentainable version of their database?




On 29.06.2018 12:18, Andy Mabbett wrote:

New Wikimedia Foundation blog post:

https://blog.wikimedia.org/2018/06/28/interactive-maps-now-in-your-language/




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

Re: [Talk-ko] promote mailinglist in ID

[Max]

Any comment?

Also: wouldn't it be better (redundancy) if there would be at least one 
more admin to this mailinglist? Maybe a korean native speaker?


On 28.05.2018 12:14, Max wrote:
After submitting a changeset ID shows on the left side some ways to get 
in touch with the community. This list is defined in a github.
Currently the Telegram Supergroup is promoted there while this official 
mailinglist is lacking.


https://github.com/osmlab/osm-community-index/tree/master/resources/asia/korea 



Since they ask for a contact email address, I suppose Andrew Errington 
should file an issue

https://github.com/osmlab/osm-community-index/issues/new


m.

___
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: [Talk-ko] Copy of thread reagrding redactions due to copyright violations in North Korea

[Max]

On the website http://38northdigitalatlas.org/ they write:

"This project is in a beta development phase. The ArcGIS platform allows 
users to search the data by name (in English and Korean) for cities, 
villages, factories, schools, government offices, restaurants, shops, 
markets, etc. However, because this data is generally derived from North 
Korean sources, Korean and English spellings can differ from South 
Korean protocol.


Although there is already a significant amount of data available in this 
portal, we have much more still to be processed. Over time, periodic 
updates will be made to the atlas of both location data and satellite 
imagery layers.


38 North would like to thank the programmers at i-cubed, and our 
partners at ScapeWare3d and Airbus Space and Defense for their help in 
designing and building this portal. 38 North is also grateful for 
generous support from the Carnegie Corporation of New York and the John 
D. and Catherine T. MacArthur Foundation for developing this important 
digital resource.
Copyright: The material in the “38 North DPRK Digital Atlas” is 
copyright protected by the US-Korea Institute at the Johns Hopkins 
School of Advanced International Studies, 38 North and Curtis Melvin. It 
is expressly forbidden to copy this material or use it in any other 
format. Licensing options are available. For details, please contact 
thirtyeightno...@gmail.com."



So basically they rip off DPRK official information to put it under 
their copyright. I bought a printed map in DPRK, will scan and provide 
it somwere.



On 04.06.2018 15:51, Changwoo Ryu wrote:

It's very sad. I have seen USKI at Johns Hopkins recently in Korean
newspapers; USKI has been mostly funded by the ROK government since
its beginning. (Only recently the funding stopped.) So practically
that 38north's map data has been built using ROK taxpayers' money.

___
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: [Talk-ko] Copy of thread reagrding redactions due to copyright violations in North Korea

[Max]

on the 38north website it says:
"38 North is a project of The Henry L. Stimson Center."

On 04.06.2018 15:51, Changwoo Ryu wrote:

It's very sad. I have seen USKI at Johns Hopkins recently in Korean
newspapers; USKI has been mostly funded by the ROK government since
its beginning. (Only recently the funding stopped.) So practically
that 38north's map data has been built using ROK taxpayers' money.

___
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: [Talk-de] Overpass-Integration meldet seit kurzem "Bad-Request" ohne Code-Änderung

[Max Berger]

Ich hatte heute das gleiche Problem. Bisher wurde das hier akzeptiert:

 [out:xml][timeout:3000];(node["mountain_pass"="yes"];
 node["natural"="saddle"];node["natural"="notch"];
 node["natural"="col"]);out body;>;out meta qt;

seit 3-7 Tage bekam ich einen Fehler 400 zurück. Lösung war
ein zusätzlicher ";" hinter "col"] und vor der Klammer

 [out:xml][timeout:3000];(node["mountain_pass"="yes"];
 node["natural"="saddle"];node["natural"="notch"];
 node["natural"="col"];);out body;>;out meta qt;

Keine Ahnung, ob das schon immer falsch war und akzeptiert wurde,
Gefunden habe ichs durch Vergleich mit dem Ergebnis des Wizards von
Overpass Turbo.

Grüße
  Max



Am 06.05.2018 um 23:20 schrieb dktue:
> Hallo,
> 
> auf der TüBus-Karte [1] funktioniert seit kurzem -- obwohl der Code
> nicht geändert wurde -- die Overpass-Abfrage nicht mehr. Der Request
> wird mit Status 400 beantwortet.
> 
> Weiß jemand, was sich geändert hat und was ich ändern müsste, damit die
> Abfrage wieder funktioniert?
> 
> Viele Grüße
> dktue
> 
> [1] http://tübus-karte.de
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-us] Gravel roads and surface tags in the US

[Max Erickson]

>I grew up in an area with these kinds of roads and I don't think
>they're technically compacted.  The gravel, which is crushed
>limerstone, is laid down and due to its chemical properties creates a
>smooth surface after several months of traffic.

Having read about this some since Tobey mentioned it on Slack, the
compaction is often meant to come from traffic.

In the Midwest the material is often from local "gravel pits" which
are glacial material, so a mix of sand and rounded stone. I think they
do some sorting and remixing of the material before using it for road
surface construction, and they definitely add clay as a binder.

I think the use of clean stone (the wiki gravel) is more common for
ornamental driveways than for any road meant to bear much traffic.
Apparently part of the issue is that there aren't many built roads in
the UK (and Europe in general) that aren't sealed.


Max

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

[Talk-us] mechanical edit of 'address' tags in New York

[Max Erickson]

Another proposed mechanical edit, splitting 'address' tags in New
York. The tags are mostly from an import of libraries.

Uses the same code as the MA splitting:

https://github.com/maxerickson/massadd

There's a lot less of them, only 290:

https://gist.github.com/maxerickson/3e5d6cb9f5b5306b8d15901b8fb351b1

Only objects where the "address" tag is correctly split and there are
no conflicts with existing tags would be altered by the edit. If the
address tag has a po box in it, it is stored in the contact:pobox tag,
which I guess can be controversial.


Max

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

Re: [Talk-us] 'address' tags in Massachusetts

[Max Erickson]

>There is a talk-us-massachusetts@ and I think review of your proposed
>mechanical edit should include that list.

Okay. This is pretty preliminary still, I just decided that feedback
was a good idea. Does that list overlap enough with this one that you
forwarding the message would be sufficient?

>I suspect people would be amenable, but it would be good to publish the
>code, and the proposed files to upload, so that they can be reviewed.

I've put the code at https://github.com/maxerickson/massadd

I guess I should have mentioned in the earlier message that it does
some (conservative) formatting cleanup. Tidying uppercase and
expanding a small number of abbreviations.

There's no OSM file because I don't think it is ready for upload (it's
quick enough to generate if you have curl and python3 installed). The
data at the gist does fully reflect the changes the script would
currently make.

>Also, it certainly makes sense that there are some values that are hard
>to parse.  The obvious approach is to just leave them out (and leave
>them for manual fixing or another day), but I'm not really sure exactly
>what you are proposing to do.

At the moment if the 'address' field is not parsed without error the
script doesn't do anything with that object. There's some 'address'
fields that are parsed incorrectly (mostly they include a po box or a
unit and could be excluded by matching for those). That's part of the
not being ready.

>As for nodes with both the old addr tag and new ones, you imply that the
>simplest way is to clean them up before a mechanical edit.  But that
>implies that if they aren't fixed first, you might do something to those
>nodes, and that seems against the spirit of the mechanical edit policy,
>which involves refraining from changes that you can't basically prove
>are correct.  But I don't expect you'd be doing that, so perhaps you can
>expand on what you meant.

Yeah, it isn't implemented yet but that is what I would do, skip those objects.

Overall I'm not in any hurry, but the majority of the address parse
correctly and after an edit would be used by more data consumers and
show up more clearly in editors and so on. It's something like 100
manual fixes to clear the way for about 3900 automatic splits.


Max

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

[Talk-us] 'address' tags in Massachusetts

[Max Erickson]

Many POIs in Massachusetts have reasonable address information stored
as a single value in the address tag (mostly from imports before the
'addr:*' scheme was established). Something like 1/2 of the uses of
'address' in OSM are in MA. I'd like to do a mechanical edit that
parses the individual pieces of the addresses and moves them into the
appropriate tags. Here is the work in progress data for the parsing:

https://gist.github.com/maxerickson/1ece717992043316bc615b8a98821efd

There's a few dozen addresses where the simple parsing I've written
doesn't work (lines start with "ERROR") and a few dozen more where a
PO Box means that the proposed parsing is wrong, with the PO box
appearing in the street or such. There's also about 100 occurrences of
an existing 'addr:*' value that does not match the data in the
'address' tag (these aren't visible in the gist). The simplest way to
deal with these issues is to clean them up before applying a
mechanical edit, so feel free to take a look at a couple and clean
them up.


Max

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

Re: [Talk-de] Challenge accepted?

[Max]

On 19.02.2018 22:14, Rolf Eike Beer wrote:

Am Montag, 19. Februar 2018, 22:06:59 schrieb Max:

Wenn man von der Adresse ausgeht, könnte man auch den Standpunkt
einnehmen, dass die Straßen in jeder Richtung eine anderen Namen hat,
und nicht, dass die Straßen gar keinen Namen haben. So scheint es ja
auch vor Ort ausgeschildert zu sein im Video.


Du übersiehst, dass jede Straße dann 2 Namen hätte, da sie ja an 2 Blocks
angrenzt.


Nein, nicht übersehen. Das ist exakt das, was ich geschrieben habe.
Also z.B.

name:forward=B1
name:backward=B2

und das obwohl es Einbahnstraßen sind. :)

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

Re: [Talk-de] Challenge accepted?

[Max]

Wenn man von der Adresse ausgeht, könnte man auch den Standpunkt 
einnehmen, dass die Straßen in jeder Richtung eine anderen Namen hat, 
und nicht, dass die Straßen gar keinen Namen haben. So scheint es ja 
auch vor Ort ausgeschildert zu sein im Video.



On 19.02.2018 20:27, Leon Karcher wrote:

Welche Challenge meinst du genau? Wenn es um die Blocks geht, die in dem
Video thematisiert werden: Die sind bereits gemappt, werden aber auf Carto
nicht gerendert.

LG, Leon

Am 19. Februar 2018 um 19:03 schrieb David Geiser :


Es geht um die namenlosen Straßen in Mannheim:
https://youtu.be/DSG-zxGRkJw


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

Re: [Talk-us] Rural US: Correcting Original TIGER Imported Ways

[Max Erickson]

In National Forests, USFS road data usually has sensible information
about the suitability of roads for general traffic.

There's an imagery layer showing the Forest Service data:

https://www.openstreetmap.org/user/Richard/diary/26099

I prefer opening transformed data as a layer in JOSM. Here's the
script I use to translate the data:

https://gist.github.com/maxerickson/32ca41e72458b12a5734f97f75800448

Followed by a command like

ogr2ogr /share/gis/extracts/test.shp /share/gis/USFSOsm/ -clipsrc
-85.2 46.2 -84.5 46.6

to clip out an area of interest. The advantage is not having to
remember a second set of visualizations for the various road features.


Max

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

Re: [Talk-us] Vermont Town Boundaries import

[Max Erickson]

I'm working on figuring out the licensing for a similar import in
Michigan (https://github.com/maxerickson/michigantownships ). I've put
together a translation for ogr2osm
(https://github.com/pnorman/ogr2osm) that takes a shapefile with
boundary polygons and outputs an osm file with merged relations, where
1 shared way represents the boundary between adjacent relations. It
seems there is a town polygon file
(http://geodata.vermont.gov/datasets/0e4a5d2d58ac40bf87cd8aa950138ae8_39),
it might save some work to adapt the translation file I have there. I
haven't looked at the osm data, if many town relations have already
been created it won't help merging the new geometries with those
relations.

The relation simplification should work as is, you'd just need to
adjust the filterTags tags function for the VT data.


Max

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

Re: [Talk-us] tiger name issue in New York

[Max Erickson]

I took note of it just seeing the name in parking lots in towns and on
obvious driveways. It seems armchair cleanup would be able to address
those.

Maybe I will get over my reticence to edit the wiki and make a page
for listing these sorts of "structural" issues with Tiger data. Could
also list things like counties with *extremely* poor geometry or high
numbers of service roads imported as residential.


Max

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

[Talk-us] tiger name issue in New York

[Max Erickson]

About 1600 highways named "Adirondack Park" and another 300 named
"Adirondack Park Preserve". Mostly service drives that are in
Adirondack Park, but it seems unlikely that they are all actually
named that way.

http://overpass-turbo.eu/s/vDk


Max

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

Re: [OSM-talk] Spam/Report user

[Max]

There is only info on how to delete content by spammers. No way to bring 
users to the attention of admins other then comments of changesets.


On 2017년 11월 26일 21:30, Simon Poole wrote:

See https://wiki.openstreetmap.org/wiki/Spam


Am 26.11.2017 um 21:00 schrieb Max:

Oh, and where is the page to report/block/ban spammers in the wiki
(not OSM, but osm/wiki accounts)?
like this one:
https://wiki.openstreetmap.org/wiki/Special:Contributions/Hpehoc


On 2017년 11월 26일 20:26, Simon Poole wrote:

Exactly the other way around: people love to create wiki pages and put
some outlandish claims on them that have nothing to do with reality,
leading to people that actually believe the nonsense to be frustrated
(in this case people believing that the page in question was set up and
is read by the admins).

Adding the warning on the page was calculated to set the expectations
right, obviously we need to resort to more drastic measures, what about

ADMINS HAVE NEVER READ THIS PAGE. ADDING ENTRIES TO THIS PAGE DOES
EXACTLY NOTHING

1/2 :-)


Am 26.11.2017 um 19:40 schrieb Max:

https://wiki.openstreetmap.org/wiki/Spam/Report_user

"Admins have never read this page, Adding entries to this page does
exactly nothing"

LOL. someone was frustrated and desperate here.

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





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




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





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




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

Re: [OSM-talk] Spam/Report user

[Max]

Oh, and where is the page to report/block/ban spammers in the wiki (not 
OSM, but osm/wiki accounts)?
like this one: 
https://wiki.openstreetmap.org/wiki/Special:Contributions/Hpehoc



On 2017년 11월 26일 20:26, Simon Poole wrote:

Exactly the other way around: people love to create wiki pages and put
some outlandish claims on them that have nothing to do with reality,
leading to people that actually believe the nonsense to be frustrated
(in this case people believing that the page in question was set up and
is read by the admins).

Adding the warning on the page was calculated to set the expectations
right, obviously we need to resort to more drastic measures, what about

ADMINS HAVE NEVER READ THIS PAGE. ADDING ENTRIES TO THIS PAGE DOES
EXACTLY NOTHING

1/2 :-)


Am 26.11.2017 um 19:40 schrieb Max:

https://wiki.openstreetmap.org/wiki/Spam/Report_user

"Admins have never read this page, Adding entries to this page does
exactly nothing"

LOL. someone was frustrated and desperate here.

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





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




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

[OSM-talk] Spam/Report user

[Max]

https://wiki.openstreetmap.org/wiki/Spam/Report_user

"Admins have never read this page, Adding entries to this page does 
exactly nothing"


LOL. someone was frustrated and desperate here.

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

Re: [Talk-us] Coolidge Corner, Brookline, MA has wrong zip code

[Max Erickson]

So just to follow up, what happens is that nominatim treats items
tagged with "addr:postcode" but not "addr:housenumber",
"addr:housename" or some type of POI tag as sources of postcode data.

There are quite few objects that will match that pattern that probably
aren't intended to define post codes. This Overpass API query does an
okay job of flagging them:

http://overpass-turbo.eu/s/t5g

It causes the server to run out of memory for large areas so just zoom
in and try again if that error happens. There's probably some more
tags to exclude but it already filters down to a manageable number of
objects.


Max

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

Re: [Talk-us] Coolidge Corner, Brookline, MA has wrong zip code

[Max Erickson]

Nominatim calculates 02118:

http://nominatim.openstreetmap.org/details.php?place_id=498867

Most of the data seems to have the correct addr:postcode:

http://overpass-turbo.eu/s/t5e

(The query includes postal_code but there aren't any in the data)

So what is Nominatim looking at to come up with the calculated value?
I think the next thing to check would be boundaries enclosing
Brookline, not sure if that is how nominatim works though.

Max

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

Re: [Talk-us] Integrating our open source data into OSM

[Max Erickson]

Hi-

It would be useful if you would describe how the data has been
collected and what other databases it may include information from.

OSM takes a fairly cautious approach to data rights, so it is a
necessary step to any import to clarify where the data has come from.


Max

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

Re: [Talk-de] Deutsche Namens-Tags in ...

[Max]

On 2017년 11월 06일 20:19, Richard wrote:

On Sat, Nov 04, 2017 at 09:11:34PM +0100, Markus wrote:


4. Wenn jemand lokale Namen in anderen Schriftsystemen abbildet,
damit Menschen die die ursprünglichen Schrift nicht lesen können,
wenigstens den Namen lautmalerisch nachbilden können,
dann macht das m.E. Sinn.
Leider haben wir m.W. noch keine tags für Schriften.
(und m.W. auch noch kein HowTo im Wiki)


gibt es schon einen Sprachcode für "phonetic"? Wobei es davon auch viele
Varianten gibt.
In vielen Fällen gibt es sogar eine offizielle phonetische Transkription,
die sollte man bestimmt  eintragen.



Das ist eine Dose mit Würmern. Wie ist denn die Aussprache von Zürich 
beispielsweise? Soll hier das Hochdeutsche in Lautschrift gesetzt 
werden, oder Schwizerdütsch? Das riecht eher nach einer Aufgabe für 
wikidata als für OSM.


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

Re: [Talk-de] Deutsche Namens-Tags in ...

[Max]

On 2017년 11월 05일 05:11, Markus wrote:

4. Wenn jemand lokale Namen in anderen Schriftsystemen abbildet,
damit Menschen die die ursprünglichen Schrift nicht lesen können,
wenigstens den Namen lautmalerisch nachbilden können,
dann macht das m.E. Sinn.
Leider haben wir m.W. noch keine tags für Schriften.
(und m.W. auch noch kein HowTo im Wiki)


Nein, transliterationen sind in OSM explizit nicht gewünscht, da sie 
besser maschinell gemacht werden als händisch.

https://wiki.openstreetmap.org/wiki/Names#Avoid_transliteration

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

[Talk-ko] Telegram (was: Re: Romanisation: a solution)

[Max]

I agree on this assessment of Telegram as a platform. However, it is 
very useful as a low-entry barrier place for casual discussion, quick 
question and dialogue type conversation that are harder in email, that 
requires a style that resembles more a letter exchange.


The mailinglist is the place where anything consensus forming is and 
will be taking place. It is also better for more complex issues.


The Telegram group is not meant as a replacement, but rather a 
complement to the mailinglist. Yes that fragments the discussion in 
smaller groups, but I think that's something we can live with. More 
problematic would be if discussion only takes place in a meduim that is 
unknown tou younger users and seems overly complicated and difficult to 
set up. Because let's face it: email only is a comfortable medium if you 
know what an email client is and you can use automatic filters, 
thread-view, etc. Mailinglists are another abstraction on top of this 
that the pokemon generation is not comfortable with. I don't even try to 
read the 19 mailinglists I am subscribed to on a mobile device, While 
it's entertaining to read the Telegram chat on a phone.


my 2 ct.

m.

On 2017년 10월 26일 13:20, Andrew Errington wrote:


Regarding the osmKorea group on telegram.me  I think 
it should not be promoted for two reasons.  Firstly, it seems that the 
messages can only be seen with the Telegram app.  They are not visible 
on a webpage therefore no-one can read any discussion or contribute 
without the app.  Secondly, the OSM community in Korea is small.  Not 
many people are subscribed to this list (Talk-ko) and using Telegram 
will fragment discussions further.  I suppose there is a third reason, 
and that is the most popular chat program in Korea is Kakao Talk.


In summary, I support changing ko_rm to ko-Latn, but I don't support 
using Telegram for discussion.


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

Re: [Talk-ko] Romanisation: a solution

[Max]

Agree, data consumers should read the tag case insensitive, just in 
case, but for tagging we should follow one recommendation and that 
should be -Latn


On 2017년 10월 26일 23:47, Lukas Sommer wrote:

Makes sense!

(I’m not sure about lowercase. I would rather opt for ko-Latn because
also also sr-Latn uses titlecase.)
Lukas Sommer


2017-10-26 3:06 GMT+00:00 Maarten van den Hoven :

Dear OSM editors,


This email proposes a solution to the Korean and Japanese romanisation
tagging issue. Since this topic concerns both Korea and Japan it is sent to
their respective mailing lists.

The tag for romanised korean is currently "name:ko_rm". However, this is not
the international standard. "ko_rm" was most likely chosen a long time ago
because people at the time were unformiliar with the global standard as seen
here (https://wiki.openstreetmap.org/wiki/Talk:Korea_Naming_Convention). The
global standard as defined by the Internet Engineering Task Force here
(https://tools.ietf.org/html/bcp47) and backed by W3C, Unicode, ECMA is
"ko-Latn" instead of "ko_rm". Adopting a global standard solves confusion
over the use of the tag
(http://wiki.openstreetmap.org/wiki/Multilingual_names#Korea).

This talk has been going on for the past years as seen by the above links
and this one ->
http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.ko/204
However, I was unable to find arguments in defense of the "ko_rm" tag.

Therefore, I suggest an edit of the OSM database (following the official
procedure as defined here
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct) of
changing all "name:ko_rm" tags to "name:ko-Latn", like Serbia did in the
past as well (http://wiki.openstreetmap.org/wiki/Multilingual_names#Serbia).

Before this change is pushed it is of course important to see if anyone has
objections or other reasons why the "ko_rm" tag was chosen over the
"ko-Latn" tag.

We encourage editors in Korea to join the OSM Korea Telegram chat group here
https://telegram.me/osmKorea.

Kind regards.

___
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




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

Re: [Talk-us] Redacting 75, 000 street names contributed by user chdr

[Max Erickson]

> I think that we need to ask MapBox to revise the 2017 Tiger layer.

Ian Dees put together the 2017 layer. There is also some kind of
rendering problem with name labels on short, curvy ways, the
characters are bunched up and overlapping and then there are gaps.

Max

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

Re: [Talk-us] Something very bad happening in Maryland?

[Max Erickson]

More at:

https://lists.openstreetmap.org/pipermail/imports/2017-October/005181.html

At the moment they are blocked:

https://www.openstreetmap.org/user_blocks/1587

It can be hard to say if the node only changesets are broken. JOSM
will split changes up like that when they exceed the API limit (10,000
objects) and the ways will appear in a later changeset.

Of course they are bad style whether they are broken or not, the
import should be split into smaller more manageable pieces.


Max

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

[Talk-us] Tracking Redaction Review

[Max Erickson]

I setup a sheet to try to consolidate information about what has been looked at:

https://docs.google.com/spreadsheets/d/1MbF4BptFvkY_Cp0zh1OKBxt_E9tdXklxRDfMW0baBvU/edit?usp=sharing

Open to anyway so just fill in a state once it is reviewed. I went
through the earlier thread and added anything mentioned as done.


Max

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

Re: [Talk-us] [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Max Erickson]

I reviewed about 40 ways in New York. Here's an Overpass script for
finding the ways that have not been changed since the redaction:

https://gist.github.com/maxerickson/e02651cce99af983949b91f8d471fb23

The ways are clustered quite a lot.


Max

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

Re: [Talk-us] Redacting 75, 000 street names contributed by user chdr

[Max Erickson]

Yeah, I'm about done with Michigan (40 ways to check).

I just used the OpenData plugin for JOSM to open a filtered csv, which
made it clear there were a few clusters. I downloaded the data for
each cluster and used a search "type:way user:woodpeck_repair" to add
the ways to the todolist plugin.


Max

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

Re: [Talk-de] Routenplanung mit osrm

[Max]

On 2017년 10월 09일 13:36, Friedrich Strohmaier wrote:

DDOS oder schlicht zu viele legitime Anfragen?


Ist das jetzt noch eine legitime Frage, oder schon DDOS, wenn man es 
drei mal schickt?


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

Re: [Talk-us] dubious church node

[Max Erickson]

>One more thing to know about GNIS: entries are never deleted.

One minor exception to this is if they determine that a given feature
has 2 IDs, one of the IDs will often be removed.


Max

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

Re: [Talk-us] dubious church node

[Max Erickson]

There's a fair chance that a GNIS location is off by a couple miles. A
little bit more information from GNIS is available by putting the ID
into https://geonames.usgs.gov/pls/gnispublic/

It lists "Mill Creek Baptist Church" as a variant name.

From time to time I come across a GNIS entry that is off by dozens of
miles. I figure these must be typos during the location entry or
something like that, as many of them are located well. In this case I
would assume they only knew the church was in Nashville near Mill
Creek.


Max

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

Re: [Talk-us] dubious church node

[Max Erickson]

Yeah, a Google search for "Mill Creek Church nashville" has

http://freepages.history.rootsweb.ancestry.com/~nashvillearchives/millcreek.html

as an early result. It says the church building has been dismantled
but mentions a cemetery, which still exists nearby the mislocated osm
node:

http://www.openstreetmap.org/way/53498031#map=16/36.1182/-86.7267


Max

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

Re: [OSM-talk] Label language on the Default stylesheet

[Max]

+1
Until there is a (vector) map that allows you to change the preferred 
language dynamically or match against a priority list of languages from 
the user, the current principle of local language = display language is 
simply the best option.




On 2017년 09월 26일 23:00, Martin Koppenhoefer wrote:
for the record: using Latin would be the completely wrong message we 
could send out IMHO. It would make us look like an elitist circle [1] 
and would make many people feel rejected, or at least make them turn 
away as soon as they get to know about it.


Cheers,
Martin


[1] sometimes you already can get this impression about OSM, although it 
is a different bunch of elitists (computer science) than those typically 
studying Latin.



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




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

Re: [Talk-us] Functional Classification question in the Kansas City area

[Max Erickson]

Given that the HFCS can simply be added as another tag, I don't see
any reason to force OSM tagging away from what is sensible just to
line up with what the state says.

Max

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

Re: [Talk-us] "System Continuity" in the Functional Classification network

[Max Erickson]

Broadly speaking, yes, such continuity should apply. Maybe not using
exactly the same rule as the US DOT.

In practice there is an overfocus on observing how a given stretch of
road is built and an underfocus on the role it plays in the network.
My pet example is this stretch of US 2 & 41:
http://www.openstreetmap.org/#map=16/45.9090/-86.9901

Several times it has been upgraded to trunk, to reflect that it is
dual carriageway. But it doesn't make any sense for a trunk road to
run the short distance between a tiny village and a small town. Lately
I've been leaning towards classifying most of US 2 as trunk, as it is
the major east-west corridor in the region. But the difference between
primary and trunk should be for the longer stretch of road, not just
to distinguish that one stretch is overbuilt.

Another example I see in the data is short cul-de-sacs tagged as
tertiary, sometimes alone and sometimes as the continuation across an
intersection of a longer road. The sensible classification for these
is frequently unclassified, because they serve as the public access
road for a small commercial or industrial area.


Max

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

Re: [Talk-us] anyone know what software is generating these Q/A Notes?

[Max Erickson]

It's StreetComplete. Newer versions include the app name in the note:

https://github.com/westnordost/StreetComplete/issues/308


Max

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

Re: [Talk-us] Territorial municipalities, Guam's villages

[Max Erickson]

>> Max Erickson  writes:
>>
>> The image the linked image was traced from provides no provenance
>> (beyond "Own work"). It's tough to go from there to being sure that
>> derived data is okay to contribute to OSM.
>
>It is explicitly CC BY-SA 4.0.  Does OSM have a problem with that?
>
>SteveA
>California

I don't claim to speak for the gestalt that might be OSM, but all we
see there is that a Wikipedia editor, "Mr.Election" has asserted CC
BY-SA 4.0 over their contribution to the work. They give as a source
"This SVG map was traced from Guam-administracja", so to evaluate the
copyright status of the SVG, it is also necessary to evaluate the
copyright status of the Guam-administracja image. I don't see
sufficient provenance to come to a safe conclusion about the status of
the Guam-administracja image.

In any case, it seems similar boundaries are available from the Census.


Max

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

Re: [Talk-us] Territorial municipalities, Guam's villages

[Max Erickson]

The image the linked image was traced from provides no provenance
(beyond "Own work"). It's tough to go from there to being sure that
derived data is okay to contribute to OSM.


Max

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

Re: [Talk-us] Tiger Zip Data Removal Project (Update)

[Max Erickson]

Frederik wrote:
> I notice that at least two people who have negatively commented on your
> recent edits in changeset comments - Max Erickson and Steve A - are
> regulars on this mailing list, but they didn't get involved when you
> discussed the issue here four weeks ago.

As this is my second message, I'm probably not a regular on the list.

I saw the thread but didn't really have anything to add to the
comments from Jason Remillard, Mike N and Walter Nordmann. I do see
the particular edits as more or less noise but won't bother Hans
further if he chooses to continue with them.

Hans, I apologize for any discouragement my message caused. I tend to
write tersely and don't always do a good job of avoiding abrasiveness.


Max

(sorry if this message breaks threading a bit, I don't get messages
delivered and am experimenting with replying from an archive)

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

Re: [Talk-de] Diskussionen auf deutsch

[Max]

On 2017년 04월 24일 11:56, Hakuch wrote:

On 21.04.2017 13:29, Max wrote:

On 2017년 04월 21일 13:12, Hakuch wrote:

Aber, es wird an einer neuen Software für das Forum gearbeitet.


Ich hoffe es wird discourse, imo die einzige sinnvolle foren plattform.
http://www.discourse.org/


Nein wird es vom aktuellen Stand her nicht sein. Ich hab mich auch für
ein anderes Projekt mehr mit Discourse beschäftigt und ich halte es auf
jeden Fall für ein gutes sinnvolles Tool. Es die "einzig sinnvolle"
Plattform zu nennen ist meiner Meinung nach aber sehr engstirnig. Ein
Programm oder eine Plattform kann nicht überall die richtige oder
sinnvollste sein. Vor allem nicht, wenn es schon eine lebendige
Community auf einer bestehenden Plattform gibt.
Ich fände es tatsächlich spannend, wie sich die Community mit einem ganz
neuen Programm entwickeln würde und einige Funktionen von Discourse
finde ich toll und entdeckenswert.
Allerdings bin ich sehr sicher, dass die Oberfläche und Bedienung vor
allem erst einmal viele Leute abhängen und abschrecken würde. Und das
könnte für eine Community sehr schädlich enden. Solange es keine
umfassenden Wünsche zu einer neuen Software dieser Art von den
derzeitgen Forennutzer-innen gibt würde ich ihnen soetwas auch nicht
aufdrücken.

Innovation ist keine wenn sie von den Leuten nicht gewollt und getragen
wird. Allerdings finde ich auch, dass it technischer Hilfe einiges an
der Diskussionsskultur im Forum verbessert werden kann/muss. Aber
Schritt für Schritt, un dafür brauchen wir ersteinmal eine
modifizierbare Softwarebasis.


Ja, das war wirklich eine sehr verkürzte und vereinfachte Aussage von 
mir. Ich selber bin dankbar, dass es eine Mailingliste gibt, bei der ich 
mir das interface (den mail client) selber aussuchen kann. Da wir hier 
auf einer Mailingliste diskutieren, gibt es natürlich auch einen Bias 
zugunsten von Mailinglisten in der Diskussion. :)


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

Re: [Talk-de] Diskussionen auf deutsch

[Max]

Da fragt man sich schon warum sie dann nicht die Mailingliste benützen, 
wenn ein Forum zu 'Klickibunti' ist.


On 2017년 04월 22일 21:51, Simon Poole wrote:

Es ist wohl eher so, dass Discourse für ein grosser Teil der aktuellen
Nutzer des Forums genau das ist was sich -nicht- wollen (überladenes,
langsames, unübersichtliches Klickibunti, bei dem es weniger um den
Inhalt geht, als um den Inhalt in die "richtigen" Bahnen zu lenken).

Simon

Am 21.04.2017 um 13:29 schrieb Max:

On 2017년 04월 21일 13:12, Hakuch wrote:

Aber, es wird an einer neuen Software für das Forum gearbeitet.


Ich hoffe es wird discourse, imo die einzige sinnvolle foren plattform.
http://www.discourse.org/


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

Re: [OSM-talk] Coordinates in OSM. Really annoying

[Max]

On 2017년 04월 21일 16:28, Dave F wrote:

This is one of my OSM bugbears: http://osm.duschmarke.de/bbox.html


Can't use this tool, because alt + mouse click moves the whole window in 
my desktop environment.


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

Re: [Talk-de] Diskussionen auf deutsch

[Max]

On 2017년 04월 21일 13:12, Hakuch wrote:

Aber, es wird an einer neuen Software für das Forum gearbeitet.


Ich hoffe es wird discourse, imo die einzige sinnvolle foren plattform.
http://www.discourse.org/

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

[Talk-us] Prototype tool to conflate/import Microsoft buildings

[Max Erickson]

There's several scripts for outputting some information, generating
modified osm data and extracting buildings that aren't present at all
in OSM.

There's more description in the readme:

https://github.com/maxerickson/osm_ms_buildings

Only tested against the Michigan data which has 8140 geometries,
concentrated in the Detroit area. Not sure how things will go with
larger datasets. A clipped out region of reasonable size should work
fine (the scripts complete in a few seconds for ~10,000 buildings on
my older laptop).

For Michigan/Detroit, the main takeaway is that a *lot* of the
buildings are already in OpenStreetMap.

This histogram is calculated using the largest single overlap for each
existing OpenStreetMap building (data at
https://drive.google.com/open?id=0BxwWB33rZeUVU2FVaEVGUk9sNFU ):

bin   count
0.0-0.1 7645
0.1-0.2 41
0.2-0.3 34
0.3-0.4 53
0.4-0.5 64
0.5-0.6106
0.6-0.7112
0.7-0.8280
0.8-0.9954
0.9-1.0 5133

The areas there are presently calculated stupidly, in WGS 84, but I
think the relative information should be fine.

So of the ~14422 buildings present in OSM, 7630 don't overlap the
Microsoft buildings at all and 5 or 6 thousand overlap quite a lot. Of
the visual review I've done, I'd say that the existing OSM buildings
tend to be more detailed and line up more closely with current Bing
Imagery.

Separately, there are 410 buildings in the Microsoft data that do not
exist in OSM (take a look
https://drive.google.com/open?id=0BxwWB33rZeUVNTVJVmNQcEg2RHM ).

A more sophisticated matching algorithm is probably a good idea, but
for the Detroit data I would be pretty comfortable mechanically adding
the heights for the buildings where the overlap is roughly 80% or
higher and then doing a more manual process for the new buildings
(checking against newer imagery?), and then also doing some sort of
more manual process to capture the information from the several
hundred buildings with smaller overlaps.


Max

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

Re: [Talk-de] Drei Tage mit dem Plug-In Hybrid

[Max]

Herzlichen Dank für die übersichtliche Zusammenstellung zum Thema. Hat 
mich bislang als nicht betroffenen wenig interessiert und ist wohl 
deshalb an mir vorbei gegangen.


On 2017년 03월 28일 05:57, Harald Hartmann wrote:

Alles in allem: das Thema Elektromobilität ist wirklich noch sehr
ausbaufähig in Deutschland.


Jepp, alles bekannt, wurde auch bereits im Forum mehrfach diskutiert:
- Bitte amenity=charging_station rendern [1]
- Wie Ladestationen (amenity=charging_station) für Autos erkennen? [2]
- etankstellen - Hilfe bei der Datenerfassung [3]

[1] https://forum.openstreetmap.org/viewtopic.php?id=54525
[2] https://forum.openstreetmap.org/viewtopic.php?id=54928
[3] https://forum.openstreetmap.org/viewtopic.php?id=56744


Für OSM stellt sich hier die Frage:
Wie bildet man das sinnvol ab? Welche tags werden hier gesetzt?


http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dcharging_station


Und für die OSM daten-konsumenten:
Wie gestaltet man die User-Experience für jemanden, der die nächste
Ladestation sucht und dann da auch laden will?


Da es ja gleich mehrere Variablen sind - könnte auch schon in OsmAnd
langsam eng werden für einen eigenen Filter (den man aber selbst
irgendwie zusammenbauen müsste) - eventuell durch eine Spezial-App ...
die wird es aber erst geben, wenn genug brauchbare Daten zum Filtern da
sind :-/ (Henne-Ei-Problem)

Es braucht also am Anfang genug Enthusiasten, die so etwas einpflegen
... übrigens die Autogas-Fahrer haben ähnliche Probleme. Und auch für
normale Tankstellen gibt es immer wieder mal Wünsche nach einer
Wochenaufgabe [5]

[5] https://forum.openstreetmap.org/viewtopic.php?id=55813

In dieser Diskussion wurde auch beschrieben, wie die gerade aktuell ohne
irgendeine App trotzdem deine passenden Ladestationen (wenn denn schon
alle Daten da wären) finden könntest: einfach eine entsprechende
Overpass Abfrage schreiben ;)

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




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

[Talk-de] Drei Tage mit dem Plug-In Hybrid

[Max]

Hi,

hier eine kleine Anekdote, die aber vielleicht Relevanz hat für das 
mappen von Ladestationen.


Am Wochenende war ich mit dem Plug-In Hybrid unterwegs. Zuerst Leipzig. 
Also mal auf OSM geschaut (maps.me) wo es eine Ladestation gibt. Und 
tatsächlich, da waren welche. Vor der Säule musste ich aber feststellen, 
dass man sich da erst kompliziert anmelden muss, und Kunde der 
Stadtwerke sein muss. Also dann halt nicht.
Interessant aber: Das Display zeigt eine OSM Karte an. Ohne Attribution 
allerdings.

https://twitter.com/bauchhaus/status/846444675007483905
da habe ich mal schnell den access tag auf customers gesetzt.
Weiter nach Weimar. Da gibt's auch zwei Ladestationen. Die werden 
ebenfalls von den dortigen Stadtwerken betrieben und sind nur für deren 
Kunden.
Alles in allem: das Thema Elektromobilität ist wirklich noch sehr 
ausbaufähig in Deutschland. Zum Glück fährt dieses Auto auch mit Benzin, 
darauf verlassen, das man an einer Ladesäule auch laden kann, das sollte 
man eher nicht. Einmal gibt es solche "privaten" Ladesäulen nur für 
Kunden, dann gibt es auch noch zig verschiedene Kabel und Stecker, und 
letztlich verschiedene "infrastruktur-Ketten" wie Park oder 
DriveNow säulen oder eben dann die von RWE, Vattenfall, oder eben den 
Weimarer Stadtwerken.


Für OSM stellt sich hier die Frage:
Wie bildet man das sinnvol ab? Welche tags werden hier gesetzt?

Und für die OSM daten-konsumenten:
Wie gestaltet man die User-Experience für jemanden, der die nächste 
Ladestation sucht und dann da auch laden will? Wie es derzeit in maps.me 
ist macht es jedenfalls kein Sinn. Da kann man sich die Charging 
Stations auf der Karte anzeigen lassen, aber das hlft nicht wirklich weiter.


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

Re: [Talk-ko] Fwd: MapRoulette Challenge: Korean junctions

[Max]

Hi 느림보 and thank you for joining this maproulette challenge.
I am the author of it.

The original nodes have the format
name=라라교 (Lalakyo)
name:en=Lalakyo
name:ko_rm=Lalakyo

My intention was not to lose any information which is already there. 
Upon discussion on the list, it was discouraged to do translations into 
English. On the wiki, it is discouraged to do transliterations.


So my thinking was to change as little as possible while preserving as 
much information from the original import as possible. So above example 
would become


junction=yes
name=라라사거리
name:ko=라라사거리
name:ko_rm=Lalasagori

off cause the ko_rm really is a legacy key/value, I left it there out of 
respect for those who want it there and put it there in the first place. 
I removed :en because it is in 99 % identical with ko_rm and was not 
English in the first place. ko_rm is not a requirement, but it is 
information which is already there.


I'm against putting the "English" version ther which you can find on 
Korean Street signs. In your example (the linked photo) it's 
Yeongdonggyo(Br) which is a horrible butchery of language. First of all 
there is a missing space before the parenthesis and then it is kind of 
like "Yeongdong bridge (Bridge)" On the pircture there is no translation 
or romanization for the junction (Interesting, everything else is sort 
of translated)


Anyways, since there is currently no map that uses a mechanical way to 
do the romainzations, I would say that it maks sense to give those 
legacy manually transliterated idioms a home and put them in the 
database. Not ideal, but out of respect for those who were reluctant to 
to remove the "English" from the name= in the first place and also it is 
similar to how it is in Japan and other places.


Translating to English is tricky. Is it a junction, intersection, 
crossroad or crossroads? I don't want to make this descision. Is a 시장삼고리 
a Sijang Crossroad or a Market intersection? Honestly, I think this task 
is impossible.


Max

On 2017년 03월 20일 15:38, 느림보 wrote:

I joined MapRoulette today and found a challenge whose name is Korean
junctions.

Description of the project is below:

/Junctions and their names are very important in Korea and Japan,
because people will reference those (instead of the street names) to
describe a route or location. A junction with a name will be
rendered in Mapnik, but unfortunately many junctions have been
imported as single points close to the actual junction./


It suggests two fixed one is related to point and the other is naming rule.

Help fix junctions mapped as points in Korea.

 1. Junctions need to be the joining node of several ways, not a point.
 2. In ID, you can just move the node to the actual intersection.

Make sure the naming is correct.

Example: OLD (wrong): |name:사동삼거리 (Sadongsamgeori)|

NEW: |name:사동삼거리|, |name:ko_rm:Sadongsamgeori| |name:ko:사동삼거리|

I have some concerns related to the challenge.

Many Korean junctions were imported using mp2osm, however I looks like
there was no crosscheck after the importment. When I joined OSM
community, I modified some junctions in my local area (Gunpo, Anyang,
and Uiwang), and I found many POIs indicate un-named junction. (I
justified it using street sign on the road.) -- 17 of 58 POIs were
classified to the case and I deleted them.

Second, naming rule. Discussion on the naming rule is on-going. It is
going to have a consensus on some cases. Korean name into name / name:ko
tag. English name into name:en tag. However discussion on other topics
are on-going.

name:ko_rm is also on discussion -- some topics are
1) It is transliteration of name tag. Should we manage this tag manually?
2) Where should we write down Romanizeed form of untranslatable name?
For example. "name:en : Seoul." Is it OK to write down some
romanized form into name:en?



From above description, I suggest following things

1) Add task to check existance of the named junction.

You can find name of a junction top of road sign or near the junction
eg)
http://pds.joins.com/news/component/htmlphoto_mmdata/201402/04/htm_2014020411231837003790.jpg
(청담사거리)
<http://pds.joins.com/news/component/htmlphoto_mmdata/201402/04/htm_2014020411231837003790.jpg>

2) Do not require to add name:ko_rm tag. Instead replace its severity to
optional.

I think it would be better to encourage to add English name of juctions.
Some of road signs displays English name, in other cases it can be
easily translatable except one arguable thing.
There may be dis-agreements on translation of '삼거리 (3-way junction:
junction)' or '사거리 (4-way juction: intersection)' or '오거리 (5-way
junction: crossroads)' as description on
http://wiki.openstreetmap.org/wiki/Korea_Naming_Convention
<http://wiki.openstreetmap.org/wiki/Korea_Naming_Convention> because
offical english words for 삼거리, 사거리, 오거리 are junction 

Re: [OSM-talk] Broken multipolygons in South Korea

[Max]

You are welcome to post this as is on talk-ko. Most posts are in English 
there anyways. The "community" is small, all though there have been more 
users recently due to pokemon go.


On 2017년 03월 12일 11:29, Jochen Topf wrote:

Hi!

As you might know, I am on a "quest" to rid OSM of broken
(multi)polygons. (See http://area.jochentopf.com/ for info about that
and https://github.com/osmlab/fixing-polygons-in-osm/issues/15 for the
news about that effort).

I noticed a huge number of problems in South Korea, probably related to
some kind of import. I have taken those out of the challenges I am
generating, because I wanted to contact the OSM community there first.
Anybody here who has connections to South Korea and/or knows about
what's going on there?

Jochen




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

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

[Max]

On 2017년 03월 05일 09:00, 최규성 wrote:

I'm very interested in this dialog thinking it important. However, it
makes me confused on what the point is. To me, the points are coming as
1) How to Romanize Korean tags
2) Labeling convention for place names (or name field).


I think none of the above is disputed. We agreed on a scheme which is 
represented on the wiki, but the actual map has not been converted in 
all places due to the huge amount of data to be changed.



*1. How to Romanize Korean Tags*

Regarding this issue, there is an agreed practice in Korea. Korean
government has led the standardization that should be officially applied
to road signs, national basemaps, etc. The Romanization standard is
established by National Institute of Korean Language (NIKL), which is
found as below:

[In Korean] -

https://www.korean.go.kr/front/page/pageView.do?page_id=P000148_id=99

[In English] - https://www.korean.go.kr/front_eng/roman/roman_01.do


(Nrimbo's Google Drive document seems to be consistent with this though
lack of source referral.)


That's a nice reference, but again, it's not really what the discussion 
is about at the moment.



For use with mapping, a practical guideline is prepared by National
Geographic Information Institute (NGII), the national mapping agency of
Korea. It is well documented as linked below.

Toponymic guidelines for map and other editors for international use:

https://www.dropbox.com/s/hxngjd18jtbsm1q/Toponymy_Guidelines.pdf?dl=0

According to this, we can decide whether we have to choose 'Daehak-ro'
or 'University street'. My answer is 'Daehak-ro'.


Nobody wants to romanize 대학로 into University-Street, because that is a 
translation into English, not a romanization.


let's go through all the fields again:

name=대학로

that's the name of the street.

name:ko=대학로

that's the name of the street in Korean. A bit redundant, but it will 
help the transition.


name:ko_rm=Daehak-ro

Romanized Korean. It is a transliteration. You could also make one for 
Thai, Arabic etc. Transliterations are not recommended to do. The 
documents you liked prove that transliterations are very systematic and 
follow strict rules. In effect something that a computer perfectly can 
do, probably with less errors than a human. Read this:

https://wiki.openstreetmap.org/wiki/Names#Localization
So name:ko_rm has two issues: 1. it should be name:ko-Latn 2. It should 
not be there at all (in most cases, where it could be done programmatically)


name:en=University-Street

That's the English translation of the street. Something that I don't see 
the point adding for most cases. If it has the same content like ko_rm I 
usually remove this tag when I come across it.



=

Now it's up to the renderer to take this data and show it as it pleases 
(the eye).


On a Korean map:  대학로
On a romanized map: Daehak-ro
On a bilingual map: 대학로 - Daehak-ro
or: 대학로 (Daehak-ro)
or:

  대학로
Daehak-ro

=


Until now, we have discussed and agreed upon the schema of data, which 
is on the wiki.

We have agreed that we want to transition to this new scheme.
We only argue about HOW this should be done.


Here is one interesting online map service that exemplarily shows the
Romanized names. It is a Road Name Address Information System service by
Korean government - http://m1.juso.go.kr/eng/standardmap/MapIndex.do .
Here, we can identify how "Daehak-ro" and other street names are labelled.

But, I have a concern on how we make the awareness sure to every OSM
mapper of this standardized Romanization practice.


Again: IMHO the best would be to leave this to the renderer.


*2. Labeling convention for place names (or name field)*

I strongly support the idea of labelling the name by Korean and English
combination.


You are talking about the renderer, that is out of the scope of the 
current discussion.



As a result, it is against the idea of Yongmin. If OSM was designed only
for Koreans and by Koreans, it would have been agreeable. But, as many
of us would agree, OSM is designed as a global map for everyone in the
world. The map of Italy region is also lack of something. The Korean who
can't understand Italian (like me) becomes illiterate when I see it,
which needs to be improved. In this regard, I evaluate that OSM labeling
style for Korea region is more advanced than that for Italy.


OpenStreetMap is a database. The map you see on openstreetmap.org is 
just an example rendering of this database.



But, I have additional request of modifying the current style. My
suggestion is to separate Korean\English by line breaker AND to remove
the parentheses (round brackets). The parenthesis is useless.


This is exactly why we need the current database to be cleaned up. 
Because your favourite rendering style is easy to implement when the 
fields contain separate data in separate fields. Right now we have two 
different informations in the same name= tag.
If you just change name="대학로 (Daehak-ro)" into name="대학로 

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-ko] Someone is removing "sensitive" information

[Max]

Just stumbled upon tha the NIS headquarter and some other objects have 
been deleted again. That's at least the 3rd time now.


user woodpecker has already left a message on some of the changesets.

Comment from woodpeck 12 days ago

Hello, in this changeset you deleted y couple of buildings and your 
comment says that you deleted them because they are in a security area. 
However, OSM does not generally respect specific national security 
interests with regards to mapping. If a building is visible on aerial 
imagery, then it may be mapped in OSM, no matter whether it is in a 
security area or not. Deleting such a building, as you have done here, 
can be interpreted as an act of vandalism on OSM. Please don't do that.


Some of the affected changesets:

https://www.openstreetmap.org/changeset/46159152
https://www.openstreetmap.org/changeset/46159124 
https://www.openstreetmap.org/changeset/46159152 
https://www.openstreetmap.org/changeset/46159410 
https://www.openstreetmap.org/changeset/46159815 
https://www.openstreetmap.org/changeset/46159870 
https://www.openstreetmap.org/changeset/46159916


probably more.

the changeset comment is 건물삭제(보안구역) which translates to Removing 
buildings (Restricted areas)


Questions:
1. what are good tools to find more of this?
2. what are the right steps to do if vandalism like this is detected?
3. can this be avoided in the future?
4. is there a tool to get notified if someone changes a specific area?
5. who has authority to revert? should I try to do this, but I might 
miss something.


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

Re: [Talk-ko] Mailinglist in Korean?

[Max]

https://forum.openstreetmap.org/viewforum.php?id=95

I personally think that it's not worth it to worry about those 
prohibitions, because North Koreans don't have that access to the 
internet anyways. The Forum might be a place though where some armchair 
mapper asks questions regarding mapping North Korea, so. Anyways, just a 
thought, not so important. Good we have that forum now, maybe a welcome 
post would be nice! (and something the search engines can index..)



On 2017년 03월 01일 03:31, 느림보 wrote:

I asked to open users: South Korea forum. I limited region to South
Korea because un-authorized communication between people in South Korea
and people in North Korea is prohibited in both Countries.


2017-03-01 10:41 GMT+09:00 느림보 <nri...@gmail.com
<mailto:nri...@gmail.com>>:

    Opps, just Max said about interface language of mailman. I
misunderstood his suggestion, so I just tried to describe barriers
that I felt. (mailman and conversation language.) As 최규성 said I
think interface language is not a big deal.


2017-02-28 23:23 GMT+09:00 Max <abonneme...@revolwear.com
<mailto:abonneme...@revolwear.com>>:

Well, that's another big discussion about mailinglists vs. other
means of communication.

Some people for example prefer forums over email lists. There is
no "user: Korea" folder in the official osm forums
https://forum.openstreetmap.org/ <https://forum.openstreetmap.org/>

I'm not a fan of forums myself* so I am not volunteering to be
admin for that, but maybe someone else here wants to ask for the
creation of "users: Korea" there?

*exept https://www.discourse.org that one I found pretty amazing



On 2017년 02월 28일 13:35, 느림보 wrote:

>From systematic view, I think two reasons made few Korean speaking
members. One is clearly language. However, a mailing list
itself would
make it worse. I think a mailing list is one of the lease common
communication system in my country. People might don’t know
how to join
and act in this system. It looks like foreign culture. (I
don’t know,
too. I tried to response some previous threads but I
hesitated because I
don’t know what is impolite attitude in a mailing list.)



It might be very difficult to invite Korean contributors in
this system,
however more discussion in Korean might lead viewers into
discussion. So
strongly agree with this suggestion.


느림보 (Nrimbo)


2017-02-28 20:57 GMT+09:00 Max <abonneme...@revolwear.com
<mailto:abonneme...@revolwear.com>
<mailto:abonneme...@revolwear.com
<mailto:abonneme...@revolwear.com>>>:

Since there is no separate email list for the DPRK, that
might be
correct to use ko or am I missing something?



On 2017년 02월 28일 12:26, Changwoo Ryu wrote:

Actually "ko" is the ISO639 code for Korean
language. ("kr" ISO3166
code for ROK.)


2017-02-28 19:02 GMT+09:00 Max
<abonneme...@revolwear.com <mailto:abonneme...@revolwear.com>
<mailto:abonneme...@revolwear.com
<mailto:abonneme...@revolwear.com>>>:


Looking through
https://lists.openstreetmap.org/pipermail/
<https://lists.openstreetmap.org/pipermail/>
<https://lists.openstreetmap.org/pipermail/
<https://lists.openstreetmap.org/pipermail/>>
I noticed that most of them have the interface
in their
respective language.
talk-ko is in English though.
(Not talking about the languag of the actual
conversations,
just the mailman
interface)

Could this be a reason for the few korean
speaking members?
Should this be changed? (I'd say yes)
Any opinions, thoughts about it?



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

Re: [Talk-ko] Mailinglist in Korean?

[Max]

Well, that's another big discussion about mailinglists vs. other means 
of communication.


Some people for example prefer forums over email lists. There is no 
"user: Korea" folder in the official osm forums

https://forum.openstreetmap.org/

I'm not a fan of forums myself* so I am not volunteering to be admin for 
that, but maybe someone else here wants to ask for the creation of 
"users: Korea" there?


*exept https://www.discourse.org that one I found pretty amazing



On 2017년 02월 28일 13:35, 느림보 wrote:

From systematic view, I think two reasons made few Korean speaking
members. One is clearly language. However, a mailing list itself would
make it worse. I think a mailing list is one of the lease common
communication system in my country. People might don’t know how to join
and act in this system. It looks like foreign culture. (I don’t know,
too. I tried to response some previous threads but I hesitated because I
don’t know what is impolite attitude in a mailing list.)



It might be very difficult to invite Korean contributors in this system,
however more discussion in Korean might lead viewers into discussion. So
strongly agree with this suggestion.


느림보 (Nrimbo)


2017-02-28 20:57 GMT+09:00 Max <abonneme...@revolwear.com
<mailto:abonneme...@revolwear.com>>:

Since there is no separate email list for the DPRK, that might be
correct to use ko or am I missing something?



On 2017년 02월 28일 12:26, Changwoo Ryu wrote:

Actually "ko" is the ISO639 code for Korean language. ("kr" ISO3166
code for ROK.)


2017-02-28 19:02 GMT+09:00 Max <abonneme...@revolwear.com
<mailto:abonneme...@revolwear.com>>:


Looking through
https://lists.openstreetmap.org/pipermail/
<https://lists.openstreetmap.org/pipermail/>
I noticed that most of them have the interface in their
respective language.
talk-ko is in English though.
(Not talking about the languag of the actual conversations,
just the mailman
interface)

Could this be a reason for the few korean speaking members?
Should this be changed? (I'd say yes)
Any opinions, thoughts about it?



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

[Talk-ko] Mailinglist in Korean?

[Max]

Looking through
https://lists.openstreetmap.org/pipermail/
I noticed that most of them have the interface in their respective 
language. talk-ko is in English though.
(Not talking about the languag of the actual conversations, just the 
mailman interface)


Could this be a reason for the few korean speaking members?
Should this be changed? (I'd say yes)
Any opinions, thoughts about it?

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

Re: [Talk-ko] Questionable imagery

[Max]

On 2017년 02월 24일 04:25, Changwoo Ryu wrote:

Questions:
1. How comes? Where is the source? Is there a Korean blog entry, Naver cafe
or other site that shows people how to do it? Can we stop it at the source?
Could someone search this on naver/daum? I could not find it in a quick
attempt, but there must be a source.


I suspected this:

http://blog.naver.com/PostView.nhn?blogId=8527l=220919020518

This 1-month old blog entry had information on adding VMS as imaginary
source. So I have informed the author about the situation about two
weeks ago, and the author has deleted the info.


It's still there! on the previous page:
http://blog.naver.com/PostView.nhn?blogId=8527l=220922543377
At least in the screenshots.

M

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

Re: [Talk-ko] Use of questionable imagery in Korea

[Max]

Simon, off cause you are right. I was not the one finding out about the 
vworld image usage. I am not patrolling OSM, I don't even know the tools 
how to do it. I don't feel a responsibility for Korea nor do I feel I 
can speak for OSM Korea, because it doesn't really exist. I only heard 
about it here on the list and thought a issue in the ID bugreacker is a 
good idea.


However I think this situation is a good opportunity and an experience 
to learn from. We can create the structures to make sure this can't 
happen again. Or at least raise the awareness.


I have a few thoughts. Fist let me try an asessment of the situation for 
those from outside:


1. OSM in Korea is in a quite dire state. There are only very few 
contibutors, the quality of data is low, Most of it still stems from an 
import that is very old. Village POI are usually so off that it's 
impossible to know which village has which name without local knowledge. 
Junctions are imported as lone points, often with steets missing. 
Bridges too.
The language is a mess, with "English" and Korean mixed in brakets ((and 
double brackets too)). Half-translations such as "name=새마을11교(Sae 
Village 11 Gyo)"(sic)


2. Bing Satellite imagery is not available in big parts of the country.
https://www.openstreetmap.org/edit#map=16/37.1364/128.2107
Mapbox Satellite often only in B/W, cloudy covered or low-res
https://www.openstreetmap.org/edit#map=13/38.0416/128.2093

3. Commercial Map providers like Naver and Daum on the other hand are 
extremely detailed, up to date including even streetview from bicycle 
tracks and such.


4. The OSM community is very loose to say the least. I don't think 
anyone knows someone else IRL. There is the mailinglist with some months 
of 0 emails. It consists largely of expats and most posts are in English.


---

In this situation, now we have suddenly new users contributing a lot of 
detail http://osmcha.mapbox.com/46332326/
But they are not reacting on changeset comments or direct messages, 
maybe because of a language barrier.


Here my thoughts:
1. Is it somehow possible to not scare those away, now that their 
contributions will be reverted? Is there a way to say: "Thank you for 
your contribution, unfortunately we had to delete you edits because of 
legal problems from derived maps from unlicensed satellite images. But 
we want you to stay in our community"?


2. How to address the teenagers and Pokemon Go users with a lot of time 
and turn their obsession into something that is for the common good. 
(honestly that is what OSM is for me personally: Procrastination, but 
with the added bonus of doing something for mankind, compare this to 
playing candy crush.)


3. Should we embrace those kids better? Maybe having a booth at a games 
convention where pokemon users go?


4. Should OSM Korea make an effort to become some sort of organization?
Or would that lead to more problems even? Around Daegu I noticed that a 
lot of army bases are mapped, even with their names, which are 
completely censored on any other service. South Korea government and 
authorities might not find this funny. This is a very young democracy 
with the army and secret service having a lot of power. I think i 
remember a story that Revi has made some experiences here when he was 
editing wikipedia.


my 2 1/2 ct.

m.






On 2017년 02월 24일 13:08, Simon Poole wrote:

Just to be clear: a report to the DWG needs neither meetings, roles,
responsibilities or a common language (well it is likely that a report
in English will be easier to understand, but that is about it).

I realize that there might be a cultural hurdle, but any OSM contributor
can and should, if other avenues have not worked (naturally we all
prefer if things can be fixed locally and need not be escalated), report
use of sources that we do not have permission to use.

Simon


Am 24.02.2017 um 12:53 schrieb Max:

Paul Norman also has complained that nobody has contacted the DWG.
https://github.com/openstreetmap/openstreetmap-website/issues/1464#issuecomment-282268051
I guess this is because there is no organizational structure in the
Korean OSM community (yet). No IRL meetings, no roles, no
responsiblities, maybe not even a common language. As everyone can see
discussions on talk-ko happen to be mainly in English, so most mombers
are "expats" me included, and I am even not any more in Korea.
my 2ct..


On 2017년 02월 23일 21:00, Simon Poole wrote:

Just a couple of notes on the use of the VWorld imagery:

  * when you experience use of questionable sources in a larger way,
please inform the Data Working Group (d...@osmfoundation.org) and
take action without too much delay. These problems tend to get
larger, not smaller with time.
  * please point out the use of  problematic sources via changeset
comments to the mappers in question and point out that they are
doing nobody a favour.
  * while not speaking for the DWG, I s

Re: [talk-au] ACTmapi data and openstreetmap

[Max Bainrot]

Okies thanks

On 15 Feb. 2017 19:57, "Andrew Harvey" <andrew.harv...@gmail.com> wrote:

> CC BY is not enough for inclusion in OSM at the moment see
> http://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>
> It looks like Andrew has reached out the the ACT Government to get the
> required permissions but it doesn't looks like the process is complete yet
> http://wiki.openstreetmap.org/wiki/Contributors#
> Australian_Capital_Territory_Government_data
>
>
> On 15 Feb 2017 6:36 PM, "Max Bainrot" <mbain...@gmail.com> wrote:
>
> Hi everyone
>
> Is it ok to use ACTmapi data for mapping, specifically the 2016 (maybe
> 2015, iirc it's also creative commons) as iirc it's licensed under creative
> commons attribution.
>
> http://www.actmapi.act.gov.au/terms.html
>
> Also if we are able to use it how does one go about getting different
> datums to play nice in josm. ACTmapi uses AGD something.
>
> I have been successful in getting QGis to play nice with it so maybe it
> might be a case of having some kind of interpreter or using QGis to take
> AGD and output mecocretor geotiffs for import into josm.
>
> Cheers
> Max
>
>
>
> ___
> 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] ACTmapi data and openstreetmap

[Max Bainrot]

Hi everyone

Is it ok to use ACTmapi data for mapping, specifically the 2016 (maybe
2015, iirc it's also creative commons) as iirc it's licensed under creative
commons attribution.

http://www.actmapi.act.gov.au/terms.html

Also if we are able to use it how does one go about getting different
datums to play nice in josm. ACTmapi uses AGD something.

I have been successful in getting QGis to play nice with it so maybe it
might be a case of having some kind of interpreter or using QGis to take
AGD and output mecocretor geotiffs for import into josm.

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

Re: [talk-au] How to tag swimming pontoons

[Max Bainrot]

The swimming raft describes it exactly

man_made=pontoon was my first thought but wasn't sure (was checking on a
mobile device on the bus) so I'll use that.

With tagging the ladder, the pontoons can rotate a fair bit so how
sensitive is the position of something like a ladder?

Swimming area is also something I plan on marking as these swimming areas
do have buoys on like a cable around the perimeter marking the boundary.

Thank you to everyone for their input so far, the help is very much
appreciated.

On 26 Jan. 2017 21:14, "Andrew Davidson"  wrote:

On 25/01/17 22:05, Andrew Harvey wrote:


> As for the pontoon, per
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpier "The
> man_made=pier tag is used for a raised walkway over water supported by
> pillars made of metal/wood, or floating and secured using chains",
> plus floating=yes
>
>
It would depend on whether we are talking about a floating jetty:

http://www.letsonslanding.com/images/IMG_4212dock_wide.jpg

or what our American friends would call a swimming raft:

http://manitoulincedar.com/wp-content/uploads/2013/03/swim-raft-2013.jpg

The first one is a pier but the second one isn't.

It seems that there are two ways to tag a swimming raft. The first is from
OpenSeaMap seamark:type=pontoon

https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dpontoon

There's 36 of these. The other is man_made=pontoon (There's 87 of these).


On 26/01/17 10:25, Graeme Fitzpatrick wrote:
> Would you then mark the inside of the pontoon as a swimming pool?
>
> Could you mark a swimming pool in the middle of a lake?
>

Maybe swimming_area

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dswimming_area ?


___
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] How to tag swimming pontoons

[Max Bainrot]

Hi all

Quick question

How does one map a swimming pontoon? Our local lake has two beaches that
has them.

They consist of a floating platform with a ladder to one side and are
anchored to the bottom of the lake and are mostly static although they do
move and rotate a little.

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

Re: [OSM-talk] RU Wikipedia now uses OSM by Wikidata ID

[Max]

Works for me (Firefox 53)

On 2017년 01월 23일 07:31, Oleksiy Muzalyev wrote:

Dear Yuri,

Could you, please, provide an example with the location outline?

I tried Salzburg, New York, Odessa, Moscow, etc. in the Russian
Wikipedia, but I got always just a marker on the map, but not an
outline, i.e. a line indicating the outer contours or boundaries of an
object or figure. Perhaps, it is a thin line, and I do not notice it on
the map? Or I misunderstood something.

With best regards,
Oleksiy

On 21.01.17 02:40, Yuri Astrakhan wrote:

Russian Wikipedia just replaced all of their map links in the upper
right corner (geohack) with the  Kartographer extension!
Moreover, when clicking the link, it also shows the location outline,
if that object exists in OpenStreetMap with a corresponding Wikidata
ID (ways and relations only, no nodes).  My deepest respect to my
former Interactive Team colleagues and volunteers who have made it
possible!  (This was community wishlist #21)

Example - city of Salzburg (click coordinates in the upper right
corner, or in the infobox on the side):
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BB%D1%8C%D1%86%D0%B1%D1%83%D1%80%D0%B3

P.S. I am still working on improving Wikidata linking, and will be
very happy to collaborate with anyone on improving OSM data quality.



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

Re: [Talk-ko] Help fix Korean Crossroads on Maproulette

[Max]

Here is an interesting node:
http://www.openstreetmap.org/node/414930595

junctio=yes
name=영중면복지회관앞
name:en=Yeongjungmyeonbokji Hall Ap
name:ko_rm=Yeongjungmyeonbokjihoegwanap

Please help me out with my Korean, but I'm pretty sure the 앞 means 
something like "In front of" in English, not "Ap" which could be 
mistaken for a misspelling of the abbreviation of Apartment (Apt.).


IMHO It's another case of database inflation with "English" that just 
isn't English and should rather be ommitted or generated 
programmatically from the Korean, rather than be a key=value pair.




On 2017년 01월 09일 19:47, Max wrote:

I made this maproulette challenge so that the very important crossroads
can actually be mapped as junctions.

http://maproulette.org/map/1460/

___
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

[Talk-ko] Help fix Korean Crossroads on Maproulette

[Max]

I made this maproulette challenge so that the very important crossroads 
can actually be mapped as junctions.


http://maproulette.org/map/1460/

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

[Talk-ko] Help fix Korean bridges on Maproulette

[Max]

Finally this challenge made it live. Task is it to fix the Korean 
bridges that have been imported as nodes, not way segments.


http://maproulette.org/map/403

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

Re: [OSM-talk] South Korea Will Not Allow Google to Use Map Data

[Max]

On 2016년 11월 19일 13:01, Paul Johnson wrote:

On Fri, Nov 18, 2016 at 12:47 AM, Clifford Snow > wrote:

Just read on Yahoo [1] that South Korea will not give Google
permission to use map data. Guess Google could always use OSM data,
with attribution of course.

[1] 
http://finance.yahoo.com/news/south-korea-rejects-google-request-mapping-data-034923060--finance.html




I'm OK with that idea.  Honestly can't figure out why they don't do that
worldwide already.


They are not barred to send out their own survey teams and build a map 
from scratch. I suppose they could do that too. The export ban only is 
concerning the governmental dataset.


m.



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

Re: [OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Max]

On 2016년 09월 19일 20:06, Paul Norman wrote:

On 9/19/2016 3:24 AM, Andy Townsend wrote:

On 19/09/2016 11:13, Paul Norman wrote:


The changes this topic is about are not live on openstreetmap.org.
The original message has details, but the issue tracking the proposed
changes is
https://github.com/gravitystorm/openstreetmap-carto/pull/2349, and
you can see images there that show what the change is.


So perhaps the "huge improvement for the situation in Korea" mentioned
above is due to the move to Mapnik 3 (which as I understand it has
happened) rather than a font change?


While I can't speak for someone else, there are significant changes to
the appearance of Korean text in the PR and a lot of images showing
Korean that fix a few known issues. Also, Mapnik 3 didn't do too much
for Korean.


indeed. The improvement is the font, not Mapnik 3.


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

Re: [OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Max]

This is a huge improvement for the situation in Korea.
Thanks you for your work on this.


On 2016년 09월 18일 11:32, Paul Norman wrote:

I'm looking for feedback from people who read non-latin languages on a
proposed OpenStreetMap Carto font change.

We are considering moving to Noto fonts and could use feedback from
people who can read languages which have non-latin scripts, particularly
Asian languages. I've made previews in about a dozen different languages
at
https://github.com/gravitystorm/openstreetmap-carto/pull/2349#issuecomment-247819822
and want to check that there are no new problems. We may have to adjust
font sizes, but that's a different issue.

If you've got feedback, please leave it on
https://github.com/gravitystorm/openstreetmap-carto/pull/2349


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



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

Re: [Talk-ko] [OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Max]

This is a huge improvement for the situation in Korea.
Thanks you for your work on this.


On 2016년 09월 18일 11:32, Paul Norman wrote:

I'm looking for feedback from people who read non-latin languages on a
proposed OpenStreetMap Carto font change.

We are considering moving to Noto fonts and could use feedback from
people who can read languages which have non-latin scripts, particularly
Asian languages. I've made previews in about a dozen different languages
at
https://github.com/gravitystorm/openstreetmap-carto/pull/2349#issuecomment-247819822
and want to check that there are no new problems. We may have to adjust
font sizes, but that's a different issue.

If you've got feedback, please leave it on
https://github.com/gravitystorm/openstreetmap-carto/pull/2349


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



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

Re: [Talk-ko] Korean Font used in Carto

[Max]

Noto is the one I propose.
It has many different weights and aims to have the most international 
coverage.
Unfortunately the devs think it's not enough to see the mock-ups made in 
GIMP. Ping-Pong back the work



On 2016년 06월 29일 13:07, Andrew Errington wrote:

Is there a better, free, font?

How about Droid Sans?

Or Noto CJK KR?
http://www.google.com/get/noto/#sans-kore

There are other fonts listed here, together with their license (but not
many samples):
https://www.google.com/fonts/earlyaccess

Best wishes,

Andrew

On 29 June 2016 at 02:36, Max <abonneme...@revolwear.com
<mailto:abonneme...@revolwear.com>> wrote:

I think the current font used in the Carto rendering is not
readable. That's why i submitted a bug to the carto style:
https://github.com/gravitystorm/openstreetmap-carto/issues/2204
please add your voice.


On 2015년 11월 01일 20:45, Max wrote:

There seems to be some momentum in the development for the
rendering of
the main OSM style osm carto.

Have you noticed any oddities or bugs in Korea?

Maybe it's a good time to sumbit a ticket to change the horrible
font
for Korean? What do you suggest? The Nanum Gothic from Naver is
under a
free license and is AFAIK the only suitable candidate.

https://github.com/gravitystorm/openstreetmap-carto
Is the place to post issues. I could do that but wanted your
input for
anything font related.

m.


___
Talk-ko mailing list
Talk-ko@openstreetmap.org <mailto: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




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

[Talk-ko] Korean Font used in Carto

[Max]

I think the current font used in the Carto rendering is not readable. 
That's why i submitted a bug to the carto style:

https://github.com/gravitystorm/openstreetmap-carto/issues/2204
please add your voice.


On 2015년 11월 01일 20:45, Max wrote:

There seems to be some momentum in the development for the rendering of
the main OSM style osm carto.

Have you noticed any oddities or bugs in Korea?

Maybe it's a good time to sumbit a ticket to change the horrible font
for Korean? What do you suggest? The Nanum Gothic from Naver is under a
free license and is AFAIK the only suitable candidate.

https://github.com/gravitystorm/openstreetmap-carto
Is the place to post issues. I could do that but wanted your input for
anything font related.

m.



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

Re: [OSM-talk] Need to revert a bunch of changesets

[Max]

Korea needs more contributors desperately and everyone should be
encouraged to to become one. I just had a presentation where I showed
OSM to an interested audience. If this user did not understand the
rules, maybe that's also our fault that it wasn't clear? Or the
instructions in Korean are insufficient?
In any case, please make sure the contact with this newbie is correcting
the situation but is welcoming enough not to scare the user off.

my 2 ct.

On 2016년 06월 26일 17:51, Robert Helvie wrote:
> If there is a government source, it is highly likely that he is still
> copying a source that he shouldn't.
> 
> The Korean Government is very restrictive about how their data can be
> used. That's why Google has to have map servers physically within Korea
> to display the Korean data that they do show. 
> 
> Nonetheless, he is still copying from some source and not giving that
> source.
> 
> /"We should give meaning to life, not wait for life to 
> give us meaning. "/
> ~ unknown
> ---
> 
> On Sun, Jun 26, 2016 at 5:30 PM, Martin Koppenhoefer
> > wrote:
> 
> 
> 
> sent from a phone
> 
> Il giorno 26 giu 2016, alle ore 06:10, Robert Helvie
> > ha scritto:
> 
>> So I have sent two messages to this user with no response.
> 
> 
> DWG can put a block on him to be sure he gets the message. He should
> explain where he got his information from and if it is not an
> legitimate source the edits should be reverted 
> 
> 
>>
>> I now know for sure that he is copying information from Naver maps
>> (maps.naver.com ) a Korean map provider or
>> some other source.
> 
> 
> maybe there are other sources (e.g. government information) for
> these as well?
> 
> Cheers,
> Martin 
> 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk] How to handle Maps.Me ?

[Max]

The user experience of adding something to the maps.me map is quit cool
actually. It's really satisfying to see something immediately nicely
rendered. I recommend to try it.


On 2016년 06월 23일 01:05, Blake Girardot wrote:
> On Wed, Jun 22, 2016 at 2:47 PM, Simone Cortesi  wrote:
>> Did somebody get in touch with the people at maps.me?
>>
>> I think they should be involved in the mess their users are causing to our
>> ecosystem.
>>
> 
> Yes, maps.me is aware there is room for improvement in their editing
> tool. Zverik is from maps.me and has participated in the previous
> thread.
> 
> I think everyone is aware now it is a significant issue so working on
> constructive ways to improve the maps.me editing feature is probably
> the best way forward.
> 
> Terms like "sub-standard" "garbage" "mess" etc are not really helping
> get anything solved.
> 
> There are good suggestions in both of these threads, let us see what
> maps.me can or is planning on implementing to incorporate them as well
> as continue to offer constructive suggestions on how to improve the
> editing functionality in maps.me keeping in mind maps.me's goals for
> their application.
> 
> Regards
> blake
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk] How to handle Maps.Me garbage?

[Max]

just checked a few of the edits and deleted some nodes.
Lee Jin-Jeong did add a couple of things that were already there and in
the case of an hostel several times. In Kiev the user added a Korean
church with the name "Kiev Korean Unified Church" in Korean. The
location is a bit curious though in an industrial aera, but I left that
as is.


On 2016년 06월 22일 21:26, Michael Reichert wrote:
> Hi,
> 
> by browsing the map, I have discovered the edits of user 이진영
> (Google Translator says that this is a Korean name). He added some
> POIs in serveral European countries and entered the Korean name into
> name=*.
> 
> https://www.openstreetmap.org/user/%EC%9D%B4%EC%A7%84%EC%98%81/history
> 
> Shall I either revert his changesets in total or shall I change
> (mechanically/without local knowledge) name=* to name:ko=*?
> 
> Best regards
> 
> Michael
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 

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

Re: [OSM-talk] Failed water proposal reversal

[Max]

On 2016년 06월 22일 18:36, Martin Koppenhoefer wrote:
> 
> 2016-06-22 10:49 GMT+02:00 Max <abonneme...@revolwear.com
> <mailto:abonneme...@revolwear.com>>:
> 
> I did not see any
> voting.
> 
how?


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

Re: [OSM-talk] Failed water proposal reversal

[Max]

the whole process is too opaque. Also there are different protagonists
posting on wiki and email list. The gallery tag clarification stalled,
because what looked like a consensus on the email list had one loud
opponent on the wiki and not many other voices. I did not see any
voting. IMHO the process is inherently flawed.


On 2016년 06월 22일 15:17, Tomas Straupis wrote:
> My question/proposal was about what to do with failed proposals in
> general. That is:
> 1. How to identify a "failed" proposal
> 2. What to do with it
> 
> My proposal for point 1 is:
> If after say two years new schema does not get at least equal tagging
> count as the old schema - proposal failed.
> 
> My proposal for point 2 is:
> Mark that proposal as filed" in wiki. Mark all wiki pages which were
> marked as "deprecated" because of the failed proposal as "valid".
> 
> P.S. This only influences proposals which are CHANGING tagging.
> P.P.S. There should also be guards against such proposals in the first
> place, but lets park it for now.
> 


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