Re: [Talk-in] Railway station GPS co-ordinates

[Sutripta]

Hi,
Thanks.
How does one know if an object has been groundtruthed/ validated?

Regards
Sutripta

On 16 May 2016 at 13:17, Shibu Narayanan  wrote:

> The link suggested by Arun http://download.geofabrik.de/asia/india.html has
> a 10GB xml file which contains the required information.
>
> I will extract it as a csv and post the results here.
>
>
>
>
> *Shibu Narayanan *Oracle Financial Services | Bangalore | India
> Office:0091-80-4918-1692 | Mobile:0091-99800-64282
>
>
>
> *From:* Sutripta (Gmail) [mailto:sutri...@gmail.com]
> *Sent:* Monday, May 16, 2016 12:10 PM
> *To:* OpenStreetMap in India
> *Subject:* Re: [Talk-in] Railway station GPS co-ordinates
>
>
>
> Hi,
> Is the list of Railway Stations/ Junctions in India available as a CSV/
> Excel file? Maybe with a column saying 'Ground truthed/ validated'.
>
> Sometime back there was a XML file from IR, but as pointed out by Arun
> Ganesh, had a lot of errors.
>
> Regards
> Sutripta
>
> On 12-05-2016 22:19, Arun Ganesh wrote:
>
> Hey Shibu, you can extract it live from OSM using overpass:
> http://overpass-turbo.eu/s/gbk
>
>
>
> If you want a shapefile of a larger area, suggest you download the OSM
> extract from geofabrik http://download.geofabrik.de/asia/india.html
>
>
>
> The POI layer should have the railway stations.
>
>
>
> On Thu, May 12, 2016 at 9:59 PM, Shibu Narayanan <
> shibu.naraya...@oracle.com> wrote:
>
> Hi,
>
> How do I get the list of all railway stations in Karnataka(or any other
> state) and also its GPS co-ordinates?
>
>
>
>
> *Shibu Narayanan *Oracle Financial Services | Bangalore | India
> Office:0091-80-4918-1692 | Mobile:0091-99800-64282
>
>
>
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
>
>
>
> --
>
> Arun Ganesh
>
> @planemad
>
>
>
>
> ___
>
> Talk-in mailing list
>
> Talk-in@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-cz] WeeklyOSM CZ 301

[Miroslav Suchý]

Dne 16.5.2016 v 22:52 Pavel Machek napsal(a):
> Na cestu proste hodim kct_red=major. Jasne, az ty znacky bude vetsi
> kus, tak by bylo dobry vyrobit relaci, ale ted jeste neni dobry cas.

A co treba:
fixme=tady vede cervena znacka

Mirek

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

Re: [OSM-talk] Upload slowness - what's going on?

[Ben Discoe]

API download and upload has gotten fast(er) tonight, for the first
time since the server move on May 9!
Whatever they've done today, it's working!
I am so happy. This really impacts my life.
Thanks,
Ben

On Fri, May 13, 2016 at 5:59 AM, Grant Slater
 wrote:
> Hi All,
>
> On Monday 9th May 2016 the master OSM database server was moved to
> York (Bytemark) from London (Imperial).
> This was to avoid multiple upcoming weekends of planned power testing
> & maintenance at the Imperial data centre. For the last few years
> Imperial has housed all our main critical systems including master &
> slave DB servers and frontend & backend web/api servers. We also added
> 4 new frontend/backend web/api server to York on Monday.
>
> We now have the master database server in York and the secondary
> database server in Imperial. We also have a warm standby slave db in
> AWS Ireland. A fourth SSD (NVMe) based DB server was delivered
> yesterday (Thursday), but it needs testing (burn-in, reliability,
> performance etc) before we can start using it. Slave DB servers can be
> promoted to master if required.
>
> The slave db servers serve Web/API read traffic and writes go to the
> master. When the frontend + backend servers were in the same data
> centre as the master db server the latency was <1ms. We now run a VPN
> to connect the servers up and the latency is ~8ms Imperial to
> Bytemark. Currently we are using the frontend & backends server at
> Imperial (closest to slave db read server) and sending writes over the
> VPN to Bytemark. The extra 8ms roundtrip is triggered multiple times
> based on the size of the upload changeset, this is the root cause for
> the slower uploads. The link between Imperial & Bytemark can handle
> gigabit speeds. Over the last few days we've been tweaking the VPN
> settings to get optimal latency & throughput over the links.
>
> Over today (for at least the weekend) we are switching to the new
> frontend & backend servers in York (Bytemark). London Imperial will be
> offline from approximately 5pm (GMT+1) for the first weekend of power
> maintenance.
>
> In summary: The slow uploads are a known issue and we'll fix as soon
> as practical. Our main concern has been setting up multiple data
> center redundancy to avoid extended downtime.
>
> Here is the list of all core hardware and hosting locations:
> https://hardware.openstreetmap.org/
>
> Hope that answers the questions. ;-)
>
> Photos or it didn't happen:
> * Syncing & powering down before we start London -> York DB move:
> https://twitter.com/OSM_Tech/status/729582996685213696
> * Staged photo of racking up the master DB server at Bytemark:
> https://twitter.com/OSM_Tech/status/729693392737832961
> * Testing the new Frontend / Backend servers a week ago:
> https://twitter.com/OSM_Tech/status/728286193696292865
>
> Bytemark are a fantastic hosting company and their ongoing support of
> the OpenStreetMap project is highly commendable. Please support them
> ;-) https://twitter.com/bytemark/status/729698435339853824
>
> Kind regards,
>
> Grant
> Part of the OSM Ops team.
>
>
> On 13 May 2016 at 11:44, Tim Waters  wrote:
>> I believe the Dev mailing list may have some of your technical answers
>> https://lists.openstreetmap.org/pipermail/dev/2016-May/thread.html
>>
>> It appears from that list that the database servers are now a few
>> hundreds of miles from where the web servers are, causing the increase
>> in latency. I do not know if this is a permanent change, the thread on
>> osm-dev does seem to indicate that things are still in flux.
>>
>> Tim
>>
>>
>>
>> On 13 May 2016 at 06:02, Ben Discoe  wrote:
>>> Several of us have noticed radically slowly upload speed for
>>> changesets, roughly since the server move on May 9.  Like, as
>>> painfully slow as it used to be, it's now several times slower.
>>>
>>> It's been discussed with @OSM_Tech on twitter, in this thread:
>>> https://twitter.com/OSM_Tech/status/730857486618664960
>>>
>>> Before I get too hysterical, can somebody tell me what happened, and
>>> can it be fixed?
>>>
>>> OSM_Tech's mysterious message:
>>>   "Large uploads will take around 3 times longer. Small uploads extra
>>> delay should be minimal."
>>>
>>> Does this mean that something did change?  It is database writes that
>>> are taking so much longer?  Changesets with as few as 400 object are
>>> taking several times longer, what constitutes "large" vs. "small"?
>>> Can it be fixed?  Can I donate large sums of money somewhere to help
>>> it get fixed?
>>>
>>> Thanks,
>>> Ben
>>>
>>> ___
>>> 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

Re: [Talk-cz] WeeklyOSM CZ 301

[Marián Kyral]

Ahoj,


-- Původní zpráva --
Od: Pavel Machek 
Komu: OpenStreetMap Czech Republic 
Datum: 16. 5. 2016 23:28:50
Předmět: Re: [Talk-cz] WeeklyOSM CZ 301

"Ahoj!

> http://www.weeklyosm.eu/cz/archives/7383
> 
> Téma čísla: Odstranění tagu kct_barva

Takze situace, jedu na koni po lese, na 200m odbocim na turistickou
trasu, pak z ni zase sjedu a pokracuju kam nas nohy nesou.

Doma zmapuju pesinky, a ted mam par moznosti:

Pokud nekde pobliz je relace turisticke znacky, tak do ni tu znacku
pridam.

Na cestu proste hodim kct_red=major. Jasne, az ty znacky bude vetsi
kus, tak by bylo dobry vyrobit relaci, ale ted jeste neni dobry cas.

Podle noveho navrhu bych, pokud ale relace nikde pobliz neni, mel
vyrobit novou relaci, dat ji asi 5 ruznych tagu. Sorry, ale to
neudelam, protoze:

a) je to trochu moc prace
"



Promiň Pavle, ale  vymlouvat se na vlastní lenost mi přijde sobecké. 
Vytvoření nové relace turistické trasy je v JOSM, díky presetu "Czech hiking
routes
(https://josm.openstreetmap.de/josmfile?page=Presets/Czech_hiking=1)" od
vrabčáka, otázkou čtyř kliků. Prvním vybereš cestu/cesty, které mají být 
součástí nové relace, pak v presetech vybereš správnou značku, zadáš jméno 
(pokud má) a klikneš na vytvořit relaci. 









"
b) kdyz to takhle bude delat vic lidi, tak v mape budem mit asi tak
100 relaci o jednom prvku, a spojovani bude vylozene zajimave."



Tak nikdo neříká, že to musíš spojovat právě ty. A jen tak pro zajímavost, 
kde u nás v ČR narazím na turistickou relaci rozdrobenou do stovky malých 
kousků? Tohle mi přijde jako hodně nereálný případ. 




"

Jo, kdyz je zmapovanych par km cesty od rozcestniku k rozcestniku,
dava smysl tu relaci vytvorit, a asi bych tim mel tech par minut
stravit. Ale ne kvuli 200m. Sorry."



Zkus ten preset.



"

Mimochodem, kdyby nekdo mel poloautomaticky nastroj na takovehle
spojovani, tak by to asi nebylo spatne. On boj s josma relacema neni
uplne trivialni, a nejsem si jisty jestli to vzdycky udelam
korektne...
Pavel
"



No to by chtělo. Koukám, že přání od jezevce hnije v Tracu už šest let: 
https://josm.openstreetmap.de/ticket/5124

Zřejmě to nikoho z vývojářů a uživatelů příliš netrápí. Můžeš tomu trošku 
pomoct, když budeš pro to issue hlasovat.




Momentálně mám jiné priority, ale pokud bude potřeba, můžu na to kouknout.




Marián



"
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/
blog.html

___
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

[OSM-talk-fr] Invitation à discuter de la cartographie interactive sur Wikipédia

[Philippe Verdy]

Appel traduit en français sur MetaWiki...
https://meta.wikimedia.org/wiki/User:CKoerner_(WMF)/Work/Maps_Communication_Invite/fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-br] Importação PMPA / Prédios : esquema de conversão para o OSM

[Sérgio V .]

>> naoliv

> convenção de key=S3DB:*

