Re: [Talk-it-trentino] Segnalazione alcune cartografie Comune di Trento, mancata attribuzione.

[michele zanolli]

> Mi stai prendendo in giro?

Per quale motivo dovrei prenderti in giro?
Riporto semplicemente quello che c'è scritto e che conosco bene,
dal momento che provengo proprio dall'ufficio che si occupa di cartografia

> Scaricati le varie cartografie del primo link riguardo i rioni di Trento
> e confrontali con la zona su OSM, noterai moltissime uguaglianze, nonchè
> della webapp/mappa per smartphone al secondo link da cui probabilmente
> derivano i PDF.

Quello che scrivi non mi meraviglia, anzi! Ma per il motivo
esattamente opposto a quello che pensi.
Può voler dire che gli utenti OSM hanno preso i dati dal Comune di
Trento per arricchire la mappa della città, cosa assolutamente
consentita dalla (non) licenza attribuita ai dati geografici del
Comune (public domain, CC0). E questo mi farebbe davvero piacere,
quale promotore/sostenitore di OSM.

I dati del Comune risalgono ad una prima edizione della carta tecnica
numerica realizzata nel 2.000 e non mi risulta che a quei tempi OSM
avesse questo livello di dettaglio e, soprattutto, copertura uniforme
su Trento. Questo dovrebbe fugare ogni dubbio sul "chi ha copiato
chi".

Spero di aver chiarito.
ciao :)
michele

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

Re: [Talk-cz] RUIAN posun - konečné řešení?

[Marián Kyral]

Dne 27.12.2016 v 08:29 Marián Kyral napsal(a):
> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a):
>> @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
>> (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
>> pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
>> projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
>>
> Snažím se to napasovat na KM. Konkrétně na tuhle definici:
> 
>   
>   
>value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>   
>   
>   
> 
>
> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí.
>
> Marián

Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného:


To je OK, nebo to mám nějak změnit?

Marián

>> S pozdravem,
>> Petr Morávek aka Xificurk
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-cz] RUIAN posun - konečné řešení?

[Marián Kyral]

Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a):
> Dne 24.12.2016 v 00:04 Ha Noj napsal(a):
>>> 1) Dělám něco špatně já?
>> *** GRID je spočítán mezi ETRS89 a JTSK, takže by tam mělo být ještě
>> něco mezi ETRS89 a WGS84. Ale nepotěším tě, neboť to dělá jen cca 30 cm.
>>
>> echo "18.845223 49.547998" | cs2cs +init=epsg:4326 +to +init=epsg:4258
>> +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
>> "%.6f" | cs2cs +init=epsg:4258 +to +init=epsg:5514
>> +nadgrids=./jezek08_jtskcz.llb -f "%.3f"
>> -432758.771-1136759.330 -0.009
> Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84)
> pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl
> otevřít :-))
>
> Zajímalo by mne odkud pochází tvoje transformační parametry towgs84?
> Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě
> zdrojů narážel na doporučení považovat oba systémy za "shodné". A když
> se podívám na definici v /usr/share/proj/epsg tak tam je:
>
>> # ETRS89
>> <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs  <>
>
> Snažil jsem se dál empiricky dopátrat, jaké transformace provádí ČÚZK.
> Jako dataset jsem použil adresní místa - pro každou obec (>6000) jsem
> náhodně vybral jedno adresní místo (to by snad mělo zajistit
> reprezentativní vzorek).
> Z WFS jsem pak stáhl souřadnice v EPSG:4258 a EPSG:4326, na ně vyzkoušel
> různé transformace a výsledek porovnával s původními souřadnicemi v
> EPSG:5514 z WFS.
> A mám pocit, že čím víc se v tom rýpu, tím větší zmatek v tom mám :/
>
>
> 1) EPSG:4258 -> EPSG:5514 pomocí gridu, např.
> echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514
> +nadgrids=czech -f "%.3f"
> -576504.892 -1168238.275 -0.000
> Výsledná odchylka na souboru adresních bodů:
> 4 +/- 2 cm (max. 15 cm)
> HURÁ! Zdá se, že grid skutečně funguje skvěle a souhlasí s tím, co
> posílá ČÚZK.
>
>
> 2) EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace, např.
> echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514
> +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
> -576504.701 -1168238.186 -44.382
> Výsledná odchylka na souboru adresních bodů:
> 16 +/- 11 cm (max. 82 cm)
> Podle očekávání dává sedmiprvková transformace horší výsledky.
>
>
> 3) EPSG:4326 -> EPSG:5514 pomocí gridu, např.
> echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514
> +nadgrids=czech -f "%.3f"
> -576505.338 -1168238.341 0.000
> Výsledná odchylka na souboru adresních bodů:
> 18 +/- 16 cm (max. 116 cm)
> Tohle je to, co používám teď na import administrativních hranic (AFAIK
> to samé je na poloha.net) a řeším, proč se ta čísla v některých
> případech rozcházejí o více jak metr.
>
>
> 4) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí gridu, např.
> echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258
> +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
> "%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=czech -f "%.3f"
> -576505.114 -1168238.150 -0.009
> Výsledná odchylka na souboru adresních bodů:
> 31 +/- 10 cm (max. 86 cm)
> Nápad s přidáním transformace WGS84<->ETRS89 sice stáhnul maximální
> chybu o těch 30 cm, na druhou stranu průměrná chyba šla nahoru, takže
> tohle asi taky nebude správná cesta (?)
>
>
> 5) EPSG:4326 -> EPSG:5514 pomocí sedmiprvkové transformace, např.
> echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514
> +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
> -576505.148 -1168238.251 -44.382
> Výsledná odchylka na souboru adresních bodů:
> 14 +/- 7 cm (max. 36 cm)
> Tohle je další překvapení - tahle cesta nejlépe reprodukuje transformaci
> ČÚZK přestože víme, že rozhodně není nejpřesnější.
>
>
> 6) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace,
> např.
> echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258
> +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
> "%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514
> +towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
> -576504.923 -1168238.061 -44.391
> Výsledná odchylka na souboru adresních bodů:
> 24 +/- 9 cm (max. 49 cm)
> Tohle už uvádím jen pro úplnost.
>
>
>
> Abych pravdu řekl, tak vůbec netuším, jaký z toho všeho udělat závěr.
> Vypadá to, že grid, co jsme používali doteď, stále "funguje" správně. A
> naopak jsou to data ČÚZK v EPSG:4326, kterým se nedá moc věřit.
>
> @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
> (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
> pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
> projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.
>

Snažím se to napasovat na KM. Konkrétně na tuhle definici:

  
  
  
  
  
  


Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí.

Marián

> S pozdravem,
> Petr Morávek aka Xificurk
>
> 

[Talk-lt] Segmentuotas upelis

[Rimas Kudelis]

Sveiki,

visų pirma, su šventėmis visus!

Visų antra, noriu paklausti: Vilniuje, per Baltupių mikrorajoną teka
nedidelis upelis, pavadintas Cedronu. Per jį yra padaryta keletas
tiltukų,  o poroje vietų jis teka vamzdžiais, o ne žemės paviršiumi. Be
to, daugmaž ties viduriu jis yra užtvenktas ir taip suformuotas Cedrono
tvenkinys.

Šiuo metu tas upelis OSM žemėlapyje yra suskaidytas į devynis atskirus
fragmentus (nepriklausomus objektus), plius kaip atskiras objektas
pažymėtas tvenkinys. Noriu paklausti, ar tikrai taip ir turi būti? Ar
neturėtų pats upelis būti vientisas? Jei turėtų, gal kas nors galėtų
situaciją pataisyti? Aš pats turiu per mažai patirties OSM redagavime, o
iD redaktorius taip paprastai objektų sujungti neleidžia, tad nenoriu
beeksperimentuodamas ko nors pridirbti.

Beje, tvenkinys žemėlapyje yra įvardintas kaip „Cedrono tv.“. Ar tikrai
pačiuose pirminiuose duomenyse reikia rašyti santrumpą?

Rimas




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

Re: [Talk-br] Alturas, mapas3D do OSM

[Pedro vida torta]

Os dados vem do site geosampa , são o resultado das plantas dos imoveis
fotos aéreas e fotos em 3 D recolhidas pela prefeitura no final da década
de noventa , por veículos equipados com  varias câmeras tipo SV.  No site
tem de tudo canos, fiação, esgotos, pontos de ônibus, numeração de porta
etc , são exportados para o OSM por um mapeador de são Paulo

Em 26/12/2016 20:13, "Lucas Ferreira Mation" 
escreveu:

> Pessoal,
>
> em primeiro lugar um feliz natal.
>
> Alguém sabe de onde vem os dados de planta dos prédios e altura que são
> usados para renderizar o mapa em 3D? Esta empresa (f4map) os calcula
> automaticamente de alguma forma (análise de sombras de imagens aérias) ou
> estes dados já estão no OSM?
>
> Fiquei muito surpreso de ver o quão completo isso está para São Paulo
> São Paulo
> http://demo.f4map.com/#lat=-23.5522503=-46.6761298=16
>
> Já para Brasília, os prédios das superquadras parecem mais baixos do que
> realmetne são
>
> http://demo.f4map.com/#lat=-15.8045536=-47.8923768=17
>
> Enfim, apenas queria saber se de fato estes dados estão no OSM, e como são
> inseridos
>
> feliz 2017
> Lucas
>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[OSM-talk] Fwd: Re: Beware Pokemon users

[Rod Bera]

 Forwarded Message 
Subject: Re: [OSM-talk] Beware Pokemon users
Date: Tue, 27 Dec 2016 00:40:18 +0100
From: Rod Bera 
To: Andy Mabbett 

Hi Andy,

I get what you mean,

and I acknowledge that though I consider OSM should be put first this is
not the case for everyone, and this is fine.

But here things are going one step further: it's about deliberately
putting non-existing features and/or mis-tagging features, which amounts
to vandalism.
A new kind of vandalism, as we could be overwhelmed by the number of
"users" doing it in various places for a coinciding purpose.
To me this is quite new.

I hope this won't happen.

And I won't comment your appreciation over "geographical practices".
Every one is welcome to practice geography their own way...
As long as we are talking about geography, i.e. depicting what is
(really is, not what Pokemon hunter wish were) on or around the surface
of Earth.

Regards,

Rod

On 26/12/16 13:19, Andy Mabbett wrote:
> On 26 December 2016 at 11:36, Rod Bera  wrote:
> 
>> Systematic bias put into the OSM base towards maximising benefits for a
>> minority of users is a threat.
>> Especially when the primary interest of these users is not OSM in itself.
> 
> Most edits to OSM benefit only a minority of users
> 
> Most editors of OSM - including me - do so because we have a primary
> interest which is not OSM itself.
> 
> Shall those of us who edit OSM because we have an interest in a
> locality, or a use-case, all stop editing, and leave OSM only to those
> for whom it is some form of geographical masturbation?
> 


-- 
Rod Béra,  MCF Géomatique/   Lecturer, Geomatics
   et SIG pour l'Environnement  /and Environmental GIS
Agrocampus-Ouest|65 r.Saint-Brieuc|CS84215|35042 Rennes cedex|France
+33 (0) 223 48 5553 - roderic.b...@agrocampus-ouest.fr

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

Re: [Talk-cz] RUIAN posun - konečné řešení?

[Petr Morávek [Xificurk]]

Dne 24.12.2016 v 00:04 Ha Noj napsal(a):
>> 1) Dělám něco špatně já?
> *** GRID je spočítán mezi ETRS89 a JTSK, takže by tam mělo být ještě
> něco mezi ETRS89 a WGS84. Ale nepotěším tě, neboť to dělá jen cca 30 cm.
> 
> echo "18.845223 49.547998" | cs2cs +init=epsg:4326 +to +init=epsg:4258
> +towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
> "%.6f" | cs2cs +init=epsg:4258 +to +init=epsg:5514
> +nadgrids=./jezek08_jtskcz.llb -f "%.3f"
> -432758.771-1136759.330 -0.009

Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84)
pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl
otevřít :-))