>Da onde você achou as tags S3DB:* ?

Inventei, ora pois. Por isto " 'proposta' convenção de key=S3DB:*". Localmente, 
para este caso (eventualmente poderia até para similares, mas inicialmente não 
é a intenção). Adaptada a partir do 
"Simple_3D_buildings, 
S3DB Proposals...). Achei que assim poderia ajudar ao menos neste caso quando 
quiser encontrar os prédios e aproveitar os que já estão em layers, quando 
quiser fazer 3D, com a chave S3DB...  Porque não tem como fazer 3D para todos 
agora. O resto que vem na sequência segue o padrão do S3DB no wiki para: 
relação type=building; role=outline (este na verdade não uma tag, mas 
indicativo do role na relação 3D); building:part=yes,... De todo modo, mesmo 
ordinariamente, quem vai fazer 3D tem que conhecer estas tags e editar em cada 
prédio manualmente, pois não tem substituição automática para colocar height=*, 
building:levels=*, que são quantitativos. Tem que fornecer de fora. Apenas que 
para aproveitar a indicação das tags de preparação para 3D na proposta, basta 
apagar onde diz "S3DB:", e acrescentar o quantitativo de andares, etc, que já 
converte em parte as tags necessárias para isto. De modo ordinário, tem que 
adicionar as tags de 3D e criar a relação. Até a relação 2D de 
type=multipolygon daria para encontrar fácil e aproveitar, basta apagar o S3DB: 
em S3DB:type=building. Gasta menos tecladas do que digitar de novo 
"type=building", etc... e as demais (onde der para aproveitar). Também já vai 
junto indicado qual é o membro outline que define a relação 3D, sem precisar 
procurar. Mas se atrapalhar mais que ajudar, deixo sem nada além das conversões 
necessárias.

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-at] "ref=*" bei Bushaltestellen / touristenrelevante Haltestellen finden

[Kevin Kofler]

Robin Däneke wrote:
> 2. Wie kann man eine Haltestelle einer Touristenbahn -> zb. VRT so
> taggen, dass sie auch in der Suche aufscheint, wenn man VRT oder Vienna
> Ring Tram sucht? (Diese Frage stellt sich auch der User "Phipsiii")

alt_name="Vienna Ring Tram"
short_name="VRT"
(und name="Schwedenplatz" wie gehabt)
sollte funktionieren.

Kevin Kofler


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

[Talk-br] RES: Usuário apagando o mapa.

[Blademir Andrade de Lima]

Já reverti.

Se ele continuar terão que bloquear ele.

Att,
BladeTC

Enviado do Email para Windows 10

De: Nelson A. de Oliveira
Enviado:segunda-feira, 16 de maio de 2016 21:03
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Usuário apagando o mapa.

2016-05-16 21:00 GMT-03:00 Blademir Andrade de Lima :
> Amigos, tem um cara apagando o mapa.
>
> https://www.openstreetmap.org/changeset/39322462

Vou reverter.

___
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

Re: [Talk-us] FW: Dakota County, MN Street Data Available

[Joe Sapletal]

My selection and export process for missing and major misalignments between 
Dakota County street centerlines and OSM data.

http://dcgisjoe.blogspot.com/2016/05/updating-streets-in-osm.html

Joe

From: Joe Sapletal
Sent: Thursday, May 12, 2016 1:05 PM
To: David Chiles
Cc: talk-us@openstreetmap.org
Subject: Re: [Talk-us] FW: Dakota County, MN Street Data Available

I suppose I could.  It wasn’t really anything too fantastic, but I did make 
some notes so I could do it again the same for a while.

Joe

From: David Chiles
Sent: Thursday, May 12, 2016 12:47 PM
To: Joe Sapletal
Cc: talk-us@openstreetmap.org
Subject: Re: [Talk-us] FW: Dakota County, MN Street Data Available

Joe this looks really great!

Do you plan on releasing the scripts/queries or process you used to compare the 
two datasets?

On Thu, May 12, 2016 at 10:15 AM, Joe Sapletal  wrote:
 
 
From: Joe Sapletal
Sent: Wednesday, May 11, 2016 7:54 PM
To: Clifford Snow
Subject: RE: [Talk-us] Dakota County, MN Street Data Available
 
We do, it is owned by the County and falls under the open data policy.  The 
intent was to make it available to everyone.  The imagery and a whole pile of 
other datasets were provided to Esri for inclusion into their basemaps and we 
are looking for others to take the data and incorporate it into their basemaps.
 
Dakota County GIS Database Disclaimer
NOTICE: Dakota County Geographic Information System (GIS) Data are made 
available pursuant to the Minnesota Government Data Practices Act (Minnesota 
Statutes Chapter 13) THE GIS DATA ARE PROVIDED TO YOU AS IS AND WITHOUT ANY 
WARRANTY AS TO THEIR PERFORMANCE, MERCHANTABILITY, OR FITNESS FOR ANY 
PARTICULAR PURPOSE. The GIS Data were developed by Dakota County (“County”) for 
their own internal business purposes. The County does not represent or warrant 
that the GIS Data or the data documentation are error-free, complete, current, 
or accurate. You are responsible for any consequences resulting from your use 
of the GIS Data or your reliance on the GIS Data. You should consult the data 
documentation for this particular GIS Data to determine the limitations of the 
GIS Data and the precision with which the GIS Data may depict distance, 
direction, location, or other geographic features. If you transmit or provide 
the GIS Data (or any portion of it) to another user, you must provide a copy of 
this disclaimer and the accompanying metadata for this dataset to the user.
 
Joe
 
From: Clifford Snow
Sent: Wednesday, May 11, 2016 6:11 PM
To: Joe Sapletal
Cc: talk-us@openstreetmap.org
Subject: Re: [Talk-us] Dakota County, MN Street Data Available
 
 
On Wed, May 11, 2016 at 4:00 PM, Joe Sapletal  wrote:
The repository also notes the URL for the 2015 Air Photo for use in JOSM.  I’ve 
used it, lines up nicely despite the warnings.

Joe,
Could you confirm that we have the right to trace the 2015 Air Photo imagery 
for use in OpenStreetMap. 
 
Thanks,
Clifford


 
-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
 
 

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



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

Re: [Talk-br] Importação PMPA / Prédios : esquema de conversão para o OSM

[Nelson A. de Oliveira]

2016-05-16 19:18 GMT-03:00 Sérgio V. :
> convenção de key=S3DB:*

Da onde você achou as tags S3DB:* ?

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

[OSM-talk] Cheap Mapillary setup

[Rob Nickerson]

Based on the new v2 Raspberry Pi Zero:

https://twitter.com/mappamercia/status/732334812703379456

Would love to see one of these up and running. Would be even better if they
were available by State of the Map 2016!

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

Re: [Talk-us] WikiProject US Bicycle Route System call for volunteers

[OSM Volunteer stevea]

> As it is now spring (or fall), it’s that national biennial bicycle routes 
> time of year!

Whoops, semi-annual, not biennial:  AASHTO approves state DOT ballots for new 
USBRs every spring and autumn.

SteveA
California


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

Re: [Talk-cz] WeeklyOSM CZ 301

[Pavel Machek]

Ahoj!

> http://www.weeklyosm.eu/cz/archives/7383
> 
> Téma čísla: Odstranění tagu kct_barva

Takze situace, jedu na koni po lese, na 200m odbocim na turistickou
trasu, pak z ni zase sjedu a pokracuju kam nas nohy nesou.

Doma zmapuju pesinky, a ted mam par moznosti:

Pokud nekde pobliz je relace turisticke znacky, tak do ni tu znacku
pridam.

Na cestu proste hodim kct_red=major. Jasne, az ty znacky bude vetsi
kus, tak by bylo dobry vyrobit relaci, ale ted jeste neni dobry cas.

Podle noveho navrhu bych, pokud ale relace nikde pobliz neni, mel
vyrobit novou relaci, dat ji asi 5 ruznych tagu. Sorry, ale to
neudelam, protoze:

a) je to trochu moc prace

b) kdyz to takhle bude delat vic lidi, tak v mape budem mit asi tak
100 relaci o jednom prvku, a spojovani bude vylozene zajimave.

Jo, kdyz je zmapovanych par km cesty od rozcestniku k rozcestniku,
dava smysl tu relaci vytvorit, a asi bych tim mel tech par minut
stravit. Ale ne kvuli 200m. Sorry.

Mimochodem, kdyby nekdo mel poloautomaticky nastroj na takovehle
spojovani, tak by to asi nebylo spatne. On boj s josma relacema neni
uplne trivialni, a nejsem si jisty jestli to vzdycky udelam
korektne...
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

Re: [OSM-talk-fr] Comment traduire les cartes

[Christian Rogel]

Le 16 mai 2016 à 03:22, Philippe Verdy  a écrit :
> 
> Pluisuers centaines de langues, tu exagères, même avec les variétés locales 
> des langues d'oïl et d'oc (qui forment un continuum et qu'il est d'autant 
> plus difificile de séparer qu'il n'y a même pas d'ortographe normalisée pour 
> bon nombre).

Mettons que plusieurs centaines soient un peu extrapolé, mais il y en a 
plusieurs dizaines uniquement en Nouvelle-Calédonie.
La normalisation endogène n'est pas le sujet, car, la normalisation 
administrative loufoque avec les phonèmes du français et les mécompréhensions 
ne changent pas la source originelle.

Christian R.

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

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Philippe Verdy]

Sauf que le choix de PostgreSQL n'est pas stupide étant donné ce qui est
demandé et déjà fourni:

- moniteur transactionnel anvec transaction log et recovery, backup et
réplication "live", gestion des caches, construction des index, niveau de
performance et de sécurité, concurrence d'accès très élevée, gestion des
supports de stockage, etc.
- le package GIS pour PostgreSQL et le support des recherches géométriques
par coordonnées
- les packages de transformation de géométrie.

Ca fait beaucoup à réécrire avec trop de bogues possibles pendant longtemps
(alors que PostgreSQL est stable et performant et bien maintenu) !

Certes Overpass n'étant qu'un outil d'interrogation, il n'a pas (ou pas
encore!) à gérer des mises à jour de la base de données OSM (exemple
sélectionner une liste d'objets, permettre la modification de certains
tags, faire des fusions ou conversion de tags, puis soumettre les objets
modifiés dans un ou plusieurs changeset au nom de l'utilisateur).

Il peut encore monter une copie read-only de la base OSM sans gestion des
transactions, mais il a besoin de transactions séparées pour l'exécution de
chaque requête et construire des index temporaires de sélection et les
combiner. Cependant sa base read-only doit aussi suivre l'intégration des
minute-diffs venant de la base principale pour rester synchronisée avec
elle. Les transactions évitent aussi une corruption totale et la
reconstruction complète à partir d'un planet dump (qui prend plusieurs
jours) en cas de plantage temporaire (il y a moyen de se resynchroniser
automatiquement en faisant un rollback des transactions incomplètes non
"committées" par les minute-diffs incomplètement chargés).