Zajímalo by mne odkud pochází tvoje transformační parametry towgs84?
Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě
zdrojů narážel na doporučení považovat oba systémy za "shodné". A když
se podívám na definici v /usr/share/proj/epsg tak tam je:

> # ETRS89
> <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs  <>


Snažil jsem se dál empiricky dopátrat, jaké transformace provádí ČÚZK.
Jako dataset jsem použil adresní místa - pro každou obec (>6000) jsem
náhodně vybral jedno adresní místo (to by snad mělo zajistit
reprezentativní vzorek).
Z WFS jsem pak stáhl souřadnice v EPSG:4258 a EPSG:4326, na ně vyzkoušel
různé transformace a výsledek porovnával s původními souřadnicemi v
EPSG:5514 z WFS.
A mám pocit, že čím víc se v tom rýpu, tím větší zmatek v tom mám :/


1) EPSG:4258 -> EPSG:5514 pomocí gridu, např.
echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514
+nadgrids=czech -f "%.3f"
-576504.892 -1168238.275 -0.000
Výsledná odchylka na souboru adresních bodů:
4 +/- 2 cm (max. 15 cm)
HURÁ! Zdá se, že grid skutečně funguje skvěle a souhlasí s tím, co
posílá ČÚZK.


2) EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace, např.
echo "16.914199 49.148716" | cs2cs +init=epsg:4258 +to +init=epsg:5514
+towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
-576504.701 -1168238.186 -44.382
Výsledná odchylka na souboru adresních bodů:
16 +/- 11 cm (max. 82 cm)
Podle očekávání dává sedmiprvková transformace horší výsledky.


3) EPSG:4326 -> EPSG:5514 pomocí gridu, např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514
+nadgrids=czech -f "%.3f"
-576505.338 -1168238.341 0.000
Výsledná odchylka na souboru adresních bodů:
18 +/- 16 cm (max. 116 cm)
Tohle je to, co používám teď na import administrativních hranic (AFAIK
to samé je na poloha.net) a řeším, proč se ta čísla v některých
případech rozcházejí o více jak metr.


4) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí gridu, např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258
+towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
"%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514 +nadgrids=czech -f "%.3f"
-576505.114 -1168238.150 -0.009
Výsledná odchylka na souboru adresních bodů:
31 +/- 10 cm (max. 86 cm)
Nápad s přidáním transformace WGS84<->ETRS89 sice stáhnul maximální
chybu o těch 30 cm, na druhou stranu průměrná chyba šla nahoru, takže
tohle asi taky nebude správná cesta (?)


5) EPSG:4326 -> EPSG:5514 pomocí sedmiprvkové transformace, např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:5514
+towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
-576505.148 -1168238.251 -44.382
Výsledná odchylka na souboru adresních bodů:
14 +/- 7 cm (max. 36 cm)
Tohle je další překvapení - tahle cesta nejlépe reprodukuje transformaci
ČÚZK přestože víme, že rozhodně není nejpřesnější.


6) EPSG:4326 -> EPSG:4258 -> EPSG:5514 pomocí sedmiprvkové transformace,
např.
echo "16.914193 49.148715" | cs2cs +init=epsg:4326 +to +init=epsg:4258
+towgs84="0.0473,0.0467,-0.0253,0.000891,0.00539,-0.008772,-0.00158" -f
"%.8f" | cs2cs +init=epsg:4258 +to +init=epsg:5514
+towgs84="570.8,85.7,462.8,4.998,1.587,5.261,3.56" -f "%.3f"
-576504.923 -1168238.061 -44.391
Výsledná odchylka na souboru adresních bodů:
24 +/- 9 cm (max. 49 cm)
Tohle už uvádím jen pro úplnost.



Abych pravdu řekl, tak vůbec netuším, jaký z toho všeho udělat závěr.
Vypadá to, že grid, co jsme používali doteď, stále "funguje" správně. A
naopak jsou to data ČÚZK v EPSG:4326, kterým se nedá moc věřit.

@Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
(hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.


S pozdravem,
Petr Morávek aka Xificurk

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

Re: [Talk-br] Alturas, mapas3D do OSM

[Lucas Pereira]

Olá Lucas.

Quando o mapeador especifica a altura (height
) ou a quantidade de andares (
building:levels )
de um edifício, o F4map interpreta estes dados e renderiza os edifícios
assim.

Caso ele não encontre estas informações no banco de dados, adota valores
arbitrários padrões para renderizar todos os edifícios, adotando uma
pequena variação entre um edifício e outro próximo, por questões estéticas.

Veja um exemplo em São Paulo, por exemplo, onde os edifícios foram
importados de um arquivo disponibilizado pela Prefeitura Municipal:
http://www.openstreetmap.org/way/421344674

Em Brasília estas informações não foram inseridas em diversos edifícios,
acredito que apenas nos principais edifícios do Governo ou alguns outros.

Att,
LucFreitas.

Em 26 de dezembro de 2016 20:12, Lucas Ferreira Mation <
lucasmat...@gmail.com> escreveu:

> Pessoal,
>
> em primeiro lugar um feliz natal.
>
> Alguém sabe de onde vem os dados de planta dos prédios e altura que são
> usados para renderizar o mapa em 3D? Esta empresa (f4map) os calcula
> automaticamente de alguma forma (análise de sombras de imagens aérias) ou
> estes dados já estão no OSM?
>
> Fiquei muito surpreso de ver o quão completo isso está para São Paulo
> São Paulo
> http://demo.f4map.com/#lat=-23.5522503=-46.6761298=16
>
> Já para Brasília, os prédios das superquadras parecem mais baixos do que
> realmetne são
>
> http://demo.f4map.com/#lat=-15.8045536=-47.8923768=17
>
> Enfim, apenas queria saber se de fato estes dados estão no OSM, e como são
> inseridos
>
> feliz 2017
> Lucas
>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Alturas, mapas3D do OSM

[Lucas Ferreira Mation]

Pessoal,

em primeiro lugar um feliz natal.

Alguém sabe de onde vem os dados de planta dos prédios e altura que são
usados para renderizar o mapa em 3D? Esta empresa (f4map) os calcula
automaticamente de alguma forma (análise de sombras de imagens aérias) ou
estes dados já estão no OSM?

Fiquei muito surpreso de ver o quão completo isso está para São Paulo
São Paulo
http://demo.f4map.com/#lat=-23.5522503=-46.6761298=16

Já para Brasília, os prédios das superquadras parecem mais baixos do que
realmetne são

http://demo.f4map.com/#lat=-15.8045536=-47.8923768=17

Enfim, apenas queria saber se de fato estes dados estão no OSM, e como são
inseridos

feliz 2017
Lucas
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-at] Peter Paul

[Martin Raifer]

Zu:

> Da der Name Handleinsberg [historisch] belegbar ist werde ich diesen auf der 
> Karte eintragen.

sagst du:

> Finde ich gut.

was ich nicht ganz nachvollziehen kann: Nur weil ein Name vor ca 200
Jahren möglicherweise gebräuchlich war, sollte man diesen nicht
zwingenderweise heute in OSM eintragen, oder?

Oder habe ich dich hier falsch verstanden/zitiert?

Martin


2016-12-26 18:50 GMT+01:00 ScubbX :
> Wie meinst du "wieso"? Ich meine das nur als Beobachtung?
>
>
>
> Am 2016-12-26 um 09:47 schrieb Martin Raifer:
>>
>> Wieso? Dieser historische Name scheint ja aktuell nicht mehr in
>> Verwendung zu sein?
>>
>>
>> 2016-12-24 18:55 GMT+01:00 ScubbX :
>>>
>>> Finde ich gut.
>>>
>>> Im historischen Orts- und Riednamenverzeichnis vom BEV findet sich an
>>> dieser
>>> Stelle gar keine Bezeichnung.
>>>
>>>
>>> Am 2016-12-24 um 17:42 schrieb Liberaler Humanist:
>>>
>>> Auf einer Reproduktion des Franziszeischen Katasters findet sich etwas
>>> unterhalb der Name "Handleinsberg" ( Vgl.:
>>> https://www.wien.gv.at/kultur/kulturgut/plaene/franziszeisch.html - Man
>>> muss
>>> heranzoomen). Warum sich der Name nicht mehr in späteren Karten findet
>>> ist
>>> nicht ersichtlich, da der Gipfel wie am Commons-Foto ersichtlich als
>>> solcher
>>> klar erkennbar ist und auch auf einer topografischen Karte eine
>>> entsprechende Prominenz zeigt (
>>> https://opentopomap.org/#map=17/48.27224/16.31161 ). Da der Name
>>> Handleinsberg belegbar ist werde ich diesen auf der Karte eintragen.
>>>
>>> MfG, LH
>>>
 Von: realadry 
 Datum: 24.12.2016 2:20 nachm.
 Betreff: Re: [Talk-at] Peter Paul
 An: OpenStreetMap AT 
 Cc:

> Hallo,
>
> Ich habe ein bisschen in online verfügbaren historischen Karten
> recherchiert und laut dieser Karte [1] von ca. 1941-1945, ist an dieser
> Stelle ein Gipfel markiert mit der Bezeichnung "Schwaben-Ws. 482".
> Ein Vergleich der Höhenlinien mit dem von Friedrich Volkmann geposteten
> screenshot [2], legt nahe, dass es sie hier um den selben Gipfel
> handelt. Die unterschiedliche Höhe (482 vs. 495) liegt vermutlich an
> damalig ungenauen Messmethoden bzw. Veränderung der Landschaft in der
> Zwischenzeit.
> Die Bezeichnung "Peter Paul" hingegen findet sich in keinem Dokument,
> weder historisch noch aktuell. Nur weil jemand diesen Namen auf OSM
> einträgt und sich dadurch verbreitet, macht es ihn noch lange nicht zum
> offiziellen oder gebräulichen Namen.
>
> Weiters: Das erste mal wurde der Gipfel in OSM auf "Peter Paul" benannt
> am 28.Juli 2012 [3]. Das Panoramio Bild wurde aber erst danach, am
> 10.August 2012, hochgeladen. Es ist also naheliegend, dass der Name des
> Gipfels auf dem Bild falsch aus OSM übernommen wurde.
>
> Ich hoffe das sind genug Beweise um zu zeigen, dass dieser Gipfel nicht
> "Peter Paul" heißt, auch wenn es jemand gerne so hätte. ;)
>
>
>
> [1]https://www.wien.gv.at/actaproweb2/benutzung/image.xhtml?id=kfGyc/iEt7fL65LzraHfwuM0+8OkdD4Jp25sfgC2ACs1
>
> [2]http://www.steige.info/austausch/screenshot_pp.png
>
> [3]http://www.openstreetmap.org/changeset/12521352
>
> Am 23.12.2016 um 18:50 schrieb grubernd:
>>>
>>> http://www.openstreetmap.org/note/510342
>>
>> endlich wieder einmal ein Henne-Ei-Problem.
>>
>> Meinung: war unbenannt, also ist eine Namensgebung absolut legitim, da
>> keinerlei Datenvandalismus vorliegt. mittlerweile finden sich einige
>> Hinweise [1][2], dass der Berg auch von anderen so genannt wird, also
>> wurde der Name angenommen. irgendwann ist es egal was einmal die Henne
>> und was das Ei war.
>>
>> ohne Worte für Dinge können wir nicht über diese Dinge reden, denken
>> und
>> uns austauschen. irgendjemand muss den ersten Schritt tun. unbenannte
>> Dinge nach dem Entdecker zu benennen ist ja durchaus eine grosse und
>> anerkannte Tradition in der Kartographie.
>>
>> grüsse,
>> grubernd
>>
>> [1] http://www.panoramio.com/photo/76813516
>> [2]
>>
>>
>> http://www.gipfeltreffen.at/showthread.php?82202-Peter-Paul-Berg-494m-Wienerwald-(5620)/page2
>>>
>>>
>>>
>>> ___
>>> Talk-at mailing list
>>> Talk-at@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-at
>>>
>>>
>>>
>>> ___
>>> Talk-at mailing list
>>> Talk-at@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-at
>>>
>> ___
>> Talk-at mailing list
>> Talk-at@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-at
>
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-us] Relation roles: Clockwise and Counterclockwise route directions? (e.g. Pittsburgh's Belts)

[Tod Fitch]

Not sure about the beltway example, but I prefer having one relation for each 
direction of a highway and then a super relation to tie those two together. 
That avoids the issues you pointed out earlier where one direction may take a 
slip/link while the other direction does not. It also makes it easy to see, at 
least in JOSM relation editing, that all the segments link up properly. And 
finally, though probably not as important, allows one to mark each segment in 
the relation with “forward” which is universally understood by the whole tool 
chain while many have issues with members marked as “north”, “south”, etc.

I suppose one could handle the beltway example with a CW relation and a CCW 
relation, with all members being tagged as “forward”, and then a super relation 
to tie those to together. Signage with stuff like north/south on them could be 
handled with destination sign tagging.


> On Dec 26, 2016, at 1:41 PM, Albert Pundt  wrote:
> 
> I know that north/south/east/west directions are preferred for relation roles 
> of one-way route segments (e.g. one-way pairs or divided highways), but what 
> about clockwise and counterclockwise? Often beltways, like D.C.'s Capital 
> Beltway, are signed such that they abruptly go from north/south to east/west, 
> but then you have routes like Pittsburgh's Belt System, where the Belts 
> aren't signed with directions at all. These seem to be given "CW" (clockwise) 
> and "CCW" (counterclockwise) roles. Is this correct, or does "forward" or 
> some other role need to be used?



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

[Talk-us] Relation roles: Clockwise and Counterclockwise route directions? (e.g. Pittsburgh's Belts)

[Albert Pundt]

I know that north/south/east/west directions are preferred for relation roles 
of one-way route segments (e.g. one-way pairs or divided highways), but what 
about clockwise and counterclockwise? Often beltways, like D.C.'s Capital 
Beltway, are signed such that they abruptly go from north/south to east/west, 
but then you have routes like Pittsburgh's Belt System, where the Belts aren't 
signed with directions at all. These seem to be given "CW" (clockwise) and 
"CCW" (counterclockwise) roles. Is this correct, or does "forward" or some 
other role need to be used?
--Roadsguy___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Overpass API from JOSM does not honor bounding box anymore?

[Maarten Deen]

Hi Pierre,

On 2016-12-26 17:36, Pierre Béland wrote:


When you click on Build a query, you wil see that the bbox definition
looks like this.

[out:xml][timeout:25][bbox:{{bbox}}];


That works better. When I put that in front of the query (I don't 
"build" the query, I have my own), then downloading works.


Regards,
Maarten



-
 DE : Maarten Deen 
À : talk@openstreetmap.org; j...@openstreetmap.org
ENVOYÉ LE : lundi 26 décembre 2016 10h14
OBJET : [OSM-talk] Overpass API from JOSM does not honor bounding box
anymore?

I'm trying the overpass API from JOSM and keep getting timeouts.
According to the docs, the bounding box for the Overpass query would
be
set automatically when selecting an area in the map in the download
screen, but I do not see that in the resulting query that gets logged.

Trying the example query from the wiki give me this error (afer a few
minutes):
2016-12-26 16:02:59.165 SEVERE: IO Exception - Failed to upload
data to or download data
from'https://overpass-api.de/api/interpreter?data=%28+node%5Bshop%5D%3B%0Away%5Bshop%5D%3B%3E%3B%0Arel%5Bshop%5D%3B%3E%3B%29%3B%0A%28._%3Brel%28bn%29%3B%29%3B%0A%28._%3Brel%28bw%29%3B%29%3B%0A%28._%3Brel%28br%29%3B%29%3B%0Aout+meta%3B'
[1]due
to a problem with transferring data.Details (untranslated): Read
timed out

I do not see a bounding box in there.

If I download without a query there is a proper bbox in the API GET.

Is there something I should do to get the query to take the bbox?

Regards,
Maarten

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



Links:
--
[1]
https://overpass-api.de/api/interpreter?data=%28+node%5Bshop%5D%3B%0Away%5Bshop%5D%3B%3E%3B%0Arel%5Bshop%5D%3B%3E%3B%29%3B%0A%28._%3Brel%28bn%29%3B%29%3B%0A%28._%3Brel%28bw%29%3B%29%3B%0A%28._%3Brel%28br%29%3B%29%3B%0Aout+meta%3B%27


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

Re: [OSM-talk-be] Lightmap

[Glenn Plas]

On 26-12-16 14:12, Philippe Casteleyn wrote:
> 
> 
> Het is nuttiger die tag in te vullen bij fietsstallingen en fietspaden.
>  Aan de kathedraal in Mechelen bijvoorbeeld is er een fietsstalling waar
> je op de tast uw sleutel in uw fietsslot moet steken.
> En dan vergeet ik nog de zebrapaden, allemaal nuttige dingen.

Het zou leuk zijn dat die dan ook werkelijk branden, en dat doen ze niet
altijd hier, sinds een paar jaar worden er 's nachts, voornamelijk op
snelwegen de lichten uitgedaan behalve aan op/afritten.

Dus lit=yes wil niet zeggen dat ze branden wanneer je het verwacht.  In
die zin vind ik lit niet zo een bruikbare tag.  Tijdsindicaties erbij
zou al heel wat goed maken en/of concepten zoals schemerschakeling etc.

Glenn


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


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

Re: [OSM-talk-be] Lightmap

[Marc Gemis]

Als ik 's avonds met de honden ga wandelen, dan loop ik toch liever
over verlichte paden. Dus ik vind dat wel leuk om te weten.

Het maakt me niet uit, wat de mensen mappen, als ze maar mappen :-)
Vandaar dat ik af en toe ideetjes lanceer..

m.

2016-12-26 14:12 GMT+01:00 Philippe Casteleyn :
>
>
> Het is nuttiger die tag in te vullen bij fietsstallingen en fietspaden.  Aan
> de kathedraal in Mechelen bijvoorbeeld is er een fietsstalling waar je op de
> tast uw sleutel in uw fietsslot moet steken.
> En dan vergeet ik nog de zebrapaden, allemaal nuttige dingen.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-fr] Osmose "Possible missing traffic_signals:direction or crossing "

[Frédéric Rodrigo]

C'est une analyse qui tente de trouver des passages ou des feux manquants.

Le 26 déc. 2016 19:03, "lenny.libre"  a écrit :