Overpass a besoin aussi des outils géométriques pour pas mal de ses
requêtes qui font des transformations (exemple: calcul de buffer, cacul
d'un centroïde).

Pour Overpass en revanche ce qui manque c'est juste un optimiseur de
requête permettant de calculer un plan d'exécution correct (car il est
clair que le plan d'exécution fait par Overpass est mauvais et oblige à
faire de multiples requêtes très lourdes à la base OSM principale pour
ensuite appliquer localement sur son propre serveur des fusions et filtres.

Le problème n'est pas dans la base OSM elle-même mais bien dans OverPass
(sur ses propres serveurs) :
- la façon dont il analyse les requêtes utilisateur pour les transformer en
requêtes avec la base principale (même s'il en dispose localement d'une
copie répliquée pour éviter de faire des requêtes distantes d'un pays à
l'autre, puisque Overpass est installé en Allemagne, en France et en Russie
mais la base OSM principale en Angleterre: les "lags" seraient beaucoup
trop longs et en plus la quantité de données qu"'Overpass demanderait à la
base principale serait trop élevée par rapport aux requêtes standards par
l'API sur des régions bien plus limitées)
- ou la façon dont il gère des caches de données pour les requêtes
courantes (sa gestion des "areas" n'est qu'une solution paliative pour une
partie spécifique d'un problème en fait plus général).


Le 16 mai 2016 à 21:20, Bruno  a écrit :

> Le 16/05/2016 17:59, Philippe Verdy a écrit :
> Bonjour,
>
> Pour ma part je pense qu'une base NoSQL sur une architecture distribuée
> serait une solution plus perenne, plus performante et avec moins de
> contraintes de schéma préétabli que les bases SQL.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Confini Parco Regionale Monti Simbruini

[Cascafico Giovanni]

Ricalcare da immagini protette dalla *© *(*"*C" cerchiata) potrebbe ledere
i diritti di opera intellettuale. Meglio contattare il sito che ha
pubblicato la mappa. Sull'esistenza del poligono del parco, hai ragione: la
query [1] non ha dato risultati di relazioni con nome "Monti Simbruini".

[1] http://overpass-turbo.eu/s/gfH

Il giorno 16 maggio 2016 21:39, Croce Domenico 
ha scritto:

> incappo in problemi di licenza anche se volgarmente "ricalco" i confini di
> quella mappa?!?
> la mappa è questa: http://www.parks.it/parco.monti.simbruini/mapl.php
> perdona l'ignoranza, ma come posso controllare l'esistenza di una
> relazione con un area che ancora non esiste?  puoi rigirarmi qualche guida
> specifica...se esiste?   GRAZIE
>
> Il giorno 16 maggio 2016 21:17, Cascafico Giovanni 
> ha scritto:
>
>> Ciao. Oltre ad un certo numero di nodi JOSM considera l'operazione
>> anomala, credo a volte causata da errori di copia tra layer. Non me ne
>> preoccuperei. Piuttosto, verifica che non esista già una relazione e
>> soprattutto, considerando quel "trovato su internet", verifica la
>> compatibilità della licenza.
>>
>> --
>> cascafico.altervista.org
>> twitter.com/cascafico
>> Il 16/mag/2016 20:44 "Croce Domenico"  ha
>> scritto:
>>
>>> Salve a tutti, ho trovato su internet una cartina del parco, che poi ho
>>> georeferenziato ed ho usato come fonte per creare i confini... ho seguito
>>> ovviamente la procedura su wiki riguardo i tag, ma josm mi "sconsiglia
>>> fortemente" di inviare al server questo cambiamento...   sbaglio qualcosa??
>>> Meglio che lascio stare??? Eventualmente dovrei crearla come area
>>> multipoligono e rivedere la varie relazioni???   GRAZIE
>>>
>>> ___
>>> 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
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] openstreetmap.de down?

[Walter Nordmann]

Klaro. das eS ist irgendwo leider verschütt gegangen. Aber die Liste 
selber und auch openstreemap.de war heute Nachmittag echt zäh. Warten 
bis zum Timeout.


Danke und Gruss
walter

Am 16.05.2016 um 15:43 schrieb Sarah Hoffmann:

On Mon, May 16, 2016 at 03:02:26PM +0200, Walter Nordmann wrote:

Hi, wollte gerade auf list.openstreetmap.de zugreifen:

|ping list.openstreetmap.de ping: unknown host list.openstreetmap.de|

Und die Webseite meldet sich im Browser auch nicht.

Trouble?

Versuch es mal mit: lists.openstreetmap.de
 ^

Gruss

Sarah

___
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: [OSM-talk] SSL cert *.openstreetmap.fr expired

[Christian Quest]

We're switching to letsencrypt on all our servers.

I check with umap is not switched yet...

2016-05-16 20:41 GMT+02:00 Johannes Visintini :

> Hey,
>
> the SSL certificate for https://umap.openstreetmap.fr expired
> yesterday. Is someone here who can fix this?
>
> Maybe this is a good moment for thinking about deploying letsencrypt ;)
>
> Greets
> Johannes
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



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

Re: [Talk-it] Confini Parco Regionale Monti Simbruini

[Croce Domenico]

incappo in problemi di licenza anche se volgarmente "ricalco" i confini di
quella mappa?!?
la mappa è questa: http://www.parks.it/parco.monti.simbruini/mapl.php
perdona l'ignoranza, ma come posso controllare l'esistenza di una relazione
con un area che ancora non esiste?  puoi rigirarmi qualche guida
specifica...se esiste?   GRAZIE

Il giorno 16 maggio 2016 21:17, Cascafico Giovanni  ha
scritto:

> Ciao. Oltre ad un certo numero di nodi JOSM considera l'operazione
> anomala, credo a volte causata da errori di copia tra layer. Non me ne
> preoccuperei. Piuttosto, verifica che non esista già una relazione e
> soprattutto, considerando quel "trovato su internet", verifica la
> compatibilità della licenza.
>
> --
> cascafico.altervista.org
> twitter.com/cascafico
> Il 16/mag/2016 20:44 "Croce Domenico"  ha
> scritto:
>
>> Salve a tutti, ho trovato su internet una cartina del parco, che poi ho
>> georeferenziato ed ho usato come fonte per creare i confini... ho seguito
>> ovviamente la procedura su wiki riguardo i tag, ma josm mi "sconsiglia
>> fortemente" di inviare al server questo cambiamento...   sbaglio qualcosa??
>> Meglio che lascio stare??? Eventualmente dovrei crearla come area
>> multipoligono e rivedere la varie relazioni???   GRAZIE
>>
>> ___
>> 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-it] Confini Parco Regionale Monti Simbruini

[Croce Domenico]

per georeferenziato intendo, che questa mappa jpeg, l'ho aperta su okmap,
gli ho impostato 3 coordinate su 3 punti...l'ho poi aperta per controllo su
google earth per vedere se combaciava, e quindi assicuratomi che fosse
correttamente georeferenziata ho usato i confini per creare una traccia
gpx, che poi ho convertito in area.  Ovviamente non ho ancora inviato nulla
al server..

i tag che ho usato sono quelli consigliati in questa lista:
http://wiki.openstreetmap.org/wiki/IT:Emilia_Romagna_parchi

inserendo le varie informazioni trovate qui:
https://it.wikipedia.org/wiki/Parco_naturale_regionale_dell%27Appennino_-_Monti_Simbruini

grazie ancora

Il giorno 16 maggio 2016 20:46, girarsi_liste  ha
scritto:

> Il 16/05/2016 20:43, Croce Domenico ha scritto:
> > Salve a tutti, ho trovato su internet una cartina del parco, che poi ho
> > georeferenziato ed ho usato come fonte per creare i confini...
>
> In che maniera, puoi essere un pò più chiaro per georeferenziato?
>
>
> > ho seguito
> > ovviamente la procedura su wiki riguardo i tag, ma josm mi "sconsiglia
> > fortemente" di inviare al server questo cambiamento...   sbaglio
> qualcosa??
> > Meglio che lascio stare??? Eventualmente dovrei crearla come area
> > multipoligono e rivedere la varie relazioni???   GRAZIE
>
>
> Quali tag?
>
> Sei sibillino sai? :)
>
>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> 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] Timeout avec OverpassT : alternative?

[Bruno]

Le 16/05/2016 17:59, Philippe Verdy a écrit :
personnelmement je trouve que la façon dont est géré le paramètre 
bounding box est plutôt mal fichu: globalement ça fait deux sélections 
d'objets puis une intersection, mais sur une bounding box très grande 
c'est ridicule car une des listes d'objets est beaucoup trop volumineuse.


Au delà d'une certaines surface (à déterminer, laquelle peut aussi 
s'appuyer sur des données statistiques partiellles précalculées sur la 
densité d'un certain nombre de "quad-tiles" pour estimer le nombre 
d'objets ou juste de noeuds inclus dans la bounding box), il ne 
faudrait pas procéder par fusion de deux listes mais par récursion en 
filtrant directement la première liste obtenue par la sélection des 
autres tags.


Il manque à OverPass ce qui est fait dans les bases de données 
relationnelles : un optimiseur statistique de requêtes pour estimer la 
sélectivité et calculer ce qu'on appelle un "plan d'exécution" adéquat.


Les optimiseurs statistiques de bases relationnelles ne font pas que 
ça, ils estiment aussi la sélectivité des index quand on a le choix 
pour une table, et savoir s'il est nécessaire de faire une jointure 
entre l'index et la table pour trouver les autres colonnes nécessaires 
aux filtres (clauses WHERE, GROUP BY/aggrégats) puis au tri final 
(ORDER BY: faut-il créer un index temporaire contenant les clés de 
tri, ou une table temporaire contenant aussi les colonnes de 
résultat), il estiment aussi le volume en I/O (tailles moyenne des 
rangées de données).