>
> Le 26/12/2016 à 14:25, Thomas Ruchin a écrit :
>
> Bonjour
>
> Au vu du marquage au sol visible depuis Bing, cela ressemble un rond-point
> plutôt qu'à un carrefour giratoire. Que dit la signalisation verticale
> présente sur place ?
> Si cela est bien confirmé, il faut remplacer le junction=roundabout par un
> oneway=yes
> Pour l’anecdote, les carrefours giratoires n'existent pas à Paris
> intramuros, de même que les stop
>
> T. Ruchin
>
> Peut-être dans ce cas particulier, mais j'ai vu d'autres cas de carrefours
> avec le panneau AB25 à chaque entrée de véhicules et qui ont les feux (par
> exemple au niveau d'une voie de tram).
>
> Pourquoi Osmose a signalé une erreur parce qu'il ne détecte pas le
> "oneway" implicite dans le "junction=roundabout"  ou  parce qu'il a trouvé
> des "crossing" à proximité ?
>
> léni
>
> Le 26 décembre 2016 à 11:40, lenny.libre  a écrit :
>
>> Bonjour :
>>
>> Osmose détecte signale sur des feux situés à l'intérieur d'un carrefour
>> giratoire.
>> *Possible missing traffic_signals:direction or crossing*
>> *node 2040084377 *
>> + *traffic_signals:direction* = forward
>> + *traffic_signals:direction* = backward
>> *highway* = traffic_signals
>>
>> - si je me réfère à la proposition d'osmose avec la direction, cela
>> voudrait dire qu'Osmose ne détecte pas que le
>> https://www.openstreetmap.org/way/22152292#map=19/43.59409/1.49617 a un
>> tag "junction=roundabout" et donc que le tag oneway=* est implicite, la
>> direction est donc elle aussi implicite ; ce serait donc une erreur que je
>> dois signaler à osmose !
>>
>> - si je me réfère à la description de l'erreur
>> https://wiki.openstreetmap.org/wiki/FR:Osmose/issues#2090
>> Détail : Un nœud très proche a déjà le tag crossing=traffic_signals ou le
>> tag crossing=traffic_signals a été utilisé sans tag highway=traffic_signals
>> à proximité.
>> : après vérification, je devrais indiquer "faux positif" et signaler à
>> osmose que la description de l'erreur n'est pas complète !
>>
>> A votre avis, dans quel cas suis-je ?
>>
>> Merci d'avance
>>
>> Léni
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Pubblicità in Google Maps

[Aury88]

girarsi_liste wrote
> Sembra un modo scaltro per produrre clic in più.

e per guadagnare soldi dalla pubblicità.
purtroppo è anche un processo che favorirà le grosse catene/marchi a
discapito dei più piccoli e meno pubblicizzati. una mappa quindi che, dando
un occhio di riguardo ai grossi business, deve necessariamente essere meno
attenta e puntuale con i pesci piccoli. per quanto l'aspetto economico sia
un aspetto importante non è l'unico e il favorirlo/risaltarlo,
necessariamente a discapito di altri, porta come conseguenza ad un
alterazione della rappresentazione della realtà che, fortunatamente, non è
solamente regolato dagli investimenti in pubblicità...sarà curioso vedere
come funziona per i clienti, cioè per i siti delle varie attività economiche
che ospitano una mappa Google...spero per loro sia lasciata la possibilità
di "oscurare" i simboli della concorrenza :-P
Per OSM non è necessariamente un bene...si continua a comparire su GMaps
gratuitamente, semplicemente si verrà rappresentati in una mappa in cui
alcuni marchi sono meno uguali di altri...purtroppo il peso che ha GMaps in
termini di utenti non consente di boicottarlo così a cuor leggero (i danni
del monpolio.), l'unica soluzione per i più piccoli è cercare di sfruttare
il più possibile le alternative che offre internet...un elemento che compare
su più mappe ottiene maggiori possibilità di venire trovato rispetto al
comparire, tra gli "anonimi" piccoli in mezzo ai grossi e distinguibili,
unicamente su una sola mappa.
 OSM non se la cava male in termini di utenti...o meglio OSM risulta essere
usata da alcune delle app più diffuse e siti più importanti, purtroppo però,
nonostante questo, continua a non essere famosa e questo comporta il fatto
che pochissimi segnalino la propria attività non perchè non ne trarrebbero
vantaggio/visibilità ma semplicemente perchè non sanno di avere questa
possibilità.



L'unica cosa che possiamo fare è continuare con il nostro lavoro di
mappatura, e cercando di essere il più precisi possibile nel farlo...Il
progetto continua ad estendersi, quasi ogni giorno c'è una novità per quanto
riguarda l'utilizzo dei dati OSM in altri progetti/app/siti/eventi e
contributori nuovi si aggiungono ogni giorno (alcuni di questi diventeranno
contributori "storici" ed esperti che sono di grandissimo valore per la
qualità della mappa)... di fatto ogni giorno c'è più gente che conosce osm 
e più possibilità di sentirne parlare o incappare in una delle sue
mappe;quindi non demoralizziamoci, stiamo andando bene e quest'ultima mossa
non sposta imho l'ago della bilancia .



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n8.nabble.com/Pubblicita-in-Google-Maps-tp5888128p5888190.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Osmose "Possible missing traffic_signals:direction or crossing "

[lenny.libre]

Le 26/12/2016 à 14:25, Thomas Ruchin a écrit :

Bonjour

Au vu du marquage au sol visible depuis Bing, cela ressemble un 
rond-point plutôt qu'à un carrefour giratoire. Que dit la 
signalisation verticale présente sur place ?
Si cela est bien confirmé, il faut remplacer le junction=roundabout 
par un oneway=yes
Pour l’anecdote, les carrefours giratoires n'existent pas à Paris 
intramuros, de même que les stop


T. Ruchin

Peut-être dans ce cas particulier, mais j'ai vu d'autres cas de 
carrefours avec le panneau AB25 à chaque entrée de véhicules et qui ont 
les feux (par exemple au niveau d'une voie de tram).


Pourquoi Osmose a signalé une erreur parce qu'il ne détecte pas le 
"oneway" implicite dans le "junction=roundabout"  ou  parce qu'il a 
trouvé des "crossing" à proximité ?


léni

Le 26 décembre 2016 à 11:40, lenny.libre > a écrit :


Bonjour :

Osmose détecte signale sur des feux situés à l'intérieur d'un
carrefour giratoire.

*Possible missing traffic_signals:direction or crossing*
*node 2040084377
*
+ *traffic_signals:direction* = forward
+ *traffic_signals:direction* = backward
*highway* = traffic_signals

- si je me réfère à la proposition d'osmose avec la direction,
cela voudrait dire qu'Osmose ne détecte pas que le
https://www.openstreetmap.org/way/22152292#map=19/43.59409/1.49617

a un tag "junction=roundabout" et donc que le tag oneway=* est
implicite, la direction est donc elle aussi implicite ; ce serait
donc une erreur que je dois signaler à osmose !

- si je me réfère à la description de l'erreur
https://wiki.openstreetmap.org/wiki/FR:Osmose/issues#2090

Détail : Un nœud très proche a déjà le tag
crossing=traffic_signals ou le tag crossing=traffic_signals a été
utilisé sans tag highway=traffic_signals à proximité.
: après vérification, je devrais indiquer "faux positif" et
signaler à osmose que la description de l'erreur n'est pas complète !

A votre avis, dans quel cas suis-je ?

Merci d'avance

Léni


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





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


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

Re: [Talk-at] Peter Paul

[ScubbX]

Wie meinst du "wieso"? Ich meine das nur als Beobachtung?


Am 2016-12-26 um 09:47 schrieb Martin Raifer:

Wieso? Dieser historische Name scheint ja aktuell nicht mehr in
Verwendung zu sein?


2016-12-24 18:55 GMT+01:00 ScubbX :

Finde ich gut.

Im historischen Orts- und Riednamenverzeichnis vom BEV findet sich an dieser
Stelle gar keine Bezeichnung.


Am 2016-12-24 um 17:42 schrieb Liberaler Humanist:

Auf einer Reproduktion des Franziszeischen Katasters findet sich etwas
unterhalb der Name "Handleinsberg" ( Vgl.:
https://www.wien.gv.at/kultur/kulturgut/plaene/franziszeisch.html - Man muss
heranzoomen). Warum sich der Name nicht mehr in späteren Karten findet ist
nicht ersichtlich, da der Gipfel wie am Commons-Foto ersichtlich als solcher
klar erkennbar ist und auch auf einer topografischen Karte eine
entsprechende Prominenz zeigt (
https://opentopomap.org/#map=17/48.27224/16.31161 ). Da der Name
Handleinsberg belegbar ist werde ich diesen auf der Karte eintragen.

MfG, LH


Von: realadry 
Datum: 24.12.2016 2:20 nachm.
Betreff: Re: [Talk-at] Peter Paul
An: OpenStreetMap AT 
Cc:


Hallo,

Ich habe ein bisschen in online verfügbaren historischen Karten
recherchiert und laut dieser Karte [1] von ca. 1941-1945, ist an dieser
Stelle ein Gipfel markiert mit der Bezeichnung "Schwaben-Ws. 482".
Ein Vergleich der Höhenlinien mit dem von Friedrich Volkmann geposteten
screenshot [2], legt nahe, dass es sie hier um den selben Gipfel
handelt. Die unterschiedliche Höhe (482 vs. 495) liegt vermutlich an
damalig ungenauen Messmethoden bzw. Veränderung der Landschaft in der
Zwischenzeit.
Die Bezeichnung "Peter Paul" hingegen findet sich in keinem Dokument,
weder historisch noch aktuell. Nur weil jemand diesen Namen auf OSM
einträgt und sich dadurch verbreitet, macht es ihn noch lange nicht zum
offiziellen oder gebräulichen Namen.

Weiters: Das erste mal wurde der Gipfel in OSM auf "Peter Paul" benannt
am 28.Juli 2012 [3]. Das Panoramio Bild wurde aber erst danach, am
10.August 2012, hochgeladen. Es ist also naheliegend, dass der Name des
Gipfels auf dem Bild falsch aus OSM übernommen wurde.

Ich hoffe das sind genug Beweise um zu zeigen, dass dieser Gipfel nicht
"Peter Paul" heißt, auch wenn es jemand gerne so hätte. ;)


[1]https://www.wien.gv.at/actaproweb2/benutzung/image.xhtml?id=kfGyc/iEt7fL65LzraHfwuM0+8OkdD4Jp25sfgC2ACs1

[2]http://www.steige.info/austausch/screenshot_pp.png

[3]http://www.openstreetmap.org/changeset/12521352

Am 23.12.2016 um 18:50 schrieb grubernd:

http://www.openstreetmap.org/note/510342

endlich wieder einmal ein Henne-Ei-Problem.

Meinung: war unbenannt, also ist eine Namensgebung absolut legitim, da
keinerlei Datenvandalismus vorliegt. mittlerweile finden sich einige
Hinweise [1][2], dass der Berg auch von anderen so genannt wird, also
wurde der Name angenommen. irgendwann ist es egal was einmal die Henne
und was das Ei war.

ohne Worte für Dinge können wir nicht über diese Dinge reden, denken
und
uns austauschen. irgendjemand muss den ersten Schritt tun. unbenannte
Dinge nach dem Entdecker zu benennen ist ja durchaus eine grosse und
anerkannte Tradition in der Kartographie.

grüsse,
grubernd

[1] http://www.panoramio.com/photo/76813516
[2]

http://www.gipfeltreffen.at/showthread.php?82202-Peter-Paul-Berg-494m-Wienerwald-(5620)/page2



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



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


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



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

[Talk-us] Relation roles for two-way way segments carrying routes in a single direction

[Albert Pundt]

So I understand that one-way ways carrying a route (e.g. a one-way pair or 
divided highway) should have relation roles of north/south/east/west, but say 
you have a situation like this. Say you have an east-west route that follows 
the primary roads in that picture. The eastbound direction follows the 
channelized right turn slip ramp, marked with a red arrow. The westbound 
direction follows the blue-arrow way, before turning left onto the green-arrow 
way.
How should relation memberships and roles be assigned here? I would think that 
the slip ramp would be part of the relation, since right-turning traffic must 
follow it. Ideally, that would be given the role "east", but what about the 
green and blue ways? It might seem right to give them the role "west", but how 
then is it differentiated which direction is westbound for it? Since all the 
ways in this picture are arranged "pointing" north or east, the green and blue 
ways would need to be given the role "backward", which is the older way of 
doing things that can't specify cardinal direction. Is replacing the single 
relation with separate relations for each direction the only good way to do 
this, or are such two-way segments the only times that "forward" and "backward" 
roles should be used?
I checked the wiki page, but it doesn't seem to specify. Instead, it just says 
such cases are very rare (which is only true relatively speaking, as routes 
very commonly turn at intersections with channelized right turns, making 
situations like the linked example very common.
--Roadsguy___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Parco Nazionale dell'Appennino Lucano

[Federico Cortese]

2016-12-26 13:03 GMT+01:00 Giuseppe Cillis :
> Ciao Federico,
> l'utente non più attivo sono io ma solo per motivi personali e nulla più.
> Il dataset è quello ufficiale della Regione Basilicata con licenza libera di
> utilizzo.
> Come mai è da eliminare?

Ciao Giuseppe,
scusa se non mi sono espresso bene, io non credo sia da eliminare,
proprio per questo ho segnalato che buona parte del perimetro
(https://www.openstreetmap.org/way/422060222) è stata eliminata da
mauromauromauro (https://www.openstreetmap.org/user/mauromauromauro).
Non so se segue la lista, ma è un utente che contribuisce con buona
volontà, aggiungendo strade di campagna, sentieri e simili, ma che
andrebbe supportato.
Purtroppo io ho già tanto da fare nel sud Puglia, non riesco ad
approfondire molto in quelle zone.
Se puoi contattalo tu e vedi se si è trattato di cancellatura eseguita
per errore o se c'è qualche motivo, ed eventualmente si recupera la
way con undelete e si inserisce nuovamente nella relazione del parco
che attualmente è rimasta aperta.

Ciao
Federico

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

Re: [OSM-talk] Overpass API from JOSM does not honor bounding box anymore?

[Pierre Béland]

Hi Marteen
There were discussions recently on this subject  but I cant find the thread. 
This was probably on the Overpass discussion group.

As for the general Overpass API, It is now possible through JOSM to either use 
bbox or other outbounding methods to define the area to query. To implement 
this in JOSM, the syntax for bbox has been slightly modified with the 
[bbox:{{bbox}}] added to the header section of the query.
Try building a query with a key value, for example : "building"="yes"
When you click on Build a query, you wil see that the bbox definition looks 
like this.
[out:xml][timeout:25][bbox:{{bbox}}];
If you still have timeout problem using the syntax above, it migth be related 
to the size of the area to query. Then, select a smaller bbox or increase the 
timeout value.
 
Pierre 


  De : Maarten Deen 
 À : talk@openstreetmap.org; j...@openstreetmap.org 
 Envoyé le : lundi 26 décembre 2016 10h14
 Objet : [OSM-talk] Overpass API from JOSM does not honor bounding box anymore?
   
I'm trying the overpass API from JOSM and keep getting timeouts. 
According to the docs, the bounding box for the Overpass query would be 
set automatically when selecting an area in the map in the download 
screen, but I do not see that in the resulting query that gets logged.

Trying the example query from the wiki give me this error (afer a few 
minutes):
2016-12-26 16:02:59.165 SEVERE: IO Exception - Failed to upload 
data to or download data 
from'https://overpass-api.de/api/interpreter?data=%28+node%5Bshop%5D%3B%0Away%5Bshop%5D%3B%3E%3B%0Arel%5Bshop%5D%3B%3E%3B%29%3B%0A%28._%3Brel%28bn%29%3B%29%3B%0A%28._%3Brel%28bw%29%3B%29%3B%0A%28._%3Brel%28br%29%3B%29%3B%0Aout+meta%3B'due
 
to a problem with transferring data.Details (untranslated): Read 
timed out

I do not see a bounding box in there.

If I download without a query there is a proper bbox in the API GET.

Is there something I should do to get the query to take the bbox?

Regards,
Maarten

___
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] Overpass API from JOSM does not honor bounding box anymore?

[Maarten Deen]

I'm trying the overpass API from JOSM and keep getting timeouts. 
According to the docs, the bounding box for the Overpass query would be 
set automatically when selecting an area in the map in the download 
screen, but I do not see that in the resulting query that gets logged.


Trying the example query from the wiki give me this error (afer a few 
minutes):
2016-12-26 16:02:59.165 SEVERE: IO Exception - Failed to upload 
data to or download data 
from'https://overpass-api.de/api/interpreter?data=%28+node%5Bshop%5D%3B%0Away%5Bshop%5D%3B%3E%3B%0Arel%5Bshop%5D%3B%3E%3B%29%3B%0A%28._%3Brel%28bn%29%3B%29%3B%0A%28._%3Brel%28bw%29%3B%29%3B%0A%28._%3Brel%28br%29%3B%29%3B%0Aout+meta%3B'due 
to a problem with transferring data.Details (untranslated): Read 
timed out


I do not see a bounding box in there.

If I download without a query there is a proper bbox in the API GET.

Is there something I should do to get the query to take the bbox?

Regards,
Maarten

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

[OSM-talk-fr] Freshmile

[osm . sanspourriel]

Bonjour,

je suis tombé sur ceci :

http://www.openstreetmap.org/node/4439550780#map=18/47.79558/-3.58667=N

En particulier sur ces attributs :


addr:street 
 	Salle 
des Fêtes
amenity  
charging_station 
 

name  	Borne de 
recharge, Clohars-Carnët - Salle des fêtes, SDEF
operator  
Freshmile

ref    QVQF
source  
https://www.freshmile.com/



(C'est le contributeur Freshmile 
 qui a entré ces informations)
addr:street : la voie de service du parking a été nommée Salle des 
Fêtes, non visible au cadastre. Douteux ?

"Borne de recharge" : sans commentaire.
Est-ce que la borne a un nom ou une description ? Ma réponse est dans la 
question ;-).


SDEF : c'est le Syndicat Des Energies du Finistère (qui a fait installer 
les bornes).

Effectivement l'exploitation est faite par Freshmile.
Ne devrait-on pas avoir :
owner=SDEF ? Ou owner=FR:SDEF ;-). http://www.sdef.fr/

Les positions ne semblent pas venir du terrain (semblent un peu 
approximatives, pas déconnantes comme un sefaireconnaitre quand même ;-)).
Mais comme ils n'ont pas mis celle de Crozon qui figure sur leur site, 
je ne sais pas trop :

http://www.openstreetmap.org/search?query=rue%20de%20la%20marne%2C%20crozon#map=19/48.24823/-4.49170=N

Vous trouverez le même genre de soucis pour leurs autres bornes :
http://overpass-turbo.eu/s/kSh

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

Re: [OSM-talk] Beware Pokemon users

[Marcos Oliveira]

Throwing my two cents,

Recently Portugal has been receiving a lot of new members and the vast
majority of them focus on adding paths and parks around a small area.

There has been an increase of bad mapping happening, see [1], [2], [3], [4]
to name a few.

I blame those Pokemon Go users that suggest you edit OSM to increase spawn
chances. It disregards the community and undermines the map data quality.

[1] - https://www.openstreetmap.org/way/461465683 (multiple over-layered
ways)
[2] - https://www.openstreetmap.org/way/461227943 (nonexistent footways
mapped)
[3] - https://www.openstreetmap.org/way/461228607 (unconnected ways)
[4] - https://www.openstreetmap.org/way/461433845 (a bit of everything
wrong)

2016-12-26 13:19 GMT+00:00 Andy Townsend :

> Well, and apologies if this appears in any way snarky, you appear not to
> have welcomed any Pokemon users, whereas the person that you are
> criticising has (e.g. https://www.openstreetmap.org/changeset/44637591
> )...
>
> OSM really doesn't need people more people telling other people what they
> should be doing.  What it does need is people actually willing to help.  If
> you'd like to see example changeset discussion comments to use, there are
> plenty more in the US (see http://resultmaps.neis-one.org
> /osm-discussions?c=United%20States ).  My example FWIW (for one that came
> to the DWG as needing reverting) is on https://www.openstreetmap.org/
> changeset/44656368 .
>
> Cheers,
>
> Andy
>
>
> On 26/12/16 12:14, Andy Mabbett wrote:
>
>> On 25 December 2016 at 17:17, Toby Murray  wrote:
>>
>> Beware Pokemon users
>>>
>> You appear to have accidentally typed "Beware Pokemon users", where
>> the correct subject would be "Please Welcome Pokemon users".
>>
>> HTH, and Merry Christmas!
>>
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 
Um Abraço,
Marcos Oliveira
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Osmose "Possible missing traffic_signals:direction or crossing "

[Thomas Ruchin]

Bonjour

Au vu du marquage au sol visible depuis Bing, cela ressemble un rond-point
plutôt qu'à un carrefour giratoire. Que dit la signalisation verticale
présente sur place ?
Si cela est bien confirmé, il faut remplacer le junction=roundabout par un
oneway=yes
Pour l’anecdote, les carrefours giratoires n'existent pas à Paris
intramuros, de même que les stop

T. Ruchin


Le 26 décembre 2016 à 11:40, lenny.libre  a écrit :

> Bonjour :
>
> Osmose détecte signale sur des feux situés à l'intérieur d'un carrefour
> giratoire.
> *Possible missing traffic_signals:direction or crossing*
> *node 2040084377 *
> + *traffic_signals:direction* = forward
> + *traffic_signals:direction* = backward
> *highway* = traffic_signals
>
> - si je me réfère à la proposition d'osmose avec la direction, cela
> voudrait dire qu'Osmose ne détecte pas que le
> https://www.openstreetmap.org/way/22152292#map=19/43.59409/1.49617 a un
> tag "junction=roundabout" et donc que le tag oneway=* est implicite, la
> direction est donc elle aussi implicite ; ce serait donc une erreur que je
> dois signaler à osmose !
>
> - si je me réfère à la description de l'erreur https://wiki.openstreetmap.
> org/wiki/FR:Osmose/issues#2090
> Détail : Un nœud très proche a déjà le tag crossing=traffic_signals ou le
> tag crossing=traffic_signals a été utilisé sans tag highway=traffic_signals
> à proximité.
> : après vérification, je devrais indiquer "faux positif" et signaler à
> osmose que la description de l'erreur n'est pas complète !
>
> A votre avis, dans quel cas suis-je ?
>
> Merci d'avance
>
> Léni
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Beware Pokemon users

[Andy Townsend]

Well, and apologies if this appears in any way snarky, you appear not to 
have welcomed any Pokemon users, whereas the person that you are 
criticising has (e.g. https://www.openstreetmap.org/changeset/44637591 )...


OSM really doesn't need people more people telling other people what 
they should be doing.  What it does need is people actually willing to 
help.  If you'd like to see example changeset discussion comments to 
use, there are plenty more in the US (see 
http://resultmaps.neis-one.org/osm-discussions?c=United%20States ).  My 
example FWIW (for one that came to the DWG as needing reverting) is on 
https://www.openstreetmap.org/changeset/44656368 .


Cheers,

Andy


On 26/12/16 12:14, Andy Mabbett wrote:

On 25 December 2016 at 17:17, Toby Murray  wrote:


Beware Pokemon users

You appear to have accidentally typed "Beware Pokemon users", where
the correct subject would be "Please Welcome Pokemon users".

HTH, and Merry Christmas!




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

[OSM-talk-be] Lightmap

[Philippe Casteleyn]

Het is nuttiger die tag in te vullen bij fietsstallingen en fietspaden.  Aan de 
kathedraal in Mechelen bijvoorbeeld is er een fietsstalling waar je op de tast 
uw sleutel in uw fietsslot moet steken.
En dan vergeet ik nog de zebrapaden, allemaal nuttige dingen.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] Parco Nazionale dell'Appennino Lucano

[girarsi_liste]

Il 26/12/2016 13:03, Giuseppe Cillis ha scritto:
> Ciao Federico,
> l'utente non più attivo sono io ma solo per motivi personali e nulla più.
> Il dataset è quello ufficiale della Regione Basilicata con licenza libera
> di utilizzo.
> Come mai è da eliminare?
> Avevo anche avviato una discussione per inserirlo con la quale riusci a
> risolvere anche alcuni problemi.
> Saluti
> 
> Giuseppe
> 

Ciao Giuseppe, solo per dirti di rileggere bene, perchè non ha detto di
eliminare il confine, bensì tutt'altro.



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



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

Re: [OSM-talk] Beware Pokemon users

[Andy Mabbett]

On 25 December 2016 at 17:17, Toby Murray  wrote:

> Beware Pokemon users

You appear to have accidentally typed "Beware Pokemon users", where
the correct subject would be "Please Welcome Pokemon users".

HTH, and Merry Christmas!

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Talk-it] Parco Nazionale dell'Appennino Lucano