[ De tels optimiseurs sont très compliqués à écrire, les règles sont 
d'autant plus complexes que cela dépend aussi de la représentation 
interne des tables et index, de leur codage en terme de compression, 
etc : il faut de bons estimateurs, et parfois aussi maintenir des 
données statistiques de sélectivité (ce qui nécessite un petit peu de 
stockage en plus pour chaque index). Certains moteurs SQL tiennent 
compte aussi de l'usage fait et gèrent des caches statistiques pour 
s'adapter à la demande (ce n'est pas parce qu'un index existe qu'il 
est souvent utilisé, certaines mises à jour d'index peuvent être 
retardées pour aller plus vite sur les mises à jour de tables ou 
d'autres index). ]


En absence de tel optimiseur statistique (au moins minimal sans aller 
jusqu'à l'estimation exacte des I/O, car les données élémentaires 
manipulées ont des tailles très peu variables, hormi le nombre de 
noeuds dans un chemin), OverPass devrait uniquement s'appuyer sur la 
façon dont on écrit la requête pour savoir si on fait des 
intersections de listes ou des récursions par filtre et pour ordonner 
les filtres (l'utilisateur écrivant la requête ayant alors une 
meilleure connaissance de la sélectivité des différents filtres.


Un bon optimiseur pour OverPass en revanche devrait s'appuyer 
directement sur les "quadtiles", en précédant par division successive 
de l'espace rectangulaire de la sélection pour déterminer s'il faut 
procéder dans chaque quadtile par fusion de listes ou par récursion 
sur les quadtiles de niveau inférieur et filtrage à ce niveau. 
Cependant cela demanderait aussi d'intégrer une partie de ce 
traitement directement sur la base SQL d'objets OSM (ou sa copie 
locale), cela demanderait une modification du schéma physique (surtout 
concernant les relations et chemins qu devraient intégrer leur propre 
"bounding box" précalculée sans nécessiter une récursion; sinon gérer 
un cache de "bounding box", pour chaque chemin ou relation).


Actuellement Overpass ne gère qu'un seul cache précalculé : les 
"areas" (qui ont le défaut d'être souvent désynchronisés car ça dépend 
d'un bot de mise à jour qui peut parfois avoir plusieurs jours de 
décalage avec les données réelles, il n'y a pas de calcul à la demande 
avec des caches ayant des durées d'expiration raisonnables, et le bot 
fait en fait trop de travail pour rien sur des areas que personne ou 
presque n'utilise dans des requêtes). Mais ça ne répond pas 
correctement aux besoins. Ces "areas" d'OverPass sont plus souvent une 
gêne qu'elles ne sont utiles, leur coût en terme de charge des 
serveurs Overpass est disproportionné : ces "areas" précalculées 
devraient être abandonnées pour utiliser à la place une génération "à 
la demande" (avec un cache raisonnable d'au moins quelques heures afin 
de prévenir les surcharges serveur du fait de requêtes répétées sur 
des géométries complexes comme les frontières de pays, ou de grandes 
régions, ou d'Etats d'une fédération).


Il faut bien voir que la façon dont les données OSM sont stockées "en 
vrac" dans une base SQL ne leur permet pas d'utiliser les filtres 
classiques SQL permettant à l'optimiseru statistique de fonctionner 
(les différents "tags" d'OSM" ne sont pas des colonnes séparées en 
SQL), et en fait les jointures sont faites à l'aide de tables 
temporaires construites par OverPass, dans l'ordre qu'il détermine 
lui-même (un ordre qui est un peu trop fait "à l'arrache").

Re: [Talk-it] Mappare un materasso

[Maurizio Napolitano]

2016-05-16 20:37 GMT+02:00 Dario Crespi :
> Immaginavo che per i negozi fosse sbagliato.

onestamente non sono proprio convinto che sia un errore
anzi! sono più convinto che sia un errore usarlo per indicare il materasso
del salto in alto o con l'asta.
quantomeno, fra le combinazioni associate a "mattress"
http://taginfo.openstreetmap.org/keys/mattress#combinations
non mi risulta ci sia qualcosa che abbia a che vedere con lo sport

> Comunque ho mappato così (indicando anche per quale disciplina viene
> utilizzato).
> https://www.openstreetmap.org/way/418650185#map=19/45.62961/8.89167
> Può andare?

Guardando la pagina wiki sullo sport
http://wiki.openstreetmap.org/wiki/Tag:sport%3Dathletics
vedo che ci sono i tag il salto in alto
athletics:high_jump=yes
solo che, in tutto in mondo, ci sono solo due casi
http://overpass-turbo.eu/s/gfB

.. in ogni caso andrei in quella direzione

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

Re: [Talk-it] Mappare un materasso

[girarsi_liste]

Dimenticavo, per la pista di atletica, fatti un multipoligono. (lo so nn
si mapa per il rederer, ma io ho fatto così[0])


[0] http://www.openstreetmap.org/relation/5227213#map=19/46.05038/11.46931
-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [Talk-it] Confini Parco Regionale Monti Simbruini

[girarsi_liste]

Il 16/05/2016 20:43, Croce Domenico ha scritto:
> Salve a tutti, ho trovato su internet una cartina del parco, che poi ho
> georeferenziato ed ho usato come fonte per creare i confini...

In che maniera, puoi essere un pò più chiaro per georeferenziato?


> ho seguito
> ovviamente la procedura su wiki riguardo i tag, ma josm mi "sconsiglia
> fortemente" di inviare al server questo cambiamento...   sbaglio qualcosa??
> Meglio che lascio stare??? Eventualmente dovrei crearla come area
> multipoligono e rivedere la varie relazioni???   GRAZIE


Quali tag?

Sei sibillino sai? :)


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



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

[Talk-it] Confini Parco Regionale Monti Simbruini

[Croce Domenico]

Salve a tutti, ho trovato su internet una cartina del parco, che poi ho
georeferenziato ed ho usato come fonte per creare i confini... ho seguito
ovviamente la procedura su wiki riguardo i tag, ma josm mi "sconsiglia
fortemente" di inviare al server questo cambiamento...   sbaglio qualcosa??
Meglio che lascio stare??? Eventualmente dovrei crearla come area
multipoligono e rivedere la varie relazioni???   GRAZIE
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Mappare un materasso

[girarsi_liste]

Il 16/05/2016 20:37, Dario Crespi ha scritto:
> Immaginavo che per i negozi fosse sbagliato.
> Comunque ho mappato così (indicando anche per quale disciplina viene
> utilizzato).
> https://www.openstreetmap.org/way/418650185#map=19/45.62961/8.89167
> Può andare?
> 
> Dario
> 

Il problema è che sport=* implica leisure=* a mio parere, ma qui è
impossibile credo.

Forse un man_made=mattress?


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



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

[OSM-talk] SSL cert *.openstreetmap.fr expired

[Johannes Visintini]

Hey,

the SSL certificate for https://umap.openstreetmap.fr expired
yesterday. Is someone here who can fix this?

Maybe this is a good moment for thinking about deploying letsencrypt ;)

Greets
Johannes

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

Re: [Talk-it] Mappare un materasso

[Dario Crespi]

Immaginavo che per i negozi fosse sbagliato.
Comunque ho mappato così (indicando anche per quale disciplina viene
utilizzato).
https://www.openstreetmap.org/way/418650185#map=19/45.62961/8.89167
Può andare?

Dario

Il giorno 16 maggio 2016 20:28, girarsi_liste  ha
scritto:

> Il 16/05/2016 20:16, Dario Crespi ha scritto:
> > Noto però che Mattress=yes è usato per negozi (che vendono materassi?) e
> > nei rifugi (forse per indicare che ci sono letti con materassi?).
> >
> > Dario
> >
>
> Nei negozi se vendono ANCHE materasi, dovrebbe essere
> sells:mattress=yes, perchè sennò è sbagliato dal mio punto di vista
> senza sells.
>
> Per i rifugi, probabile intenda letti "comodi" e non stanze senza letti,
> per sacchi a pelo.
>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> 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] Mappare un materasso

[girarsi_liste]

Il 16/05/2016 20:16, Dario Crespi ha scritto:
> Noto però che Mattress=yes è usato per negozi (che vendono materassi?) e
> nei rifugi (forse per indicare che ci sono letti con materassi?).
> 
> Dario
> 

Nei negozi se vendono ANCHE materasi, dovrebbe essere
sells:mattress=yes, perchè sennò è sbagliato dal mio punto di vista
senza sells.

Per i rifugi, probabile intenda letti "comodi" e non stanze senza letti,
per sacchi a pelo.

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



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

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Shohreh]

Merci!



--
View this message in context: 
http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617p5873637.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-ca] Water area (blue) turns white

[Pierre Béland]

Plusieurs contributeurs sont a faire des modifications au polygone du 
Lac-des-deux-Montagnes. Cela va dans tous les sens et le polygone n'est 
maintenant plus fermé.
Svp venez discuter avant de modifier et enlever des sections.Je vois le 
contributeur Boff II qui a effacé une section sans commentaire dans son 
changeset.https://www.openstreetmap.org/changeset/39357069
  
Pierre 


  De : Pierre Béland 
 À : Adam Martin ; Pierre Boucher 
 
Cc : "talk-ca@openstreetmap.org" 
 Envoyé le : lundi 16 mai 2016 12h00
 Objet : Re: [Talk-ca] Water area (blue) turns white
   