[Giuseppe Cillis]

Ciao Federico,
l'utente non più attivo sono io ma solo per motivi personali e nulla più.
Il dataset è quello ufficiale della Regione Basilicata con licenza libera
di utilizzo.
Come mai è da eliminare?
Avevo anche avviato una discussione per inserirlo con la quale riusci a
risolvere anche alcuni problemi.
Saluti

Giuseppe

Il giorno 26 dicembre 2016 11:07, Federico Cortese 
ha scritto:

> Buongiorno,
> segnalo che col changeset:
>
> https://www.openstreetmap.org/changeset/44663363
>
> è stata eliminata parte del perimetro del "Parco Nazionale
> Dell'Appennino Lucano Val D'agri Lagonegrese", creato il 31/05/2016
> col changeset:
>
> https://www.openstreetmap.org/changeset/39694446
>
> L'utente che lo ha creato non è più attivo da allora, quindi segnalo
> qui in lista in caso qualcuno fosse interessato ad approfondire.
>
> Ciao
> Federico
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Beware Pokemon users

[Rod Bera]

Hi all,

Thank you Toby for you vigilance.
I do share Clifford's concern about OSM being tweaked/vandalised.

Systematic bias put into the OSM base towards maximising benefits for a
minority of users is a threat.
Especially when the primary interest of these users is not OSM in itself.

Also, to the best of my knowledge, the company behind Pokemon is only
acknowledging Google maps as a source. Not OSM. Therefore those new
users should be redirected to Google mapmaker and left to deal with
subsequent legal issues with that company (the "your data is ours but
trouble is yours" disclaimer by Google).

However, this leaves unaddressed another issue, that of OSM data being
uploaded/copied into google maps. I have myself noticed in several
instances that google maps updated following my own edits into OSM,
especially for features that only myself could be aware of.

So I don't know which process holds here:
1. pokemon directly using (and not acknowledging) OSM data,
or
2. pokemon using google data with google themselves using OSM data (and
not acknowledging it, whether it comes from google paid people or people
"freely" contributing the google base).

Up to now, leaving aside the legal breach of either ODbL or cc-by-sa
licenses (or both), it could nevertheless be satisfying for us to
believe we were contributing to improve other databases as a side effect
(OSM people working for the benefit of all, even google. Even though
google has not the correctness to abide by licensing). And believe
(which I do myself) that ours is better. But now what makes the strength
of OSM could be used to destroy it.

The phenomenon is not new however: we have seen "biased" edits into OSM
in the past, with some OSM users modifying or deleting other
contributions for personal reasons (political, religious, etc., or mere
competition over stats), and putting their questionable ones instead.
This can always happen, but the procedures and general ethos within our
community can usually deal with this smoothly.

Now we're potentially facing a problem of a completely different
magnitude. One tweet among pokemon-Goers saying -no matter true or not-
that they can capture more creatures by tweeking OSM, and we might end
up with myriads of local difficult-to-detect edits by many users (mostly
new, but we can't rule out "pokemonised" OSM users...).

For those who doubt it this is quite serious. Over time people have come
to rely onto OSM for a number of activities, amongst which navigation or
humanitarian activities (just to name a few I'm engaged in. Landuse
management and environmental science is another).

If our geographical commons are impacted this can translate into loss of
meaningful data, and beyond: waste of time and efficiency, waste of
money, even lives.

Yes, OSM has become as crucial as this for some people.

I believe this issue should be discussed at OSMF level.
We, as a community should investigate and take action to safeguard our
common good.

Maybe I'm worrying too much, that Pokemon-Goers won't in their vast
majority sign up and overwhelm OSM with "inaccurate" data.

But there is a risk.
I've long been aware of it but was confident our community could
overcome. Now I'm not too sure anymore.

Rod

On 25/12/16 18:46, Clifford Snow wrote:
> I've been seeing a number of new users adding paths and parks. I deleted
> three "parks" in Tacoma Washington just this morning. One was covering a
> residential area, another was a group of trees behind some houses and
> the third was a vacant lot. The area with the trees might have been an
> attempt to add a landcover feature. But they were all done by the same
> user. None of the changeset comments mentioned pokemon. 
> 
> One user did reply to my welcome message. I had asked him if he was
> mapping as part of a school project. He replied "No, a game I play uses
> path information to generate its data, so I'm uploading my common walk
> paths, getting familiar with OSM and its toolset. Me adding those paths
> is just filling in gaps in that data that others may find useful. Thank
> you for the welcome email! Happy holidays!" His edits were good for a
> new user.
> 
> Since Dec 17th over 20 new people have started mapping in Washington
> State. A good number of them have been adding footways and paths.
> Unfortunately I haven't been keeping records on how many corrections
> I've had to make. 
> 
> There is some good coming from Pokemon, however I worry about the
> increase in vandalism. 
> 
> 
> 
> On Sun, Dec 25, 2016 at 9:17 AM, Toby Murray  > wrote:
> 
> There was a video uploaded to YouTube a couple of days ago that
> claims to show some possible evidence that Pokemon Go uses data from
> OSM to determine good spawn locations for Pokemon. There are also
> several threads on reddit under /r/TheSilphRoad that have similar
> claims. It is amusing to see their speculation and methods of
> testing their "evidence" 

Re: [OSM-talk-fr] MapContrib 1.0.0 est arrivé par la cheminée 

[Guillaume AMAT]

En l'occurrence pour ce problème là le problème existait déjà avant...
La propagation DNS avance, ça sera réglé avant cet après-midi.
26 décembre 2016 12:10 "Christian Quest"  a écrit:

 Si l'ancien serveur est toujours actif, configure un nginx pour faire proxy 
vers le nouveau... ça permet d'avoir une transition "sans couture" 
Le 26 décembre 2016 à 11:49, Guillaume AMAT  a écrit :
J'ai modifié les DNS ce matin pour gérer ces cas là. Chez moi, 
https://mapcontrib.xyz (https://mapcontrib.xyz) fonctionne mais pas encore 
https://cartes.xyz (https://cartes.xyz).
Ça va arriver !

Merci pour tes tests ;)
26 décembre 2016 10:14 osm.sanspourr...@spamgourmet.com 
(mailto:osm.sanspourr...@spamgourmet.com) a écrit:
Effectivement, ça marche : comme c'est du https ou parce que c'est une 
extension non standard, FF n'ajoute pas automatiquement www. et le serveur ne 
redirige pas ce qui arrive directement sur www.cartes.xyz 
(http://www.cartes.xyz) vers www.cartes.xyz (http://www.cartes.xyz). 
Le 26/12/2016 à 08:43, Guillaume AMAT - guilla...@amat.io 
(mailto:guilla...@amat.io) a écrit :  
Salut,

Ce matin ça devrait être bon non ?
Sinon peux-tu essayer en ajoutant www devant ? On sait jamais...

Merci !
26 décembre 2016 00:06 osm.sanspourr...@spamgourmet.com 
(mailto:osm.sanspourr...@spamgourmet.com) a écrit:
Oui, sûrement, mais pas chez moi. 

J'ai cherché l'adresse directement avec un nslookup. 

Pas un pour donner la bonne adresse ? ;-) 
Le 25/12/2016 à 23:50, Vincent Bergeot - vinc...@bergeot.org 
(mailto:vinc...@bergeot.org) a écrit : De mon côté, les 2 adresses 
fonctionnent, ainsi que les quelques thèmes visités.

@Jean-Yves, un problème de cache à vider ?

A plus
Le 25 décembre 2016 23:33:39 GMT+01:00, osm.sanspourr...@spamgourmet.com 
(mailto:osm.sanspourr...@spamgourmet.com) a écrit : 

Les deux mon capitaine ! 
Le 25/12/2016 à 23:22, Guillaume AMAT - guilla...@amat.io 
(mailto:guilla...@amat.io) a écrit : Arf... Sur quelle adresse ?
Le 25 décembre 2016 23:14:11 GMT+01:00, Jean-Yvon Landrac  
(mailto:osm.sanspourr...@spamgourmet.com) a écrit : 

Bonsoir, 

Ou pas. 

Le délai d’attente est dépassé 

Visiblement les DNS ne sont pas encore à jour. 

217.70.184.38 selon Numéricable. Je suppose que c'est l'ancien serveur. 

Jean-Yvon 
Le 25/12/2016 à 22:48, Guillaume AMAT - guilla...@amat.io 
(mailto:guilla...@amat.io) a écrit :  
C'est bon !
Vous pouvez vous rendre aux adresses suivantes quand vous voulez et tester la 
nouvelle version de MapContrib :)
https://mapcontrib.xyz (https://mapcontrib.xyz) et https://cartes.xyz 
(https://cartes.xyz)

À bientôt,
Guillaume
25 décembre 2016 19:39 "Guillaume AMAT"  a écrit:
Mince, le mail est parti trop vite :P
Il s'avère que certains serveurs DNS ne sont pas encore à jour, donc vous 
pourriez tomber sur l'ancien serveur pendant quelques temps... Je viens de le 
couper pour éviter de générer des choses dessus, au risque de les perdre en 
arrivant sur le nouveau serveur.

Ah ! La tuile !
Ça va tomber en marche tout seul, à plus tard ;)
25 décembre 2016 19:35 "Guillaume AMAT"  a écrit:
Oh oh oh !...

Ce matin en me réveillant j'ai trouvé la nouvelle version de MapContrib sous le 
sapin, la 1.0.0 !
Je me suis donc empressé de l'installer sur un tout nouveau serveur et c'est 
disponible aux adresses habituelles :
https://mapcontrib.xyz (https://mapcontrib.xyz) et https://cartes.xyz 
(https://cartes.xyz)

J'ai un peu cherché les nouveautés et j'ai trouvé ça :
* Des colonnes plus larges pour être un peu plus à l'aise. 
* La possibilité de créer des cartes thermiques. 
* Une nouvelle gestion des tags personnalisés et des types de nœuds 
(presets). 
* La possibilité pour le créateur du thème de traduire toutes les 
informations du thèmes en anglais, français et italien (pour le moment). 

 Merci papa Noël !

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

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

Talk-fr mailing list
Talk-fr@openstreetmap.org (mailto:Talk-fr@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-fr 
(https://lists.openstreetmap.org/listinfo/talk-fr)   -- Vincent Bergeot 

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

___ Talk-fr mailing list 

[OSM-talk-be] Lightmap

[Marc Gemis]

It seems we have not mapped a lot of "lit=yes"  on our well lit
Belgian streets:
http://lightmap.uni-hd.de/?lat=51.47197425351888=-0.0679779052734375=10#

regards

m

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

Re: [OSM-talk-fr] MapContrib 1.0.0 est arrivé par la cheminée 

[Christian Quest]

Si l'ancien serveur est toujours actif, configure un nginx pour faire proxy
vers le nouveau... ça permet d'avoir une transition "sans couture"

Le 26 décembre 2016 à 11:49, Guillaume AMAT  a écrit :

> J'ai modifié les DNS ce matin pour gérer ces cas là. Chez moi,
> https://mapcontrib.xyz fonctionne mais pas encore https://cartes.xyz.
> Ça va arriver !
>
> Merci pour tes tests ;)
>
>
>
> 26 décembre 2016 10:14 osm.sanspourr...@spamgourmet.com a écrit:
>
> Effectivement, ça marche : comme c'est du https ou parce que c'est une
> extension non standard, FF n'ajoute pas automatiquement www. et le serveur
> ne redirige pas ce qui arrive directement sur www.cartes.xyz vers
> www.cartes.xyz.
> Le 26/12/2016 à 08:43, Guillaume AMAT - guilla...@amat.io a écrit :
>
> Salut,
>
> Ce matin ça devrait être bon non ?
> Sinon peux-tu essayer en ajoutant www devant ? On sait jamais...
>
> Merci !
>
>
> 26 décembre 2016 00:06 osm.sanspourr...@spamgourmet.com a écrit:
>
> Oui, sûrement, mais pas chez moi.
>
> J'ai cherché l'adresse directement avec un nslookup.
>
> Pas un pour donner la bonne adresse ? ;-)
> Le 25/12/2016 à 23:50, Vincent Bergeot - vinc...@bergeot.org a écrit :
>
> De mon côté, les 2 adresses fonctionnent, ainsi que les quelques thèmes
> visités.
>
> @Jean-Yves, un problème de cache à vider ?
>
> A plus
>
> Le 25 décembre 2016 23:33:39 GMT+01:00, osm.sanspourr...@spamgourmet.com
> a écrit :
>
> Les deux mon capitaine !
> Le 25/12/2016 à 23:22, Guillaume AMAT - guilla...@amat.io a écrit :
>
> Arf... Sur quelle adresse ?
> Le 25 décembre 2016 23:14:11 GMT+01:00, Jean-Yvon Landrac
>   a
> écrit :
>
> Bonsoir,
>
> Ou pas.
>
> *Le délai d’attente est dépassé*
>
> Visiblement les DNS ne sont pas encore à jour.
>
> 217.70.184.38 selon Numéricable. Je suppose que c'est l'ancien serveur.
>
> Jean-Yvon
> Le 25/12/2016 à 22:48, Guillaume AMAT - guilla...@amat.io a écrit :
>
> C'est bon !
> Vous pouvez vous rendre aux adresses suivantes quand vous voulez et tester
> la nouvelle version de MapContrib :)
> https://mapcontrib.xyz et https://cartes.xyz
>
> À bientôt,
> Guillaume
>
>
> 25 décembre 2016 19:39 "Guillaume AMAT"  <%22guillaume%20amat%22%20%3cguilla...@amat.io%3E>> a écrit:
>
> Mince, le mail est parti trop vite :P
> Il s'avère que certains serveurs DNS ne sont pas encore à jour, donc vous
> pourriez tomber sur l'ancien serveur pendant quelques temps... Je viens de
> le couper pour éviter de générer des choses dessus, au risque de les perdre
> en arrivant sur le nouveau serveur.
>
> Ah ! La tuile !
> Ça va tomber en marche tout seul, à plus tard ;)
>
>
> 25 décembre 2016 19:35 "Guillaume AMAT"  <%22guillaume%20amat%22%20%3cguilla...@amat.io%3E>> a écrit:
>
> Oh oh oh !...
>
> Ce matin en me réveillant j'ai trouvé la nouvelle version de MapContrib
> sous le sapin, la 1.0.0 !
> Je me suis donc empressé de l'installer sur un tout nouveau serveur et
> c'est disponible aux adresses habituelles :
> https://mapcontrib.xyz et https://cartes.xyz
>
> J'ai un peu cherché les nouveautés et j'ai trouvé ça :
>
>- Des colonnes plus larges pour être un peu plus à l'aise.
>- La possibilité de créer des cartes thermiques.
>- Une nouvelle gestion des tags personnalisés et des types de nœuds
>(presets).
>- La possibilité pour le créateur du thème de traduire toutes les
>informations du thèmes en anglais, français et italien (pour le moment).
>
> Merci papa Noël !
>
> ___ Talk-fr mailing list 
> Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___ Talk-fr mailing list 
> Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
>
>  --
>
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> -- Vincent Bergeot
>
> ___ Talk-fr mailing list 
> Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___ Talk-fr mailing list 
> Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] MapContrib 1.0.0 est arrivé par la cheminée 

[Guillaume AMAT]

J'ai modifié les DNS ce matin pour gérer ces cas là. Chez moi, 
https://mapcontrib.xyz fonctionne mais pas encore https://cartes.xyz.
Ça va arriver !

Merci pour tes tests ;)
26 décembre 2016 10:14 osm.sanspourr...@spamgourmet.com 
(mailto:osm.sanspourr...@spamgourmet.com) a écrit:
Effectivement, ça marche : comme c'est du https ou parce que c'est une 
extension non standard, FF n'ajoute pas automatiquement www. et le serveur ne 
redirige pas ce qui arrive directement sur www.cartes.xyz 
(http://www.cartes.xyz) vers www.cartes.xyz (http://www.cartes.xyz). 
Le 26/12/2016 à 08:43, Guillaume AMAT - guilla...@amat.io 
(mailto:guilla...@amat.io) a écrit :  
Salut,

Ce matin ça devrait être bon non ?
Sinon peux-tu essayer en ajoutant www devant ? On sait jamais...

Merci !
26 décembre 2016 00:06 osm.sanspourr...@spamgourmet.com 
(mailto:osm.sanspourr...@spamgourmet.com) a écrit:
Oui, sûrement, mais pas chez moi. 

J'ai cherché l'adresse directement avec un nslookup. 

Pas un pour donner la bonne adresse ? ;-) 
Le 25/12/2016 à 23:50, Vincent Bergeot - vinc...@bergeot.org 
(mailto:vinc...@bergeot.org) a écrit : De mon côté, les 2 adresses 
fonctionnent, ainsi que les quelques thèmes visités.

@Jean-Yves, un problème de cache à vider ?

A plus
Le 25 décembre 2016 23:33:39 GMT+01:00, osm.sanspourr...@spamgourmet.com 
(mailto:osm.sanspourr...@spamgourmet.com) a écrit : 

Les deux mon capitaine ! 
Le 25/12/2016 à 23:22, Guillaume AMAT - guilla...@amat.io 
(mailto:guilla...@amat.io) a écrit : Arf... Sur quelle adresse ?
Le 25 décembre 2016 23:14:11 GMT+01:00, Jean-Yvon Landrac  
(mailto:osm.sanspourr...@spamgourmet.com) a écrit : 

Bonsoir, 

Ou pas. 

Le délai d’attente est dépassé 

Visiblement les DNS ne sont pas encore à jour. 

217.70.184.38 selon Numéricable. Je suppose que c'est l'ancien serveur. 

Jean-Yvon 
Le 25/12/2016 à 22:48, Guillaume AMAT - guilla...@amat.io 
(mailto:guilla...@amat.io) a écrit :  
C'est bon !
Vous pouvez vous rendre aux adresses suivantes quand vous voulez et tester la 
nouvelle version de MapContrib :)
https://mapcontrib.xyz (https://mapcontrib.xyz) et https://cartes.xyz 
(https://cartes.xyz)

À bientôt,
Guillaume
25 décembre 2016 19:39 "Guillaume AMAT"  a écrit:
Mince, le mail est parti trop vite :P
Il s'avère que certains serveurs DNS ne sont pas encore à jour, donc vous 
pourriez tomber sur l'ancien serveur pendant quelques temps... Je viens de le 
couper pour éviter de générer des choses dessus, au risque de les perdre en 
arrivant sur le nouveau serveur.

Ah ! La tuile !
Ça va tomber en marche tout seul, à plus tard ;)
25 décembre 2016 19:35 "Guillaume AMAT"  a écrit:
Oh oh oh !...