Malgré l'ajout de l'Ile Rita dans la relation Lac-des-deux-Montagnes, puis 
forcé affichage en demandant révision des tuiles png (par exemple 
https://b.tile.openstreetmap.org/17/38477/46892.png/dirty)
toujours pas d'affichage de l'Ile.
Je crois que ceci est dû à un conflit avec le polygone de la Rivière Rigaud. Ce 
polygone inclue une partie du lac incluant l'Ile Rita. De plus, le chemin est 
dans le mauvais sens. Pour les polygones délimitant les cours d'eau, la terre 
doit toujours être à gauche. Je vais corriger.
  
Pierre 


  De : Pierre Béland 
 À : Adam Martin ; Pierre Boucher 
 
Cc : "talk-ca@openstreetmap.org" 
 Envoyé le : lundi 16 mai 2016 10h20
 Objet : Re: [Talk-ca] Water area (blue) turns white
  
Dans JOSM,
L'Édition de la relation Deux-Montagnes, id=128586647
m'indique que les roles outer forment bien un polygone fermé. L'Ile Rita dans 
la Baie de Rigaud était absente de la relation. Je l'ai ajoutée.

  
Pierre 


  De : Adam Martin 
 À : Pierre Boucher  
Cc : "talk-ca@openstreetmap.org" 
 Envoyé le : lundi 16 mai 2016 9h44
 Objet : Re: [Talk-ca] Water area (blue) turns white
  
Something odd is going on with that area. If you look carefully at the lake at 
the closer zoom, the lower left side is filled in correctly and the rest is 
blank. Also, the Isle just above that (Île de Carillon) is displaying as water 
and it should be as land (inner portion of Lac des Deux-Montagnes). I traced 
the entire outer lake relation and it appears to be intact. The only oddity 
that I see is in that lower left portion 
-(https://www.openstreetmap.org/#map=16/45.4975/-74.3210). In iD, it looks like 
this (https://www.openstreetmap.org/edit#map=16/45.4992/-74.3287). Selecting 
that line indicates that this is defining the outer boundary of the La rivière 
Rigaud. I imagine that these are interrupting each other in some manner. That 
polygon structure may have recently been imported considering the line for this 
"river" runs completely straight across this section of the lake and into the 
ground there (still straight) and I am getting some trees rendered in that 
"river" area. Edit history there indicates that a user named Boff II 
(https://www.openstreetmap.org/user/Boff%20II) made changes to the Lake 13 
hours ago. Maybe he had something to do with it? Try contacting him.

Adam

On Mon, May 16, 2016 at 10:17 AM, Pierre Boucher  wrote:

  Please help, Someone pull the plug at the buttom of Lac des Deux-Montagnes in 
Oka, Quebec (could be me or someone else trying to improve the map) The water 
area (blue at a zoom of 2km) dissapear (turns white at 1km zoom and closer).  A 
month ago everything was ok ( i guess ). Can somebody help?
  https://www.openstreetmap.org/#map=12/45.4523/-74.1172
  Pierre Boucher  (Boff II in OSM)   
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca




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


   

   

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

Re: [OSM-talk] Slipways connected to highways

[Clifford Snow]

I just wanted to make sure that I haven't been tagging slipways wrong.

You are correct, I've had success with both JOSM and iD in getting bugs
fixed. The developers are awesome.

On Mon, May 16, 2016 at 9:36 AM, Andy Townsend  wrote:

> On 16/05/2016 17:30, Clifford Snow wrote:
>
>> I've always added slipways to the last node of a service road. Now JOSM
>> is complaining of leisure=slipway connected to a highway. It seem logical
>> to me that the if you wanted to get routing to a boat launch that the node
>> would be on the highway. How do others tag slipways?
>>
>
> I had a look at "how people tagged slipways" a week or so ago in answer to
> a question (either an IRC or a "help" one ) and most people do that too.
>
> If the JOSM validator is wrong, raise a bug on JOSM trac with the JOSM
> validator. I've always found the developers there very helpful about fixing
> such issues.
>
> Cheers,
>
> Andy
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Slipways connected to highways

[Andy Townsend]

On 16/05/2016 17:30, Clifford Snow wrote:
I've always added slipways to the last node of a service road. Now 
JOSM is complaining of leisure=slipway connected to a highway. It seem 
logical to me that the if you wanted to get routing to a boat launch 
that the node would be on the highway. How do others tag slipways?


I had a look at "how people tagged slipways" a week or so ago in answer 
to a question (either an IRC or a "help" one ) and most people do that too.


If the JOSM validator is wrong, raise a bug on JOSM trac with the JOSM 
validator. I've always found the developers there very helpful about 
fixing such issues.


Cheers,

Andy


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

[OSM-talk] Slipways connected to highways

[Clifford Snow]

I've always added slipways to the last node of a service road. Now JOSM is
complaining of leisure=slipway connected to a highway. It seem logical to
me that the if you wanted to get routing to a boat launch that the node
would be on the highway. How do others tag slipways?

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] Water area (blue) turns white

[Pierre Béland]

Malgré l'ajout de l'Ile Rita dans la relation Lac-des-deux-Montagnes, puis 
forcé affichage en demandant révision des tuiles png (par exemple 
https://b.tile.openstreetmap.org/17/38477/46892.png/dirty)
toujours pas d'affichage de l'Ile.
Je crois que ceci est dû à un conflit avec le polygone de la Rivière Rigaud. Ce 
polygone inclue une partie du lac incluant l'Ile Rita. De plus, le chemin est 
dans le mauvais sens. Pour les polygones délimitant les cours d'eau, la terre 
doit toujours être à gauche. Je vais corriger.
  
Pierre 


  De : Pierre Béland 
 À : Adam Martin ; Pierre Boucher 
 
Cc : "talk-ca@openstreetmap.org" 
 Envoyé le : lundi 16 mai 2016 10h20
 Objet : Re: [Talk-ca] Water area (blue) turns white
   
Dans JOSM,
L'Édition de la relation Deux-Montagnes, id=128586647
m'indique que les roles outer forment bien un polygone fermé. L'Ile Rita dans 
la Baie de Rigaud était absente de la relation. Je l'ai ajoutée.

  
Pierre 


  De : Adam Martin 
 À : Pierre Boucher  
Cc : "talk-ca@openstreetmap.org" 
 Envoyé le : lundi 16 mai 2016 9h44
 Objet : Re: [Talk-ca] Water area (blue) turns white
  
Something odd is going on with that area. If you look carefully at the lake at 
the closer zoom, the lower left side is filled in correctly and the rest is 
blank. Also, the Isle just above that (Île de Carillon) is displaying as water 
and it should be as land (inner portion of Lac des Deux-Montagnes). I traced 
the entire outer lake relation and it appears to be intact. The only oddity 
that I see is in that lower left portion 
-(https://www.openstreetmap.org/#map=16/45.4975/-74.3210). In iD, it looks like 
this (https://www.openstreetmap.org/edit#map=16/45.4992/-74.3287). Selecting 
that line indicates that this is defining the outer boundary of the La rivière 
Rigaud. I imagine that these are interrupting each other in some manner. That 
polygon structure may have recently been imported considering the line for this 
"river" runs completely straight across this section of the lake and into the 
ground there (still straight) and I am getting some trees rendered in that 
"river" area. Edit history there indicates that a user named Boff II 
(https://www.openstreetmap.org/user/Boff%20II) made changes to the Lake 13 
hours ago. Maybe he had something to do with it? Try contacting him.

Adam

On Mon, May 16, 2016 at 10:17 AM, Pierre Boucher  wrote:

  Please help, Someone pull the plug at the buttom of Lac des Deux-Montagnes in 
Oka, Quebec (could be me or someone else trying to improve the map) The water 
area (blue at a zoom of 2km) dissapear (turns white at 1km zoom and closer).  A 
month ago everything was ok ( i guess ). Can somebody help?
  https://www.openstreetmap.org/#map=12/45.4523/-74.1172
  Pierre Boucher  (Boff II in OSM)   
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca




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


   

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

Re: [Talk-de] openstreetmap.de down?

[Manfred A. Reiter]

Hallo Sarah,

aber auch die list*s* war eine Zeit lang nicht errichbar ;-)

LG

Manfred

Am 16. Mai 2016 um 15:43 schrieb Sarah Hoffmann :

> On Mon, May 16, 2016 at 03:02:26PM +0200, Walter Nordmann wrote:
> > Hi, wollte gerade auf list.openstreetmap.de zugreifen:
> >
> > |ping list.openstreetmap.de ping: unknown host list.openstreetmap.de|
> >
> > Und die Webseite meldet sich im Browser auch nicht.
> >
> > Trouble?
>
> Versuch es mal mit: lists.openstreetmap.de
> ^
>
> Gruss
>
> Sarah
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>



-- 
## Manfred Reiter - -
## www.weeklyOSM.eu
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Philippe Verdy]

personnelmement je trouve que la façon dont est géré le paramètre bounding
box est plutôt mal fichu: globalement ça fait deux sélections d'objets puis
une intersection, mais sur une bounding box très grande c'est ridicule car
une des listes d'objets est beaucoup trop volumineuse.

Au delà d'une certaines surface (à déterminer, laquelle peut aussi
s'appuyer sur des données statistiques partiellles précalculées sur la
densité d'un certain nombre de "quad-tiles" pour estimer le nombre d'objets
ou juste de noeuds inclus dans la bounding box), il ne faudrait pas
procéder par fusion de deux listes mais par récursion en filtrant
directement la première liste obtenue par la sélection des autres tags.

Il manque à OverPass ce qui est fait dans les bases de données
relationnelles : un optimiseur statistique de requêtes pour estimer la
sélectivité et calculer ce qu'on appelle un "plan d'exécution" adéquat.

Les optimiseurs statistiques de bases relationnelles ne font pas que ça,
ils estiment aussi la sélectivité des index quand on a le choix pour une
table, et savoir s'il est nécessaire de faire une jointure entre l'index et
la table pour trouver les autres colonnes nécessaires aux filtres (clauses
WHERE, GROUP BY/aggrégats) puis au tri final (ORDER BY: faut-il créer un
index temporaire contenant les clés de tri, ou une table temporaire
contenant aussi les colonnes de résultat), il estiment aussi le volume en
I/O (tailles moyenne des rangées de données).

[ De tels optimiseurs sont très compliqués à écrire, les règles sont
d'autant plus complexes que cela dépend aussi de la représentation interne
des tables et index, de leur codage en terme de compression, etc : il faut
de bons estimateurs, et parfois aussi maintenir des données statistiques de
sélectivité (ce qui nécessite un petit peu de stockage en plus pour chaque
index). Certains moteurs SQL tiennent compte aussi de l'usage fait et
gèrent des caches statistiques pour s'adapter à la demande (ce n'est pas
parce qu'un index existe qu'il est souvent utilisé, certaines mises à jour
d'index peuvent être retardées pour aller plus vite sur les mises à jour de
tables ou d'autres index). ]

En absence de tel optimiseur statistique (au moins minimal sans aller
jusqu'à l'estimation exacte des I/O, car les données élémentaires
manipulées ont des tailles très peu variables, hormi le nombre de noeuds
dans un chemin), OverPass devrait uniquement s'appuyer sur la façon dont on
écrit la requête pour savoir si on fait des intersections de listes ou des
récursions par filtre et pour ordonner les filtres (l'utilisateur écrivant
la requête ayant alors une meilleure connaissance de la sélectivité des
différents filtres.

Un bon optimiseur pour OverPass en revanche devrait s'appuyer directement
sur les "quadtiles", en précédant par division successive de l'espace
rectangulaire de la sélection pour déterminer s'il faut procéder dans
chaque quadtile par fusion de listes ou par récursion sur les quadtiles de
niveau inférieur et filtrage à ce niveau. Cependant cela demanderait aussi
d'intégrer une partie de ce traitement directement sur la base SQL d'objets
OSM (ou sa copie locale), cela demanderait une modification du schéma
physique (surtout concernant les relations et chemins qu devraient intégrer
leur propre "bounding box" précalculée sans nécessiter une récursion; sinon
gérer un cache de "bounding box", pour chaque chemin ou relation).

Actuellement Overpass ne gère qu'un seul cache précalculé : les "areas"
(qui ont le défaut d'être souvent désynchronisés car ça dépend d'un bot de
mise à jour qui peut parfois avoir plusieurs jours de décalage avec les
données réelles, il n'y a pas de calcul à la demande avec des caches ayant
des durées d'expiration raisonnables, et le bot fait en fait trop de
travail pour rien sur des areas que personne ou presque n'utilise dans des
requêtes). Mais ça ne répond pas correctement aux besoins. Ces "areas"
d'OverPass sont plus souvent une gêne qu'elles ne sont utiles, leur coût en
terme de charge des serveurs Overpass est disproportionné : ces "areas"
précalculées devraient être abandonnées pour utiliser à la place une
génération "à la demande" (avec un cache raisonnable d'au moins quelques
heures afin de prévenir les surcharges serveur du fait de requêtes répétées
sur des géométries complexes comme les frontières de pays, ou de grandes
régions, ou d'Etats d'une fédération).

Il faut bien voir que la façon dont les données OSM sont stockées "en vrac"
dans une base SQL ne leur permet pas d'utiliser les filtres classiques SQL
permettant à l'optimiseru statistique de fonctionner (les différents "tags"
d'OSM" ne sont pas des colonnes séparées en SQL), et en fait les jointures
sont faites à l'aide de tables temporaires construites par OverPass, dans
l'ordre qu'il détermine lui-même (un ordre qui est un peu trop fait "à
l'arrache").


Le 16 mai 2016 à 16:13, Christian Quest  a écrit :

> Sur un très grand BBOX un timeout de 60 est très 

Re: [Talk-it] Mappare un materasso

[dgitto]

Ma lo lasciano sempre lì anche di notte? Beh comunque è bello che ci si occupi delle cose più svariate.
Il 16/mag/2016 17:20, Dario Crespi  ha scritto:Dall'oggetto della mail sembra una cosa stupida, ma esiste in tag per mappare un materasso? Ovviamente non mi riferisco a quelli per dormire, ma a quelli che nei campi di atletica leggera vengono usati per il salto con l'asta e per il salto in alto.
Se, come penso, non esiste un tag ad hoc, come fare per inserirli su OSM?
Dario
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Mappare un materasso

[Dario Crespi]

Dall'oggetto della mail sembra una cosa stupida, ma esiste in tag per
mappare un materasso? Ovviamente non mi riferisco a quelli per dormire, ma
a quelli che nei campi di atletica leggera vengono usati per il salto con
l'asta e per il salto in alto.

Se, come penso, non esiste un tag ad hoc, come fare per inserirli su OSM?

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

Re: [Talk-ca] Water area (blue) turns white

[Pierre Béland]

Dans JOSM,
L'Édition de la relation Deux-Montagnes, id=128586647
m'indique que les roles outer forment bien un polygone fermé. L'Ile Rita dans 
la Baie de Rigaud était absente de la relation. Je l'ai ajoutée.

  
Pierre 


  De : Adam Martin 
 À : Pierre Boucher  
Cc : "talk-ca@openstreetmap.org" 
 Envoyé le : lundi 16 mai 2016 9h44
 Objet : Re: [Talk-ca] Water area (blue) turns white
   
Something odd is going on with that area. If you look carefully at the lake at 
the closer zoom, the lower left side is filled in correctly and the rest is 
blank. Also, the Isle just above that (Île de Carillon) is displaying as water 
and it should be as land (inner portion of Lac des Deux-Montagnes). I traced 
the entire outer lake relation and it appears to be intact. The only oddity 
that I see is in that lower left portion 
-(https://www.openstreetmap.org/#map=16/45.4975/-74.3210). In iD, it looks like 
this (https://www.openstreetmap.org/edit#map=16/45.4992/-74.3287). Selecting 
that line indicates that this is defining the outer boundary of the La rivière 
Rigaud. I imagine that these are interrupting each other in some manner. That 
polygon structure may have recently been imported considering the line for this 
"river" runs completely straight across this section of the lake and into the 
ground there (still straight) and I am getting some trees rendered in that 
"river" area. Edit history there indicates that a user named Boff II 
(https://www.openstreetmap.org/user/Boff%20II) made changes to the Lake 13 
hours ago. Maybe he had something to do with it? Try contacting him.

Adam

On Mon, May 16, 2016 at 10:17 AM, Pierre Boucher  wrote:

  Please help, Someone pull the plug at the buttom of Lac des Deux-Montagnes in 
Oka, Quebec (could be me or someone else trying to improve the map) The water 
area (blue at a zoom of 2km) dissapear (turns white at 1km zoom and closer).  A 
month ago everything was ok ( i guess ). Can somebody help?
  https://www.openstreetmap.org/#map=12/45.4523/-74.1172
  Pierre Boucher  (Boff II in OSM)   
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca




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


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

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Christian Quest]

Sur un très grand BBOX un timeout de 60 est très très insuffisant.

Deux solutions:
- l'augmenter (beaucoup)
- ne pas mettre de BBOX... dans ce cas overpass ne cherchera que via les
tags et sur un type d'objet aussi peu fré"quent que les centrales
nucléaires ça sera beaucoup plus rapide (testé, ça prend 20s)


[out:json][timeout:60];
(
  // query part for: “"generator:source"=nuclear”
  node["generator:source"="nuclear"];
  way["generator:source"="nuclear"];
  relation["generator:source"="nuclear"];
);
out center;




2016-05-16 14:55 GMT+02:00 Shohreh :

> Bonjour
>
> Je voulais récupérer la liste des centrales nucléaires en Europe et les
> importer dans une carte Umap, mais OT fait un time-out:
>
> 
> [out:json][timeout:60];
> (
>   // query part for: “"generator:source"=nuclear”
>   node["generator:source"="nuclear"]({{bbox}});
>   way["generator:source"="nuclear"]({{bbox}});
>   relation["generator:source"="nuclear"]({{bbox}});
> );
> out body;
> >;
> out skel qt;
>
> 
>
> An error occured during the execution of the overpass query! This is what
> overpass API returned:
> runtime error: Query timed out in "query" at line 12 after 61 seconds.
>
> 
>
> Y a-t-il une autre solution?
>
> Merci.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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: [Talk-de] openstreetmap.de down?

[Sarah Hoffmann]

On Mon, May 16, 2016 at 03:02:26PM +0200, Walter Nordmann wrote:
> Hi, wollte gerade auf list.openstreetmap.de zugreifen:
> 
> |ping list.openstreetmap.de ping: unknown host list.openstreetmap.de|
> 
> Und die Webseite meldet sich im Browser auch nicht.
> 
> Trouble?

Versuch es mal mit: lists.openstreetmap.de
^

Gruss

Sarah

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

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Pierre Béland]

Augmente le paramètre timeout, par exemple a 1200
[out:json][timeout:1200];  
Pierre 


  De : Shohreh 
 À : talk-fr@openstreetmap.org 
 Envoyé le : lundi 16 mai 2016 8h55
 Objet : [OSM-talk-fr] Timeout avec OverpassT : alternative?
   
Bonjour

Je voulais récupérer la liste des centrales nucléaires en Europe et les
importer dans une carte Umap, mais OT fait un time-out:


[out:json][timeout:60];
(
  // query part for: “"generator:source"=nuclear”
  node["generator:source"="nuclear"]({{bbox}});
  way["generator:source"="nuclear"]({{bbox}});
  relation["generator:source"="nuclear"]({{bbox}});
);
out body;
>;
out skel qt;



An error occured during the execution of the overpass query! This is what
overpass API returned:
runtime error: Query timed out in "query" at line 12 after 61 seconds.



Y a-t-il une autre solution?

Merci.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.html
Sent from the France mailing list archive at Nabble.com.

___
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-ca] Red Cross and Fort McMurray Fires

[Pierre Béland]

Paul
Jean-Guilhem Cailton et moi avons adressé une requête à Airbus pour qu'ils 
accordent une licence d'utilisation des données. Nous avons obtenu de telles 
autorisations déja pour motifs humanitaires.

Je suggère d'attendre une réponse de leur part avant de modifier les données. 
 
Pierre 


  De : Paul Norman 
 À : talk-ca@openstreetmap.org 
 Envoyé le : lundi 16 mai 2016 3h29
 Objet : Re: [Talk-ca] Red Cross and Fort McMurray Fires
   
 
 On 5/15/2016 4:00 PM, Dan Joseph wrote:
  
Hi, that url looks like the one from the gov't of Alberta web viewer. If that's 
the case it pretty clearly states on the welcome page (emphasis mine): 
 Satellite image source: Pléaides-1A © CNES 2016, Distribution AIRBUS DS, all 
rights reserved. Use of this imagery is subject to the Airbus Defence and Space 
Web License for Non-Commercial Use, January, 2015. Users may view the image; 
must not download, store, copy, transfer or reverse engineer the image in any 
way or use the image to create a database and/or a derivative work; and must 
contact AIRBUS DS to obtain a full license. Base Map Data provided by the 
Government of Alberta under the Alberta Open Government Licence. Cadastral and 
Dispositions Data provided by Alberta Data Partnerships. Other data are 
provided by the ministry of Alberta Environment and Parks (AEP). No base 
feature data can be reproduced or distributed without the prior written 
permission of the Government of Alberta.   
 Can you please clarify the source of the imagery and the licensing around it?
 
 Yes - that license is clearly incompatible with using with OSM as it 
explicitly prohibits what we do.
 
 Denis, how can I identify the changesets where you used that source?
 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


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

[Talk-de] openstreetmap.de down?

[Walter Nordmann]

Hi, wollte gerade auf list.openstreetmap.de zugreifen:

|ping list.openstreetmap.de ping: unknown host list.openstreetmap.de|

Und die Webseite meldet sich im Browser auch nicht.

Trouble?

Gruss
walter

ps: gerade hat ein Kollege bestätigt, dass er das gleiche Problem hat. 
Wir sind bei unterschiedlichen Providern, also solle es nicht daran 
liegen, dass eventuell DNS-Einträge veraltet sind.


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

[OSM-talk-fr] Timeout avec OverpassT : alternative?

[Shohreh]

Bonjour

Je voulais récupérer la liste des centrales nucléaires en Europe et les
importer dans une carte Umap, mais OT fait un time-out:


[out:json][timeout:60];
(
  // query part for: “"generator:source"=nuclear”
  node["generator:source"="nuclear"]({{bbox}});
  way["generator:source"="nuclear"]({{bbox}});
  relation["generator:source"="nuclear"]({{bbox}});
);
out body;
>;
out skel qt;



An error occured during the execution of the overpass query! This is what
overpass API returned:
runtime error: Query timed out in "query" at line 12 after 61 seconds.



Y a-t-il une autre solution?

Merci.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-co] Unidad de Mapeo Humanitario #UMH

[Fredy Rivera]

Hola Maperx

Gracias a tu apoyo logré ser un Titán Caracol y logramos visibilizar y
llamar la atención sobre nuestra comunidad. Ahora te invito a que me
acompañes  en una nueva etapa donde crearemos la Unidad de Mapeo
Humanitario (#UMH) con la comunidad de OpenStreetMap Colombia y otras
organizaciones amigas como #BrigadaDigital.

Hemos celebrado con la organización y los patrocinadores un acuerdo de
colaboración que nos asegura la adquisición de algunos de los equipos
requeridos para la creación de la #UMH.  Tu ayuda será muy importante
para completar  los equipos que necesitamos y contar con  la logística
para desplazamiento a trabajo de campo.

Aportaremos nuestra experiencia en la creación de mapas comunitarios
para la atención y prevención de emergencias.

Ya lo hicimos en Manatí durante la ola invernal, en Salgar por la
avalancha de la quebrada la Liboriana y en  la Guajira por la actual
crisis del agua. El resultado de este ejercicio quedará documentado en
el libro “Dragones en Emergencia” un manual para el mapeo comunitario
en situación de crisis.

El volcán cerro Machín es uno de los más peligrosos del mundo. Las
consecuencias de su erupción serán tan extremas que afectarán no sólo
a sus vecinos sino también a la economía del país y hasta el clima del
planeta.
Con la comunidad vecina del volcán y las autoridades locales
mejoraremos el mapa de riesgo. En el Machín se hará el primer
ejercicio con la #UMH, así nos prepararemos para ofrecer este mismo
equipo  donde se requiera ya sea dentro o fuera de Colombia.

Tu aporte y los mapas son vitales para acercar a la comunidad y
organismos de atención y prevención a la dimensión real de la crisis y
su atención.

Los aportes en dinero desde $10.000 pesos colombiano (3.5 dolares
aprox)  los recibiremos a través de la plataforma
http://ayudatutitan.com/fredy-rivera/ , si deseas hacer otro tipo de
aporte, comunícate con nosotros al correo proyec...@vivirenlafinca.org

Cuento  contigo!!!

Fredy Rivera
OpenStreetMap Colombia
#UMH

PD: También te invito a que compartas esta iniciativa en las redes sociales:
 https://www.facebook.com/titanfredyrivera/?fref=ts
 https://www.facebook.com/groups/OsmCol/?fref=ts
 @OpenStreetMapCo
 @vivierenlafinca
 @fredy_rivera
 HT #UMH

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

[Talk-ca] Water area (blue) turns white

[Pierre Boucher]

Please help,

Someone pull the plug at the buttom of Lac des Deux-Montagnes in Oka, 
Quebec (could be me or someone else trying to improve the map)


The water area (blue at a zoom of 2km) dissapear (turns white at 1km 
zoom and closer).  A month ago everything was ok ( i guess ).


Can somebody help?

https://www.openstreetmap.org/#map=12/45.4523/-74.1172

*/Pierre Boucher  (Boff II in OSM)/*

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

Re: [Talk-se] Automatiska edits ang. Statoil/CircleK

[Tomas Marklund]

På min lokala f.d. Statoilmack har personalen nya kläder, nya flaggor
hängdes upp i flaggstängerna redan dag ett och på de kvitton man får på
samtliga stationer i hela landet (verifierat med Circle K's kundtjänst)
står det redan nu "Circle K". Sen kommer de "hårda" skyltarna och
färgschemat på byggnaderna (det som Circle K kallar "profileringen") att
bytas ut löpande på mackarna under ett års tid.

Ska man sätta ett alt-name så borde det väl isåfall vara
"alt_name"="Statoil" (efter att ha bytt "name"="Cirkle K"), eftersom
mackarna formellt inte längre heter Statoil, men troligen i folkmun kommer
att kallas typ "statoilmacken vid rondellen" i många år framöver. Såvitt
jag har förstått är det precis för det syftet taggen alt_name är avsedd?

mvh Tomas

Den 13 maj 2016 19:51 skrev Andreas Vilén :

> Ja, mitt största problem var det som blev fel... Dvs butiker som
> antagligen inte alls drivs av Statoil längre utan är feltaggat från första
> början. Ingen hjälps av att felet blir mer fel, utan är det kvar på
> "felnivå 1" är det lättare att kontrollera i framtiden när alla legit
> taggade mackar bytt name-tagg manuellt.
>
> I de delar av Skåne jag rör mig har de flesta mackar bytt inredning,
> reklamskyltar och arbetskläder men inte de stora skyltarna och färgschema
> på pumpar och liknande.
>
> Vill man tvunget ändra nu är nog alt_name=Circle K den bästa lösningen.
> Att dubbeltagga med snedstreck enligt Eriks förslag är nog inte det bästa.
> Ska man tvunget ha två namn i name-taggen bör värdena som vanligt separeras
> med semikolon.
>
> Nu är alltså massredigeringarna återställda enligt Facebookposten:
> https://www.facebook.com/groups/osmsweden/permalink/1136965283041337/
>
> Om inte annat är det bra att medvetenhet om vilka problem som kan uppstå
> med automatiska redigeringar sprids även i den svenska gemenskapen. Jag
> blev själv frustrerad när jag blev ifrågasatt för en byggnadsimport för
> några år sedan, men efter att ha sett gott om skräckexempel på importer och
> massredigeringar så kan jag förstå varför nu.
>
> MVH Andreas
>
> 2016-05-13 19:24 GMT+02:00 Mikael Nordfeldth :
>
>> On 2016-05-13 14:39, Erik Johansson wrote:
>> > 2016-05-11 14:10 GMT+02:00 Tomas Marklund :
>> >> Jag erkänner, jag har felat. Jag kände inte till att ändringar av det
>> här
>> >
>> > Tycker själv det var en bra ändring, ingen större dramatik i att göra
>> > byråkratiska fel!  Ska vi tagga om till name="Statoil/Circle K", för
>> > så verkar fallet på de jag har sett. Är det någon annan som har ground
>> > truth checkat?
>>
>> Jag lyfte i alla fall en av dessa changesets på IRC eftersom jag
>> noterade att en massa ändringar gjordes i Umeå-regionen eftersom senast
>> jag kollade fanns det bara Statoil-varumärken längsmed vägarna.
>>
>> Nu har jag varit ute och kollat på en av mackarna specifikt för denna
>> diskussions syfte:
>> https://www.openstreetmap.org/#map=18/63.80246/20.31269
>>
>> Där sitter det förvisso ett par Circle K-flaggorn på flaggstångar, men
>> de syns knappt (de hänger mest neråt). Hela stationen är fortfarande blå
>> + orange med Statoil skrivet på samtliga namnplatser.
>>
>> Jag misstänker förstås att vi alltid är lite efter såhär i Norrland
>> eftersom vi inte är lika intressanta kommersiellt eller för varumärket.
>> Vilket är anledning nog att vänta med att ändra namn... Samt förstås att
>> alla av ren vana kommer att söka efter "Statoil" ett tag framåt om de är
>> vana att handla där :)
>>
>> alt_name="Circle K" hade jag varit okej med, samt att man absolut borde
>> kunna byta Operator-taggen. Risken är ju då dock att man ändrar på t.ex.
>> butiker som t.ex. inte alls drivs av Statoil utan av tredjepartfranchise
>> vilket inte upptäcks om man inte är ute och kikar själv ändå...
>>
>> --
>> Mikael Nordfeldth
>> https://blog.mmn-o.se/
>> XMPP/mail: m...@hethane.se
>> OpenPGP Fingerprint: AE68 9813 0B7C FCE3 B2FA 727B C7CE 635B B52E
>>
>>
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
>>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [OSM-talk-fr] Mapcontrib, logiciel

[Vincent Bergeot]

Bonjour,

merci pour les retours mais n'oublions pas dans ces remerciements :

 * Guillaume, qui développe le logiciel (et oui je ne sais pas écrire
   une ligne de code, c'est pour cela que j'ai besoin de mapcontrib !!!)
 * Frédéric, pour ses conseils sur osm et ses outils, qui sait donner
   les coups de pouce ou de rappels, et dont les discussions ont permis
   de faire apparaitre mapcontrib (après avoir tenté des choses sur
   amenity éditor, en roue libre, ...), avec l'envie de faire le pont
   avec osmose,


et puis spécial merci à Yohan Boniface et Noémie Lehuby qui, avec umap 
et openbeermap, nous ont donné plein d'idées et clin d'oeil à 
osm-hydrant qui nous a aussi inspiré (mais qui n'est pas libre, du moins 
la dernière fois que j'ai posé la question).


Bonne journée






Le 16/05/2016 07:35, Arnaud Vandecasteele a écrit :

Bonjour Vincent,

Un grand bravo pour ce logiciel !
C'est une très bonne idée.

Amicalement,

Arnaud

2016-05-13 18:09 GMT+04:00 Pierre-Yves Berrard 
>:


Le 13 mai 2016 à 10:42, Vincent Bergeot > a écrit :

Bonjour,
un mail pour vous présenter MapContrib, logiciel dont
l'objectif est de faciliter la contribution à OpenStreetMap
(par exemple sur des carto, avec des classes, et autres cadres
non imaginés !).

[...]

Guillaume Amat, Vincent Bergeot, Frédéric Rodrigo


Testé et approuvé !
http://www.openstreetmap.org/node/4183617935

Très sympa.


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




--

Arnaud Vandecasteele
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://geotribu.net/
http://about.me/arnaud_vandecasteele



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


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

Re: [OSM-talk-fr] Mapcontrib, logiciel

[Guillaume AMAT]

Étrange... À quelle adresse ?

Guillaume

Le 16 mai 2016 11:52:32 GMT+02:00, rainerU  a écrit :
>Ça a l'air très bien fait mais quand j’essaye de me connecter avec mon
>compte 
>OSM j'ai systématiquement une erreur "502 Bad Gateway"
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mapcontrib, logiciel

[rainerU]

Ça a l'air très bien fait mais quand j’essaye de me connecter avec mon compte 
OSM j'ai systématiquement une erreur "502 Bad Gateway"



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

[Talk-it] Database topografico Emilia con Licenza CC-BY

[bvivi]

A questo link c'è un articolo sull'aggiornamento del Database topografico 
dell'Emilia Romagna, con anche i numeri civici.
http://geoportale.regione.emilia-romagna.it/it/it/notizie/geoportale-emilia-romagna/database-topografico-regionale-pubblicati-gli-strati-relativi-ad-accessi-e-numerazione-civica-con-licenza-cc-by

Con la Licenza CC-BY è utilizzabile in OSM?___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it-trentino] OSMIT 2016 venerdì 20 maggio 2016 BASE Milano

[Luca Delucchi]

2016-05-16 11:21 GMT+02:00 Paolo Ianes :
> Ciao a tutti,

ciao,

> ho ricevuto da Alessandro Palmas la notizia che OSMIT 2016 si terrà a Milano
> il 20 e il 21 maggio 2016.
> Purtroppo, anche se mi piacerebbe, il sabato no posso partecipare, c'è
> qualcuno che parte da Trento il giorno 20 con rientro in serata con cui
> condividere il viaggio?
> Mi potete far sapere?

io vado giù in treno e torno il 21, mi spiace

> Grazie,
> Paolo Ianes
>

-- 
ciao
Luca

www.lucadelu.org

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

[Talk-it-trentino] OSMIT 2016 venerdì 20 maggio 2016 BASE Milano

[Paolo Ianes]

Ciao a tutti,
ho ricevuto da Alessandro Palmas la notizia che OSMIT 2016 si terrà a
Milano il 20 e il 21 maggio 2016.
Purtroppo, anche se mi piacerebbe, il sabato no posso partecipare, c'è
qualcuno che parte da Trento il giorno 20 con rientro in serata con cui
condividere il viaggio?
Mi potete far sapere?
Grazie,
Paolo Ianes
___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

Re: [Talk-in] Railway station GPS co-ordinates

[Warin]

Hi,
a better way ?

with this query, you immediately have a CSV file as output.

Use thishttp://overpass-turbo.eu/s/gdp

or copy the query below tohttp://overpass-turbo.eu/



[out:csv (railway,station)][timeout:25];
// gather results
(
  // query part for: “railway=station”
  node["place"="town"]({{bbox}});
  way["place"="town"]({{bbox}});
  relation["place"="town"]({{bbox}});
);
// print results
out body;


;


out skel qt;

seehttp://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29
for more options on the CSV output

You can make the timeout longer in case you want to cover a larger area.
 


On 5/16/2016 5:47 PM, Shibu Narayanan wrote:


The link suggested by Arun 
http://download.geofabrik.de/asia/india.html has a 10GB xml file which 
contains the required information.


I will extract it as a csv and post the results here.

*Shibu Narayanan
*Oracle Financial Services | Bangalore | India
Office:0091-80-4918-1692 | Mobile:0091-99800-64282

*From:*Sutripta (Gmail) [mailto:sutri...@gmail.com]
*Sent:* Monday, May 16, 2016 12:10 PM
*To:* OpenStreetMap in India
*Subject:* Re: [Talk-in] Railway station GPS co-ordinates

Hi,
Is the list of Railway Stations/ Junctions in India available as a 
CSV/ Excel file? Maybe with a column saying 'Ground truthed/ validated'.


Sometime back there was a XML file from IR, but as pointed out by Arun 
Ganesh, had a lot of errors.


Regards
Sutripta

On 12-05-2016 22:19, Arun Ganesh wrote:

Hey Shibu, you can extract it live from OSM using overpass:
http://overpass-turbo.eu/s/gbk

If you want a shapefile of a larger area, suggest you download the
OSM extract from geofabrik
http://download.geofabrik.de/asia/india.html

The POI layer should have the railway stations.

On Thu, May 12, 2016 at 9:59 PM, Shibu Narayanan
>
wrote:

Hi,

How do I get the list of all railway stations in Karnataka(or any
other state) and also its GPS co-ordinates?

*Shibu Narayanan
*Oracle Financial Services | Bangalore | India
Office:0091-80-4918-1692  |
Mobile:0091-99800-64282 


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



-- 


Arun Ganesh

@planemad




___

Talk-in mailing list

Talk-in@openstreetmap.org 

https://lists.openstreetmap.org/listinfo/talk-in



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



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

Re: [Talk-in] Railway station GPS co-ordinates

[Shibu Narayanan]

The link suggested by Arun http://download.geofabrik.de/asia/india.html has a 
10GB xml file which contains the required information.

I will extract it as a csv and post the results here.  

 

Shibu Narayanan 
Oracle Financial Services | Bangalore | India
Office:0091-80-4918-1692 | Mobile:0091-99800-64282

 

From: Sutripta (Gmail) [mailto:sutri...@gmail.com] 
Sent: Monday, May 16, 2016 12:10 PM
To: OpenStreetMap in India
Subject: Re: [Talk-in] Railway station GPS co-ordinates

 

Hi, 
Is the list of Railway Stations/ Junctions in India available as a CSV/ Excel 
file? Maybe with a column saying 'Ground truthed/ validated'. 

Sometime back there was a XML file from IR, but as pointed out by Arun Ganesh, 
had a lot of errors. 

Regards 
Sutripta 



On 12-05-2016 22:19, Arun Ganesh wrote:

Hey Shibu, you can extract it live from OSM using overpass: 
http://overpass-turbo.eu/s/gbk 

 

If you want a shapefile of a larger area, suggest you download the OSM extract 
from geofabrik http://download.geofabrik.de/asia/india.html

 

The POI layer should have the railway stations.

 

On Thu, May 12, 2016 at 9:59 PM, Shibu Narayanan mailto:shibu.naraya...@oracle.com; \nshibu.naraya...@oracle.com> wrote:

Hi,

How do I get the list of all railway stations in Karnataka(or any other state) 
and also its GPS co-ordinates?

 

Shibu Narayanan 
Oracle Financial Services | Bangalore | India
Office:HYPERLINK "tel:0091-80-4918-1692" \n0091-80-4918-1692 | Mobile:HYPERLINK 
"tel:0091-99800-64282" \n0091-99800-64282

 


___
Talk-in mailing list
HYPERLINK "mailto:Talk-in@openstreetmap.org"Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in





 

-- 

Arun Ganesh

@planemad






___
Talk-in mailing list
HYPERLINK "mailto:Talk-in@openstreetmap.org"Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

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

Re: [Talk-cz] [osm_sk] WeeklyOSM CZ 301

[Martin Ždila]

Ono chyba aj osmc:symbol pre obycajnu bodku bez podkladu, nieco ako
"red::red_dot". Skoda, ze background je povinny.

2016-05-16 9:01 GMT+02:00 Tibor Jamečný :

> Ahoj,
> zhodou okolnosti som vcera studoval osmc:symbol kvoli upravam na
> Freemap-e, a zaujima ma, odkial ste zobrali osmc:symbol=none?
> Na http://wiki.openstreetmap.org/wiki/Key:osmc:symbol je napisane, ze
> minimalny povinny format je:
>
> osmc:symbol=*waycolor*:*background*
>
> Taktiez nikde nevidim zmienku o hodnote "none" (ani na
> http://www.wanderreitkarte.de/symbols_en.html), maximalne niektore polia
> mozu byt vynechane.
>
> T.
>
> 2016-05-16 8:20 GMT+02:00 Tom Ka :
>
>> Ahoj, je dostupné vydání 301 týdeníku weeklyOSM:
>>
>> http://www.weeklyosm.eu/cz/archives/7383
>>
>> Téma čísla: Odstranění tagu kct_barva
>>
>> * api.osm.org a IPv6.
>> * Rychlé mapování dle Mapboxu.
>> * OpenPeer review pro OSM.
>> * OSM a zemětřesení v Ekvádoru.
>>
>> Pěkné počtení...
>>
>> --
>> Túto správu ste prijali, pretože ste prihlásení na odber správ skupiny
>> „Openstreetmap Slovakia“ služby Skupiny Google.
>>
>> Ak chcete zrušiť odber tejto skupiny a prestať od nej prijímať e-maily,
>> pošlite e-mail na adresu osm_sk+unsubscr...@googlegroups.com.
>> Ak chcete zobraziť túto diskusiu na webe, prejdite na adresu
>> https://groups.google.com/d/msgid/osm_sk/CAHqEKC2HtomgjY7PPyFMrGo9ZoXF7NSUiRW2L0bfdGJatjr7Cg%40mail.gmail.com
>> .
>> Ďalšie možnosti nájdete na stránke https://groups.google.com/d/optout.
>>
>
> --
> Túto správu ste dostali, pretože v Skupinách Google ste odberateľom
> skupiny "Openstreetmap Slovakia".
> V prípade, že chcete zrušiť odber tejto skupiny a prestať od nej prijímať
> e-maily, zašlite e-mail na adresu osm_sk+unsubscr...@googlegroups.com.
> Ak chcete zobraziť túto diskusiu na webe, prejdite na adresu
> https://groups.google.com/d/msgid/osm_sk/CAKvbCN3T6aXnhpeXV68bW0u8%2BBuw%3D0TJ50J22HZy9rHTRsN35w%40mail.gmail.com
> 
> .
>
> Ďalšie možnosti nájdete na stránke https://groups.google.com/d/optout.
>



-- 
Ing. Martin Ždila 
OZ Freemap Slovakia
tel:+421-908-363-848
mailto:martin.zd...@freemap.sk
http://www.freemap.sk/
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-in] Railway station GPS co-ordinates

[Sutripta (Gmail)]

Hi,
Is the list of Railway Stations/ Junctions in India available as a CSV/ 
Excel file? Maybe with a column saying 'Ground truthed/ validated'.


Sometime back there was a XML file from IR, but as pointed out by Arun 
Ganesh, had a lot of errors.


Regards
Sutripta


On 12-05-2016 22:19, Arun Ganesh wrote:
Hey Shibu, you can extract it live from OSM using overpass: 
http://overpass-turbo.eu/s/gbk


If you want a shapefile of a larger area, suggest you download the OSM 
extract from geofabrik http://download.geofabrik.de/asia/india.html


The POI layer should have the railway stations.

On Thu, May 12, 2016 at 9:59 PM, Shibu Narayanan 
> wrote:


Hi,

How do I get the list of all railway stations in Karnataka(or any
other state) and also its GPS co-ordinates?

*Shibu Narayanan
*Oracle Financial Services | Bangalore | India
Office:0091-80-4918-1692  |
Mobile:0091-99800-64282 


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




--
Arun Ganesh
@planemad


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


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