Ce matin en me réveillant j'ai trouvé la nouvelle version de MapContrib sous le 
sapin, la 1.0.0 !
Je me suis donc empressé de l'installer sur un tout nouveau serveur et c'est 
disponible aux adresses habituelles :
https://mapcontrib.xyz (https://mapcontrib.xyz) et https://cartes.xyz 
(https://cartes.xyz)

J'ai un peu cherché les nouveautés et j'ai trouvé ça :
* Des colonnes plus larges pour être un peu plus à l'aise. 
* La possibilité de créer des cartes thermiques. 
* Une nouvelle gestion des tags personnalisés et des types de nœuds 
(presets). 
* La possibilité pour le créateur du thème de traduire toutes les 
informations du thèmes en anglais, français et italien (pour le moment). 

 Merci papa Noël !  

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

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

Talk-fr mailing list
Talk-fr@openstreetmap.org (mailto:Talk-fr@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-fr 
(https://lists.openstreetmap.org/listinfo/talk-fr)   -- Vincent Bergeot 

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

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

[OSM-talk-fr] Osmose "Possible missing traffic_signals:direction or crossing "

[lenny.libre]

Bonjour :

Osmose détecte signale sur des feux situés à l'intérieur d'un carrefour 
giratoire.


*Possible missing traffic_signals:direction or crossing*
*node 2040084377 *
+ *traffic_signals:direction* = forward
+ *traffic_signals:direction* = backward
*highway* = traffic_signals

- si je me réfère à la proposition d'osmose avec la direction, cela 
voudrait dire qu'Osmose ne détecte pas que le 
https://www.openstreetmap.org/way/22152292#map=19/43.59409/1.49617 a un 
tag "junction=roundabout" et donc que le tag oneway=* est implicite, la 
direction est donc elle aussi implicite ; ce serait donc une erreur que 
je dois signaler à osmose !


- si je me réfère à la description de l'erreur 
https://wiki.openstreetmap.org/wiki/FR:Osmose/issues#2090
Détail : Un nœud très proche a déjà le tag crossing=traffic_signals ou 
le tag crossing=traffic_signals a été utilisé sans tag 
highway=traffic_signals à proximité.
: après vérification, je devrais indiquer "faux positif" et signaler à 
osmose que la description de l'erreur n'est pas complète !


A votre avis, dans quel cas suis-je ?

Merci d'avance

Léni

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

[Talk-it] Parco Nazionale dell'Appennino Lucano

[Federico Cortese]

Buongiorno,
segnalo che col changeset:

https://www.openstreetmap.org/changeset/44663363

è stata eliminata parte del perimetro del "Parco Nazionale
Dell'Appennino Lucano Val D'agri Lagonegrese", creato il 31/05/2016
col changeset:

https://www.openstreetmap.org/changeset/39694446

L'utente che lo ha creato non è più attivo da allora, quindi segnalo
qui in lista in caso qualcuno fosse interessato ad approfondire.

Ciao
Federico

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

[Talk-it] reinoltro messaggio già diffuso su gfoss.it e spaghetti open data

[Andrea Giacomelli]

Buongiorno e buone feste -

scusandomi per le triplici ricezioni di alcuni di voi:

http://www.pibinko.org/una-storia-natalizia-sul-mappare-dal-2008-a-oggi/

L'articolo nasce non a caso...siamo un po' in un clima di decennali (a
partire dal Festival d'Inverno in Val di Farma, ben spiegato dal Tirreno
del 17-12 scorso [1]), e quindi è magari per questo che si fanno alcune
sintesi.

un saluto e grazie per l'attenzione.

Andrea
http://www.pibinko.org

[1]
http://www.pibinko.org/a-misurare-il-buio-nella-valle-che-non-ce-il-tirreno-17-12-2016/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Tasking manager italiano inaccessibile

[Fabrizio Tambussa]

Era andato in crash il processo.
Due martellate al server ed e' ripartito.
Saluti


2016-12-26 7:33 GMT+01:00 dan980 :
> Segnalo che dal 24 dicembre il tasking manager italiano
> (http://osmit-tm.wmflabs.org) non risulta più accessibile. Compare il
> seguente messaggio:
>
>
>
> -
> --
> confronto navigatori basati su OSM:
> https://docs.google.com/spreadsheets/d/1xmhQ15bQ5eH_8U7kCzwi5xoNtT8e8JxDUEz05px-Vog/pubhtml
>
> --
> View this message in context: 
> http://gis.19327.n8.nabble.com/Tasking-manager-italiano-inaccessibile-tp5888155.html
> Sent from the Italy General mailing list archive at Nabble.com.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [OSM-talk-fr] MapContrib 1.0.0 est arrivé par la cheminée 

[osm . sanspourriel]

Effectivement, ça marche : comme c'est du https ou parce que c'est une 
extension non standard, FF n'ajoute pas automatiquement www. et le 
serveur ne redirige pas ce qui arrive directement sur www.cartes.xyz 
vers www.cartes.xyz.



Le 26/12/2016 à 08:43, Guillaume AMAT - guilla...@amat.io a écrit :

Salut,

Ce matin ça devrait être bon non ?
Sinon peux-tu essayer en ajoutant www devant ? On sait jamais...

Merci !


26 décembre 2016 00:06 osm.sanspourr...@spamgourmet.com 
 a écrit:


Oui, sûrement, mais pas chez moi.

J'ai cherché l'adresse directement avec un nslookup.

Pas un pour donner la bonne adresse ? ;-)

Le 25/12/2016 à 23:50, Vincent Bergeot - vinc...@bergeot.org
 a écrit :

De mon côté, les 2 adresses fonctionnent, ainsi que les quelques
thèmes visités.

@Jean-Yves, un problème de cache à vider ?

A plus


Le 25 décembre 2016 23:33:39 GMT+01:00,
osm.sanspourr...@spamgourmet.com
 a écrit :

Les deux mon capitaine !

Le 25/12/2016 à 23:22, Guillaume AMAT - guilla...@amat.io
 a écrit :

Arf... Sur quelle adresse ?
Le 25 décembre 2016 23:14:11 GMT+01:00, Jean-Yvon Landrac

 a écrit :

Bonsoir,

Ou pas.

/Le délai d’attente est dépassé/

Visiblement les DNS ne sont pas encore à jour.

217.70.184.38 selon Numéricable. Je suppose que c'est
l'ancien serveur.

Jean-Yvon

Le 25/12/2016 à 22:48, Guillaume AMAT -
guilla...@amat.io  a écrit :

C'est bon !
Vous pouvez vous rendre aux adresses suivantes quand
vous voulez et tester la nouvelle version de MapContrib :)
https://mapcontrib.xyzet https://cartes.xyz

À bientôt,
Guillaume


25 décembre 2016 19:39 "Guillaume AMAT"
>
a écrit:

Mince, le mail est parti trop vite :P
Il s'avère que certains serveurs DNS ne sont pas
encore à jour, donc vous pourriez tomber sur
l'ancien serveur pendant quelques temps... Je viens
de le couper pour éviter de générer des choses
dessus, au risque de les perdre en arrivant sur le
nouveau serveur.

Ah ! La tuile !
Ça va tomber en marche tout seul, à plus tard ;)


25 décembre 2016 19:35 "Guillaume AMAT"
>
a écrit:

Oh oh oh !...

Ce matin en me réveillant j'ai trouvé la
nouvelle version de MapContrib sous le sapin,
la 1.0.0 !
Je me suis donc empressé de l'installer sur un
tout nouveau serveur et c'est disponible aux
adresses habituelles :
https://mapcontrib.xyzet https://cartes.xyz

J'ai un peu cherché les nouveautés et j'ai
trouvé ça :

  * Des colonnes plus larges pour être un peu
plus à l'aise.
  * La possibilité de créer des cartes thermiques.
  * Une nouvelle gestion des tags personnalisés
et des types de nœuds (presets).
  * La possibilité pour le créateur du thème de
traduire toutes les informations du thèmes
en anglais, français et italien (pour le
moment).

Merci papa Noël !

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


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


  




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


-- Vincent Bergeot

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




___
Talk-fr mailing list

Re: [Talk-it] Tasking manager italiano inaccessibile

[Francesco Pelullo]

Il 26 dic 2016 09:52, "girarsi_liste"  ha scritto:



Probabile sia in manutenzione.



OT:
Non so se sia questo il caso, ma su un'altra macchina, che gestisco io e
che non c'entra nulla con OSM, nelle ultime 48 ore ho registrato migliaia
di tentativi di intrusione, provenienti da centinaia di indirizzi IP.

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

Re: [Talk-it] Tasking manager italiano inaccessibile

[girarsi_liste]

Il 26/12/2016 07:33, dan980 ha scritto:
> Segnalo che dal 24 dicembre il tasking manager italiano
> (http://osmit-tm.wmflabs.org) non risulta più accessibile. Compare il
> seguente messaggio: 
> 

Probabile sia in manutenzione.



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



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

Re: [Talk-at] Peter Paul

[Martin Raifer]

Wieso? Dieser historische Name scheint ja aktuell nicht mehr in
Verwendung zu sein?


2016-12-24 18:55 GMT+01:00 ScubbX :
> Finde ich gut.
>
> Im historischen Orts- und Riednamenverzeichnis vom BEV findet sich an dieser
> Stelle gar keine Bezeichnung.
>
>
> Am 2016-12-24 um 17:42 schrieb Liberaler Humanist:
>
> Auf einer Reproduktion des Franziszeischen Katasters findet sich etwas
> unterhalb der Name "Handleinsberg" ( Vgl.:
> https://www.wien.gv.at/kultur/kulturgut/plaene/franziszeisch.html - Man muss
> heranzoomen). Warum sich der Name nicht mehr in späteren Karten findet ist
> nicht ersichtlich, da der Gipfel wie am Commons-Foto ersichtlich als solcher
> klar erkennbar ist und auch auf einer topografischen Karte eine
> entsprechende Prominenz zeigt (
> https://opentopomap.org/#map=17/48.27224/16.31161 ). Da der Name
> Handleinsberg belegbar ist werde ich diesen auf der Karte eintragen.
>
> MfG, LH
>
>> Von: realadry 
>> Datum: 24.12.2016 2:20 nachm.
>> Betreff: Re: [Talk-at] Peter Paul
>> An: OpenStreetMap AT 
>> Cc:
>>
>> > Hallo,
>> >
>> > Ich habe ein bisschen in online verfügbaren historischen Karten
>> > recherchiert und laut dieser Karte [1] von ca. 1941-1945, ist an dieser
>> > Stelle ein Gipfel markiert mit der Bezeichnung "Schwaben-Ws. 482".
>> > Ein Vergleich der Höhenlinien mit dem von Friedrich Volkmann geposteten
>> > screenshot [2], legt nahe, dass es sie hier um den selben Gipfel
>> > handelt. Die unterschiedliche Höhe (482 vs. 495) liegt vermutlich an
>> > damalig ungenauen Messmethoden bzw. Veränderung der Landschaft in der
>> > Zwischenzeit.
>> > Die Bezeichnung "Peter Paul" hingegen findet sich in keinem Dokument,
>> > weder historisch noch aktuell. Nur weil jemand diesen Namen auf OSM
>> > einträgt und sich dadurch verbreitet, macht es ihn noch lange nicht zum
>> > offiziellen oder gebräulichen Namen.
>> >
>> > Weiters: Das erste mal wurde der Gipfel in OSM auf "Peter Paul" benannt
>> > am 28.Juli 2012 [3]. Das Panoramio Bild wurde aber erst danach, am
>> > 10.August 2012, hochgeladen. Es ist also naheliegend, dass der Name des
>> > Gipfels auf dem Bild falsch aus OSM übernommen wurde.
>> >
>> > Ich hoffe das sind genug Beweise um zu zeigen, dass dieser Gipfel nicht
>> > "Peter Paul" heißt, auch wenn es jemand gerne so hätte. ;)
>> >
>> >
>> > [1]https://www.wien.gv.at/actaproweb2/benutzung/image.xhtml?id=kfGyc/iEt7fL65LzraHfwuM0+8OkdD4Jp25sfgC2ACs1
>> >
>> > [2]http://www.steige.info/austausch/screenshot_pp.png
>> >
>> > [3]http://www.openstreetmap.org/changeset/12521352
>> >
>> > Am 23.12.2016 um 18:50 schrieb grubernd:
>> > >> http://www.openstreetmap.org/note/510342
>> > >
>> > > endlich wieder einmal ein Henne-Ei-Problem.
>> > >
>> > > Meinung: war unbenannt, also ist eine Namensgebung absolut legitim, da
>> > > keinerlei Datenvandalismus vorliegt. mittlerweile finden sich einige
>> > > Hinweise [1][2], dass der Berg auch von anderen so genannt wird, also
>> > > wurde der Name angenommen. irgendwann ist es egal was einmal die Henne
>> > > und was das Ei war.
>> > >
>> > > ohne Worte für Dinge können wir nicht über diese Dinge reden, denken
>> > > und
>> > > uns austauschen. irgendjemand muss den ersten Schritt tun. unbenannte
>> > > Dinge nach dem Entdecker zu benennen ist ja durchaus eine grosse und
>> > > anerkannte Tradition in der Kartographie.
>> > >
>> > > grüsse,
>> > > grubernd
>> > >
>> > > [1] http://www.panoramio.com/photo/76813516
>> > > [2]
>> > >
>> > > http://www.gipfeltreffen.at/showthread.php?82202-Peter-Paul-Berg-494m-Wienerwald-(5620)/page2
>
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>

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

Re: [Talk-it] Bulk edit fuel:cng=yes

[Francesco Pelullo]

Il 26 dic 2016 08:55, "Martin Koppenhoefer"  ha
scritto:





da me +1
intendi anche togliere il "name"? Vorrei far notare che esiste 'Metano', ci
vanno pure degli autobus urbane ;-)


Ciao Martin,

Ormai è fatto, ho eseguito l'edit ieri sera come da messaggio precedente.

Ho modificato soltanto il tag fuel:cng=yes dei nodi dove mancava del tutto,
ne ho trovato  uno che ha fuel:cng=no e presumendo che l'autore sapeva cosa
stava facendo, l'ho lasciato tal quale.

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