Re: [OSM-talk-fr] modification au 1er janvier

[Stéphane Péneau]

Il y a un peu plus de communes nouvelles ici :
https://fr.wikipedia.org/wiki/Liste_des_communes_nouvelles_cr%C3%A9%C3%A9es_en_2018

Le 29/12/2017 à 07:41, Stéphane Péneau a écrit :

Je m'occupe des modifs Loire-Atlantique / Maine-et-Loire dans la journée

Stf

Le 28/12/2017 à 22:27, osm.sanspourr...@spamgourmet.com a écrit :
Ce décret étant applicable au 25 décembre je l'ai appliqué à la base 
: changeset #54992352 .
Je me suis permis de conserver l'accent aigü sur Saint-Elix-d'Astarac 
(soit Saint-Élix-d'Astarac).
Car Christian avait bien prévu que les noms en doubles seraient 
dédoublés, les tirets cadratins corrigés (pas vu mais appliqués à ces 
nouveaux noms) mais il y a aussi les accents oubliés sur les majuscules.


Je n'ai pas modifié les pages Wikipedia.

Anne-Marie, j'ai profité pour ajouter un nom en gascon. On remarquera 
que le nom actuel en français se rapproche fortement du nom gascon.


Jean-Yvon

Le 28/12/2017 à 19:09, David Crochet - david.croc...@free.fr a écrit :


JORF n°0300 du 24 décembre 2017 : 
https://www.legifrance.gouv.fr/eli/jo/2017/12/24/0300


*6 * Décret n° 2017-1744 du 22 décembre 2017 portant changement du 
nom de communes 






___
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: [OSM-talk-fr] modification au 1er janvier

[Stéphane Péneau]

Je m'occupe des modifs Loire-Atlantique / Maine-et-Loire dans la journée

Stf

Le 28/12/2017 à 22:27, osm.sanspourr...@spamgourmet.com a écrit :
Ce décret étant applicable au 25 décembre je l'ai appliqué à la base : 
changeset #54992352 .
Je me suis permis de conserver l'accent aigü sur Saint-Elix-d'Astarac 
(soit Saint-Élix-d'Astarac).
Car Christian avait bien prévu que les noms en doubles seraient 
dédoublés, les tirets cadratins corrigés (pas vu mais appliqués à ces 
nouveaux noms) mais il y a aussi les accents oubliés sur les majuscules.


Je n'ai pas modifié les pages Wikipedia.

Anne-Marie, j'ai profité pour ajouter un nom en gascon. On remarquera 
que le nom actuel en français se rapproche fortement du nom gascon.


Jean-Yvon

Le 28/12/2017 à 19:09, David Crochet - david.croc...@free.fr a écrit :


JORF n°0300 du 24 décembre 2017 : 
https://www.legifrance.gouv.fr/eli/jo/2017/12/24/0300


*6 * Décret n° 2017-1744 du 22 décembre 2017 portant changement du 
nom de communes 






___
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] Standard map style contributions

[Andy Townsend]

On 28/12/2017 10:45, Daniel Koć wrote:


However after almost half a year we still don't have too many 
contributions from other people and I'm curious what are the main 
obstacles which prevent it and what else could we possibly change to 
make it easier? There's also more basic question: how many people are 
interested in contributing to osm-carto at all?


Speaking entirely personally, the main issue is just 
selfishness/laziness.  I don't use the OSM Carto style much myself 
(there'd be too much information missing at the zoom levels I typically 
use) so I wouldn't get much benefit myself from an accepted change.  In 
case it helps anyone who does want to contribute but doesn't quite know 
where to start I've added a diary entry 
https://www.openstreetmap.org/user/SomeoneElse/diary/43041 that explains 
what I needed to do to submit 
https://github.com/gravitystorm/openstreetmap-carto/pull/2966 . There's 
actually a surprisingly large amount that needs to be done to support 
(in this case) 7 lines of changed code.


I'd also not assume that everyone is familar with CSS.  In addition, the 
somewhat arcane way that some of the selections for layers are done in 
project.mml is, shall we say, not always that easy to follow.


Another reason why I've not added more pull requests is that in some 
cases I don't think that they'd be accepted.  If I offered to "fix" the 
main problem described by 
https://github.com/gravitystorm/openstreetmap-carto/issues/765 I'm 
pretty sure that it wouldn't be accepted.  As described in 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md 
, OSM Carto has somewhat conflicting goals - both as "an important 
feedback mechanism for mappers" and as an "exemplar stylesheet". Any map 
style will always be a compromise of course; you can't have "everything 
louder than everything else" which is why the requests for some features 
to be rendered will be denied (although I suspect that we underestimate 
how much more opportunity these is for rendering features at high zoom 
levels only).


Another reason is I suspect the "jumping through hoops" needed to get 
something accepted.  See for example the discussion on 
https://github.com/gravitystorm/openstreetmap-carto/issues/2355 - it's 
clear that there's unlikely to be complete agreement there, and the 
result is no solution at all (essentially "perfect is the enemy of good").


With the last two issues it's difficult to know what to suggest - there 
has to be an overall style "direction" otherwise you just end up with 
something that is a bit of a mess.  Likewise there have to be some 
standards, but sometimes I suspect that if the maintainers actually want 
to see a fix to a particular problem that they'll need help potential 
contributors a bit more.  Obviously the docker info is a step in the 
right direction (I've not tried that myself so I can't point to specific 
pitfalls there).


Anyway, I hope the above helps (and please understand that it's not 
meant as a criticism either of the style or the maintainers - it's just 
trying to provide answers to the questions that were asked).


Best Regards,

Andy


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

[Talk-de] Chemnitzer Linuxtage 2018 - ist da jemand aktiv?

[lars lingner]

Hallo zusammen,

auf dem 34C3 wurde ich heute gefragt, warum von OSM bisher keine
Anmeldung für die Chemnitzer Linuxtage 2018 [1] kam. Die Frage konnte
ich nicht beantworten und ich muss gestehen, ich war auch noch nie dabei.

Es wäre laut OSM-Wiki [2] das 10. Jahr mit OSM-Beteiligung. Irgendwie
muss OSM auch einen positiven Eindruck hinterlassen haben, wenn man auf
eine fehlende Anmeldung hingewiesen wird.

Besteht denn Interesse einen Stand auf den CLT zu haben? Gibt es Hürden?
Wird Hilfe benötigt?

Eine Anmeldung ist noch bis 08.01.2018 möglich.


Viele Grüße vom 34C3,

Lars


[1] https://chemnitzer.linux-tage.de
[2] http://wiki.openstreetmap.org/wiki/Chemnitzer_Linux-Tage_2017

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

Re: [Talk-GB] Importing Shell fuel stations

[Warin]

On 29-Dec-17 07:28 AM, Mark Goodge wrote:



On 28/12/2017 19:31, Lester Caine wrote:

Get the return address right ...

On 28/12/17 16:12, Colin Spiller wrote:
I've been adding postcodes in the Bradford BD area using Robert & 
gregrs

useful tools. I've just noticed that the Shell station at the Rooley
Lane / Rooley Avenue junction BD5 8JR is now reported as having an
incorrect postal unit (the final two letters of the postcode). This
postcode appears widely on the internet for this site, but the RM
postcode finder thinks it should be Rooley Avenue, BD6 1DA.


PAF file has ...
Shell Filling Station
Rooley Avenue
BRADFORD
BD6 1DA

and BD5 8JR is not listed having been deleted in 2009
http://checkmypostcode.uk/bd58jr so the real problem is does one leave
the faulty postcode in place because we can't use the PAF data or do we
validate postcodes against the codepoint database and remove those that
are not listed


It's an interesting conundrum, on several levels. We can certainly 
validate against Codepoint Open or the ONSPD, as these are open data. 
So if they say the postcode is impossible (because it's defunct), then 
we can definitely delete it if we want to.


Replacing it with the correct postcode, though, is harder. We'd need a 
source that isn't derived from PAF. But Googling for this particular 
station, all the sources have the old, incorrect postcode - even 
Google itself! (I would expect they're all using the Shell data, of 
course).


So that leaves us with three options, at least initially:

1. Leave it as is. We know it's wrong, but it's consistent with every 
other source, and it's from the only canonical source.


2. Replace it with the right one. More useful, but potentially risky 
from a licensing perspective.


3. Delete it and leave the entry with no postcode. Probably the best 
we can do as far as accuracy is concerned (in line with the general 
principle that data is better missing than wrong, if it can't be 
right), and avoids any licence conflict. But this is the least useful 
for users of the data (since, in this case, even the wrong postcode 
will identify the location in practice - for obvious reasons, Royal 
Mail will deliver to defunct postcodes long after they have been 
deleted, and many sat-navs will work with defunct postcodes too).


Maybe the best solution is to leave it alone for now, and see if we 
can persuade Shell to fix it. Deleting the postcode risks it being 
re-added by someone else who spots its absence and decides to be 
helpful, without realising that if they use the RM postcode finder to 
validate it that isn't compatible with OSM's licence.


Usually a note is used to make comments to other mappers. In this case a 
note to say that post code xxx is defunct would explain the situation. 
Possibly a tag 'defunct:postcode=xxx would also be explanatory.


Could the post code be derived from surrounding features?
I don't know how detailed the post codes there are .. but if features in 
OSM surrounding it were of the same post code (and correct) then they 
could be used to derive the post code?


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

Re: [OSM-talk-fr] modification au 1er janvier

[osm . sanspourriel]

Ce décret étant applicable au 25 décembre je l'ai appliqué à la base : 
changeset #54992352 .
Je me suis permis de conserver l'accent aigü sur Saint-Elix-d'Astarac 
(soit Saint-Élix-d'Astarac).
Car Christian avait bien prévu que les noms en doubles seraient 
dédoublés, les tirets cadratins corrigés (pas vu mais appliqués à ces 
nouveaux noms) mais il y a aussi les accents oubliés sur les majuscules.


Je n'ai pas modifié les pages Wikipedia.

Anne-Marie, j'ai profité pour ajouter un nom en gascon. On remarquera 
que le nom actuel en français se rapproche fortement du nom gascon.


Jean-Yvon

Le 28/12/2017 à 19:09, David Crochet - david.croc...@free.fr a écrit :


JORF n°0300 du 24 décembre 2017 : 
https://www.legifrance.gouv.fr/eli/jo/2017/12/24/0300


*6 * Décret n° 2017-1744 du 22 décembre 2017 portant changement du nom 
de communes 



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

Re: [Talk-GB] Importing Shell fuel stations

[Mark Goodge]

On 28/12/2017 19:31, Lester Caine wrote:

Get the return address right ...

On 28/12/17 16:12, Colin Spiller wrote:

I've been adding postcodes in the Bradford BD area using Robert & gregrs
useful tools. I've just noticed that the Shell station at the Rooley
Lane / Rooley Avenue junction BD5 8JR is now reported as having an
incorrect postal unit (the final two letters of the postcode). This
postcode appears widely on the internet for this site, but the RM
postcode finder thinks it should be Rooley Avenue, BD6 1DA.


PAF file has ...
Shell Filling Station
Rooley Avenue
BRADFORD
BD6 1DA

and BD5 8JR is not listed having been deleted in 2009
http://checkmypostcode.uk/bd58jr so the real problem is does one leave
the faulty postcode in place because we can't use the PAF data or do we
validate postcodes against the codepoint database and remove those that
are not listed


It's an interesting conundrum, on several levels. We can certainly 
validate against Codepoint Open or the ONSPD, as these are open data. So 
if they say the postcode is impossible (because it's defunct), then we 
can definitely delete it if we want to.


Replacing it with the correct postcode, though, is harder. We'd need a 
source that isn't derived from PAF. But Googling for this particular 
station, all the sources have the old, incorrect postcode - even Google 
itself! (I would expect they're all using the Shell data, of course).


So that leaves us with three options, at least initially:

1. Leave it as is. We know it's wrong, but it's consistent with every 
other source, and it's from the only canonical source.


2. Replace it with the right one. More useful, but potentially risky 
from a licensing perspective.


3. Delete it and leave the entry with no postcode. Probably the best we 
can do as far as accuracy is concerned (in line with the general 
principle that data is better missing than wrong, if it can't be right), 
and avoids any licence conflict. But this is the least useful for users 
of the data (since, in this case, even the wrong postcode will identify 
the location in practice - for obvious reasons, Royal Mail will deliver 
to defunct postcodes long after they have been deleted, and many 
sat-navs will work with defunct postcodes too).


Maybe the best solution is to leave it alone for now, and see if we can 
persuade Shell to fix it. Deleting the postcode risks it being re-added 
by someone else who spots its absence and decides to be helpful, without 
realising that if they use the RM postcode finder to validate it that 
isn't compatible with OSM's licence.


Mark

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

[Talk-lv] Ādažu poligons

[Kārlis Šteinbergs]

Sveicināti!

Skatos, ka OSM kartē nav paplašināta Ādažu poligona teritorija.

Vai ir kādas idejas kā varētu labot šo kļūdu (esmu kādu brīdi izkriti no
aprites :) )?

http://www.delfi.lv/news/national/politics/adazu-poligona-teritorija-sogad-paplasinata-par-5259-hektariem.d?id=49594035

Dabā esmu pārliecinājies, ka dienvid-austrumu stūrī jaunajā teritorijā
jau dabā jau ir poligona apzīmējumi.

-- 
--
Ar cieņu,
Kārlis Šteinbergs



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

Re: [Talk-us] Walmart Import

[Peter Dobratz]

Hi Ilya,

This copnflation audit software tool is really good to allow multiple OSM
users to review the data before changes are made to OSM data.  I didn't
initially realize the amount of manual review of the data that is being
done prior to importing the data into OSM.

I've been reviewing a bunch of Walmarts using this tool and there will be a
lot of new good data being added to OSM through this process.  It seems
like people are generally preserving the choice of shop=supermarket or
shop=department_store and also name of "Walmart" or "Walmart Supercenter"
as the choice between the two is somewhat arbitrary.  Also, in many cases
the addr:full tag is being omitted if that same information is already
contained in existing addr:housenumber, addr:street, and addr:unit tags.

Peter

On Thu, Dec 28, 2017 at 6:22 AM, Ilya Zverev  wrote:

> Hi Peter,
>
> Thank you for the extended example of opening_hours containing holidays
> exceptions. While validating the Walmart import, I've encountered a couple
> of these, albeit simpler.
>
> My opinion on tags does not have an extra weight in relation to other
> mappers. With the introduction of the "Conflation Audit" website, to which
> I link, the data owner does not dictate which tags to overwrite as well. By
> participating in validation, you choose which tags to keep and which to
> override, and where to place imported points.
>
> For example, when seeing "24/7; Dec 25 off" on a Walmart, I clicked on
> that line, so it doesn't get overwritten on import. The line becomes
> highlighted, which means that's what will be in OSM after the import. See
> for an example this object:
>
> http://audit.osmz.ru/browse/walmart/4404
>
> Sorry I didn't get to answer earlier,
> Ilya
>
> > 22 дек. 2017 г., в 10:46, Peter Dobratz  написал(а):
> >
> > Ilya,
> >
> > I'm trying to wrap my head around how making this a "frictionless series
> of imports" is going to work.  So if a local mapper edits details on a
> Walmart, those details could potentially be swiftly overwritten with your
> data?
> >
> > As you can see, the opening hours for next week are non-standard due to
> the Christmas holiday.  What if someone decides they want to add that level
> of detail to the opening_hours tag:
> > opening_hours=00:00-01:00,05:00-24:00; Dec 24 5:00-18:00; Dec 25 off;
> Dec 26 06:00-24:00
> >
> > How long until you automatically replace this with "05:00-01:00" ?
> >
> > Do you see the problem with doing that?
> >
> > As you say there are differences of opinion in how things are tagged.
> Why does your opinion get to have more weight?
> >
> > Peter
> >
> > On Thu, Dec 21, 2017 at 1:12 AM, Ilya Zverev  wrote:
> > Hi Peter,
> >
> > Thank you for suggestions.
> >
> > First, the highlighted tag value is what goes into OSM. In your case,
> the import will keep the shop=department_store.
> >
> > Regarding updates to opening_hours, you are suggesting I parse each
> opening_hours value and then compare these? It would be quite hard and in
> my opinion excessive. With the two values being equivalent, I don't how the
> data becomes worse. A few times I omitted "Mo-Su", I was being told it's
> better to specify the weekdays, so it is again a matter of opinion.
> >
> > In your example, you override the definition for Monday, so it doesn't
> demonstrate anything besides how complex the opening_hours notation is.
> >
> > The rest I answered in imports@, and some of it goes against what other
> community members suggest, so again I can conclude that is a matter of
> opinion and not important one way or another:
> >
> > * URL is provided by Walmart and is much better than what we have.
> /whats-new can be fixed later, and does not really matter, because it still
> takes to a store page.
> > * addr:full is provided by Walmart and may be used to improve addressing
> where there are no addr:* tags. Sorry the importing script cannot do
> conditional tagging.
> > * operator was recommended by community members, and is a good tag to
> filter all Walmarts.
> > * ref:walmart will be used for updating the data. Ref may refer not only
> to a store, but to a building or another feature.
> >
> > Please understand that this is not a one-off handcrafted import. We are
> working on a process for frictionless series of imports, with regular
> updates later on. I understand you have mapped a Walmart and feel
> protective of it. I felt the same a few years into OSM, because everything
> you add to the map is important. With this import, I believe it does not
> make the data worse. More attributes is not bad, even if some of these are
> redundant. The main thing is, until now there were zero mappers who care
> about keeping all the Walmart stores in OSM up-to-date, and after, there
> will be more. To me, that is a good thing.
> >
> > Thanks,
> > Ilya
> >
> >
> > > 21 дек. 2017 г., в 1:22, Peter Dobratz  написал(а):
> > >
> > > Ilya,
> > >
> > > Here's a Walmart 

Re: [Talk-GB] Importing Shell fuel stations

[Lester Caine]

Get the return address right ...

On 28/12/17 16:12, Colin Spiller wrote:
> I've been adding postcodes in the Bradford BD area using Robert & gregrs
> useful tools. I've just noticed that the Shell station at the Rooley
> Lane / Rooley Avenue junction BD5 8JR is now reported as having an
> incorrect postal unit (the final two letters of the postcode). This
> postcode appears widely on the internet for this site, but the RM
> postcode finder thinks it should be Rooley Avenue, BD6 1DA.

PAF file has ...
Shell Filling Station
Rooley Avenue
BRADFORD
BD6 1DA

and BD5 8JR is not listed having been deleted in 2009
http://checkmypostcode.uk/bd58jr so the real problem is does one leave
the faulty postcode in place because we can't use the PAF data or do we
validate postcodes against the codepoint database and remove those that
are not listed

> The node Fuel #5210358416 
> has these tags:
> 
> 
> Tags
> 
> addr:postcode
> 
> BD5 8JR
> amenity 
> fuel 
> brand Shell
> opening_hours
> 
> 24/7
> phone +44
> 1274 306188 
> ref:navads_shell  NVDS353-12038573
> 
> 
> but no street or city. The whole thing seems odd to me.


-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-it] Trinceroni

[Martin Koppenhoefer]

sent from a phone

> On 28. Dec 2017, at 20:15, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
> Ok, per il natural=cave_entrance, è esagerato, ma se c'è questa esigenza era 
> una considerazione.



per me non è nessun “cave”, ne natural ne man made.

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

Re: [Talk-it] cimiteri in Italia

[Martin Koppenhoefer]

sent from a phone

> On 28. Dec 2017, at 12:08, Volker Schmidt  wrote:
> 
> 
> 2)
> Pensavo che landuse=cemetery e amenity=grave_yard sono alternative. Trovo 
> parecchi cimiteri con entrambi i tag.


amenity =graveyard lo vedo per i cimiteri “antichi”, cioè annessi ad una 
chiesa, mentre i cimiteri normali non fanno parte di una chiesa (hanno una 
cappella per il rito di sepoltura, ma non sono chiese normali). Anche se 
guardando il pelo, dovrebbe forse essere churchyard


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

Re: [Talk-it] Trinceroni

[liste DOT girarsi AT posteo DOT eu]

Il 27/12/2017 22:49, demon.box ha scritto:

ciao Simone, ok concordo e recepisco l'impianto di base della tua proposta
anche se ti faccio notare che a me suona un po' strano

tunnel=building_passage visto che di fatto non si passa attraverso nessun
edificio ma è più un tunnel=yes, a parer mio...

inoltre colgo l'occasione (e sò già che muovo un vespaio) a proposito di

disused:military=trench

non è la stessa cosa fare così?

military=trench
disused=yes

non mai ben capito perchè dobbiamo incasinarci con il prefisso disused,
magari qualcuno me lo sa cortesemente spiegare?

grazie



Ok, per il natural=cave_entrance, è esagerato, ma se c'è questa esigenza 
era una considerazione.


Per il tag disused:military=trench//bunker, era perchè oggi non viene 
più usato militarmente, però esistono ancora e sono anche per uso civile 
(turistico).


Quanto al tunnel, guardando il wiki ci starebbe tunnel=culvert [0], 
visto che è di fatto un passaggio coperto, insieme a layer=-1.


man_made=cave entrance non dice nulla se non ce c'è una cosa scavata 
dall'uomo per entrare, ma tralascia tutto il resto, mentre man_made=yes, 
dice genericamente fatto dall'uomo, vale per tutto il tratto del tunnel, 
comprese le entrate/uscite.



[0] http://wiki.openstreetmap.org/wiki/IT:Key:tunnel

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

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

Re: [OSM-talk] Generate polygons out of administrative Relations

[Martin Koppenhoefer]

sent from a phone

> On 28. Dec 2017, at 11:56, Nic  wrote:
> 
> Any recommended URL where I can start reading about the "style file"
> approach to only load boundaries?


not sure about URL (I believe there’s docu both bundled with osm2pgsql and in 
the osm wiki), but there’s a default.style file which you can modify, and it is 
pretty self explanatory 


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

[Talk-ar] Interpolación Incorrecta

[Jorge Aguirre]

Buen día.

Al estar ingresando direcciones (alturas) que aparecen en los edificios en
el area de *Partido de Lanús* pude observar que éstos no coinciden con la
interpolación que ha sido ingresada a la base de datos.  Resulta que la
numeración de los pares y los impares se encuentra ingresada del lado
contrario en las calles.  Incluso la secuencia de la numeración de menor a
mayor está, aparentemente, invertida.

Esto lo descubrí específicamente sobre la calle Doctor Roberto Paxtot ,
entre las calles Alfredo Palacios y Jean Juares, pero al revisar el área
adyacente, en general, parece que el error es bastante extenso.

Me comuniqué con el autor (*hcastellaro*) quien me confirmó que los datos
utilizados en una importación (de una supuesta buena fuente - *Dirección
Provincial de Estadística*) tenía errores, sin embargo no se ofreció a
corregirlos.  Debo suponer que aun no cuenta con los datos correctos.  La
última edición se realizó en Dic/16.
https://www.openstreetmap.org/changeset/44361343

Desconozco cuál sea la metodología adoptada por ustedes para casos como
éste y cómo se debe proceder. - Creo que en este caso específico conviene
borrar lo ingresado y empezar de cero.  Lamentablemente, no cuento con la
suficiente información para corregir este hallazgo, tan solo puedo ingresar
como referencia los edificios con las alturas que sean perfectamente
legibles en las fotografías.  Por esta razón, recurro a ustedes para lograr
corregir esto con información correcta y actualizada.  Yo podría colaborar,
en cierta medida, pero necesitaría acceso a una fuente confiable. Es
preferible que no se incluyan las alturas - a tenerlas mal ingresadas.

En un correo anterior intenté adjuntar una muestra de fotos
geo-referenciadas de las alturas en el area descrita, pero parece que el
archivo era muy grande y no pudo llegarles.

Quedo a la espera de sus comentarios.

Atentamente,


Jorge Aguirre
Geographer
Kaart Group, LLC
jo...@kaartgroup.com
+(502) 4191 1999 
www.kaartgroup.com



*“Let's make our planet great again.”*
- Emmanuel Macron
  President of France
___
Talk-ar mailing list
Talk-ar@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ar

Re: [Talk-GB] Importing Shell fuel stations

[Andy Mabbett]

On 26 November 2017 at 14:52, Philip Barnes  wrote:

> This would make obvious errors easier to spot, one example I found was
> a closing time of 16:00 which is an obvious error that does not need
> local knowledge.

At a supermarket filling station near me, the "kiosk" actually closes at a
time not far different from this. fter that, fuel is only available from
self-service pumps - and is available from them 24/7.

Given the increasing ubiquity of the latter, plus pay-for-water and
pay-for-air machines, we need to be careful with "closing" times.

[Wonders off, muttering about when air was free...]

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-fr] modification au 1er janvier

[David Crochet]

Bonjour

Pour info

Au JORF n°0302 du 28 décembre 2017 : 
https://www.legifrance.gouv.fr/eli/jo/2017/12/28/0302


 * *3 * Décret n° 2017-1756 du 26 décembre 2017 portant modification
   des limites territoriales de cantons, d'arrondissements et de
   départements dans la Manche et le Calvados
   


 * *4 * Décret n° 2017-1757 du 26 décembre 2017 portant modification
   des limites territoriales de cantons, d'arrondissements et de
   départements dans la Loire-Atlantique et le Maine-et-Loire
   


 * *5 * Décret n° 2017-1758 du 26 décembre 2017 portant création de la
   métropole dénommée « Toulon-Provence-Méditerranée »
   


 * *7 * Arrêté du 4 décembre 2017 portant création de la commune
   nouvelle d'Arinthod
   


 * *8 * Arrêté du 4 décembre 2017 portant création de la commune
   nouvelle de Vosbles-Valfin
   


 * *9 * Arrêté du 6 décembre 2017 portant habilitation du lycée
   français de Shanghai (République populaire de Chine) pour les
   formations aux premiers secours
   


 * *10 * Arrêté du 6 décembre 2017 portant création de la commune
   nouvelle de Porte-de-Seine
   


 * *11 * Arrêté du 7 décembre 2017 portant création de la commune
   nouvelle de Lasserre-Pradère
   


 * *12 * Arrêté du 12 décembre 2017 portant création de la commune
   nouvelle de Beauvallon
   

 * *16 * Arrêté du 13 décembre 2017 portant création de la commune
   nouvelle de Pont-Hébert
   


Au JORF n°0301 du 27 décembre 2017 : 
https://www.legifrance.gouv.fr/eli/jo/2017/12/27/0301



 * *4 * Arrêté du 6 décembre 2017 portant création de la commune
   nouvelle de Lendou-en-Quercy
   


 * *5 * Arrêté du 6 décembre 2017 portant création de la commune
   nouvelle de Pont-Audemer
   


JORF n°0300 du 24 décembre 2017 : 
https://www.legifrance.gouv.fr/eli/jo/2017/12/24/0300


*6 * Décret n° 2017-1744 du 22 décembre 2017 portant changement du nom 
de communes 




JORF n°0299 du 23 décembre 2017 : 
https://www.legifrance.gouv.fr/eli/jo/2017/12/23/0299


 * *5 * Arrêté du 29 septembre 2017 portant création de la commune
   nouvelle de Trie-Château
   


 * *6 * Arrêté du 15 novembre 2017 portant création de la commune
   nouvelle du Lude
   

 * *9 * Arrêté du 1er décembre 2017 portant création de la commune
   nouvelle de Bâgé-Dommartin
   


 * *10 * Arrêté du 4 décembre 2017 portant création de la commune
   nouvelle de 

[Talk-GB] Importing Shell fuel stations

[Rob Nickerson]

Hi Colin,

BD5 8JP is but a stone's throw away. I guess this got picked up then
incorrectly typed and hence the 8JR ending.

Luckily OSM is editable (!) so if you can find a better source of free data
then please update.

Regards,
Rob

P.s. you can see all this on the postcode centroid map which highlights
that this is borderline BD5 and BD6.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Site de pêche litigieux

[osm . sanspourriel]

Le 28/12/2017 à 14:46, LeTopographeFou - letopographe...@gmail.com a écrit :
Quelqu'un de chevronné ici est-il chargé de faire corriger ces 
problèmes ou bien dois-je aller au charbon avec doigté ?

Comme on est tous bénévoles, le mieux que c'est que chacun aille au charbon.

Non seulement ils ne payent pas, ne créditent pas mais en plus se font 
rémunérer par la pub et comme localisation utilisent Google.
Il semble que les données ne sont pas extraites d'OSM (ou mal 
simplifiées : le début c'est le lavoir sur OSM), de là à penser qu'ils 
ont viré une carte payante Google pour une carte gratuite... sans même 
créditer.


> Notre but est de proposer le meilleur service de localisation et de 
renseignements des lieux de pêche français.

Ils feraient mieux d'améliorer les infos sur OSM et les utiliser ensuite.
Jean-Yvon

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

Re: [OSM-talk-fr] Site de pêche litigieux

[Philippe Verdy]

L'erreur obtenue est une erreur DNS (le géoDNS d'OSM.org semble en être la
cause), je n’atteins même pas un le serveur proxy cache, sans doute un
changement de configuration sur le CDN d'OSM.org.

Le 28 décembre 2017 à 17:11, Philippe Verdy  a écrit :

> A ce sujet le serveur de tuiles cartoCSS d'OSM.org est tombé et n'affiche
> plus rien pour le moment, pas même au n iveau de zoom faible sur la carte
> du monde qui devrait être en cache.
> Il semble que ce soit le proxy cache pour la France qui soit en rade...
>
> Le 28 décembre 2017 à 14:46, LeTopographeFou 
> a écrit :
>
>> Bonjour,
>>
>> Je suis tombé par hasard sur la page https://ou-pecher.fr/coins-de-
>> peche-detail/55a6344a2b6dff21167dcaa3/ruisseau-des-coutumes où je
>> constate au moins deux infractions selon https://operations.osmfoundati
>> on.org/policies/tiles/ :
>>
>>1. OpenStreetMap n'est pas crédité
>>2. Le site envoi des en-têtes qui désactivent le cache
>>(“Cache-Control: no-cache” + “Pragma: no-cache”)
>>
>> Le site utilise les serveurs de tuile {a,b,c}.tile.openstreetmap.org (ce
>> qui n'est pas explicitement interdit tant que l'on respecte les règles).
>>
>> Je suspect que le nombre de thread dépasse la limite autorisée mais ne me
>> prononcerait pas avec assurance sur ce point (impression que toutes les
>> tuiles sont téléchargées en simultané quand je regarde le graphique Réseau
>> de mon navigateur).
>>
>> Toutes les pages de coins de pêche (ruisseaux, étangs...) sont
>> concernées. Le site parent http://comptoirdespecheurs.com semblant
>> payant je n'ai pas pu y regarder plus loin.
>> Quelqu'un de chevronné ici est-il chargé de faire corriger ces problèmes
>> ou bien dois-je aller au charbon avec doigté ?
>>
>> En vous souhaitant de belles fêtes de fin d'années,
>> Cordialement,
>>
>> --
>> LeTopographeFou
>>
>>
>> ___
>> 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] Site de pêche litigieux

[Philippe Verdy]

A ce sujet le serveur de tuiles cartoCSS d'OSM.org est tombé et n'affiche
plus rien pour le moment, pas même au n iveau de zoom faible sur la carte
du monde qui devrait être en cache.
Il semble que ce soit le proxy cache pour la France qui soit en rade...

Le 28 décembre 2017 à 14:46, LeTopographeFou  a
écrit :

> Bonjour,
>
> Je suis tombé par hasard sur la page https://ou-pecher.fr/coins-de-
> peche-detail/55a6344a2b6dff21167dcaa3/ruisseau-des-coutumes où je
> constate au moins deux infractions selon https://operations.
> osmfoundation.org/policies/tiles/ :
>
>1. OpenStreetMap n'est pas crédité
>2. Le site envoi des en-têtes qui désactivent le cache
>(“Cache-Control: no-cache” + “Pragma: no-cache”)
>
> Le site utilise les serveurs de tuile {a,b,c}.tile.openstreetmap.org (ce
> qui n'est pas explicitement interdit tant que l'on respecte les règles).
>
> Je suspect que le nombre de thread dépasse la limite autorisée mais ne me
> prononcerait pas avec assurance sur ce point (impression que toutes les
> tuiles sont téléchargées en simultané quand je regarde le graphique Réseau
> de mon navigateur).
>
> Toutes les pages de coins de pêche (ruisseaux, étangs...) sont concernées.
> Le site parent http://comptoirdespecheurs.com semblant payant je n'ai pas
> pu y regarder plus loin.
> Quelqu'un de chevronné ici est-il chargé de faire corriger ces problèmes
> ou bien dois-je aller au charbon avec doigté ?
>
> En vous souhaitant de belles fêtes de fin d'années,
> Cordialement,
>
> --
> LeTopographeFou
>
>
> ___
> 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-GB] Importing Shell fuel stations

[Colin Spiller]

I've been adding postcodes in the Bradford BD area using Robert & gregrs 
useful tools. I've just noticed that the Shell station at the Rooley 
Lane / Rooley Avenue junction BD5 8JR is now reported as having an 
incorrect postal unit (the final two letters of the postcode). This 
postcode appears widely on the internet for this site, but the RM 
postcode finder thinks it should be Rooley Avenue, BD6 1DA.


The node Fuel #5210358416  
has these tags:



   Tags

addr:postcode 
 
BD5 8JR
amenity  
fuel 

brand Shell
opening_hours 
 
24/7
phone  	+44 
1274 306188 

ref:navads_shellNVDS353-12038573


but no street or city. The whole thing seems odd to me.

Colin


On 20/12/17 12:32, Ilya Zverev wrote:

Hi folks,

I have just uploaded the fuel stations:

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

Thank you everyone who participated. I noticed there has been many "fixme" tags 
filled during the validation. You can see them all using Overpass API:

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

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


--
Colin Spiller
co...@thespillers.org.uk

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

Re: [Talk-it] cimiteri in Italia

[Dino Michelini]

  Le religioni c'entrano eccome perchè in base alla Costituzione (artt.
8, 19, 20) che ha valenza superiore dell'art. 824 c.c; tutti posso
professare il proprio credo religioso per cui anche il rito della
sepoltura che secondo il rito mussulmano o ebraico hanno tecniche e
esigenze particolari. Per cui devono essere per forza di cose i
rappresentanti delle comunità religiose o i singoli cittadini devono
chiedere delle autorizzazioni all'amministrazione ciomunale per
realizzare aree specifiche rispondenti a questi riti.
Il fatto che il
territorio del cimitero è equiparato come hai giustamente segnalato, al
demanio pubblico significa solo che è sottopostio a un particolare
regime giuridico, che consiste nella inalienabilità e nell'impossibilità
di costituzione di diritti di terzi, se non nei casi e nei modi previsti
dalla legge.

Il 28.12.2017 15:42 Giovanni Berti ha scritto: 

> I
cimiteri in Italia sono demanio pubblico come stabilisce l'articolo 824
dl codice civile. Quindi le religioni non dovrebbero centrare.
> GB
> 
>
Il 28/12/2017 15:36, Dino Michelini ha scritto: 
> 
>> La gestione dei
cimiteri spetta ai Comuni che, in base alle leggi nazionali e regionali,
emanano un proprio regolamento. Nei cimiteri possono essere seppelliti
tutte le persone senza distinzione di origine, cittadinanza, religione,
le salme delle persone decedute nel territorio del Comune o che, ovunque
decedute, avevano nel Comune, al momento della morte, la propria
residenza. Secondo la Costituzione (artt. 8, 19, 20) tutte le persone
hanno gli stessi diritti nel professare una religione. 
>> 
>> Fino alla
revisione dei patti Lateranensi questo non era così scontato, tutti i
cimiteri in Italia erano cattolici "de facto". Oggi con le revisioni
costituzionali intervenute in questi anni i cimiteri italiani non sono
cattolic ma strutture civiche in cui possono essere accolti tutti i
credenti e i non credenti. 
>> 
>> Detto ciò, per cause storiche,
costruzione e gestioni dei cimiteri, oggi per essere sepolti in un
cimitero con altri riti religioso ad es. ebraico o mussulmano, che
prevedono ciascuno tecniche di sepoltura diverse da quella cattolica
occorre individuare all'interno o fuori dei cimiteri cattolici una o più
aree specifiche (speciali) e idonee al seppellimento delle salme ed alla
conservazione dei resti di persone appartenenti a culto diverso da
quello cattolico. Infatti, il regolamento nazionale di polizia
mortuaria, D.P.R. n. 285/90, all'articolo 100, stabilisce che i piani
regolatori cimiteriali "possono prevedere reparti speciali e separati
per la sepoltura di cadaveri di persone professanti un culto diverso da
quello cattolico". Lo stesso articolo consente alle comunità straniere
che ne facciano richiesta di avere in concessione dal sindaco un'area
adeguata del cimitero per crearvi un reparto per la sepoltura dei
connazionali. Per cui credo che ancora valga l'iter della richiesta da
parte delle Amministrazioni comunali dell'autorizzazione delle
Prefetture per accogliere nei cimiteri italiani sepolture diverse.
Quindi, non è sufficiente leggere sulle lapidi cognomi arabi, ebraici,
slavi, ecc. perchè non significa che ti trovi in un area cimiteriale
dove le salme sono sepolte secondo riti religiosi specifici. 
>> 
>> Se
non si conosce nel cimitero l'esatta perimetrazione delle "aree
speciali", ovvero, dove sono le sepolture ad es. con rito mussulmano,
ebraico, ecc. non ha molto senso utilizzare i tag religion=christian e
denomination=catholic ed è sufficiente il tag landuse=cemetery. Forse
l'unico caso in cui religion e denomination possono essere usati con
certezza è il cimitero che non presenta "aree speciali", ovvero quello
dove esiste solo la sepoltura cattolica senza la sepoltura con rito
ebraico, mussulmano, ortotosso, ecc. 
>> 
>> Il 28.12.2017 12:24
Alessandro Palmas ha scritto: 
>> 
>>> Il 28/12/2017 12:08, Volker
Schmidt ha scritto: 
>>> 
 Due domand: 
 
 1)
 I
cimiteri in Italia sono separati per religione e confessione o no?


 Pensavo, da ignorante completo nella materia, che i cimiteri
(landuse=cemetery) in Italia, generalmente, sono comunali e quindi
"usufruibili" da tutti, indipendentemente da religione o confessione.

 In OSM per l'Italia trovo la maggior parte dei cimiteri senza
religione e senza denomination. Trovo anche tanti con
religion=christian, ma senza denomination. E trovo alcuni con
religion=christian e denomination=catholic. 
 Di nuovo da ignorante,
pensavo che i cimiteri attaccati alle chiese cristiane cattoliche
(amenity=grave_yard) sono generalmente "riservati" ai cristiani
cattolici
>>> Io posso parlare per quello monumentale di Genova (che in
questo periodo stiamo migliorando): lì si trovano tutte le religioni e
anche gli atei.
>>> 
>>> Alessandro Ale_Zena_IT
>> 
>> Con Mobile Open 7
GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 200 minuti
ed SMS a 12 cent. Passa a Tiscali Mobile! http://tisca.li/OPEN7GBFirma
[1]
>> 
>> 

Re: [Talk-it] cimiteri in Italia

[Gianluca Boero]

Dalle mie parti in Val Pellice e Val Chisone (To) esistono però dei 
cimiteri Valdesi, alcuni storici altri ancora in uso. La religione è 
Cristiana, però la denominazione è protestante.



Il 28/12/2017 15:42, Giovanni Berti ha scritto:
I cimiteri in Italia sono demanio pubblico come stabilisce l'articolo 
824 dl codice civile. Quindi le religioni non dovrebbero centrare.

GB

Il 28/12/2017 15:36, Dino Michelini ha scritto:
La gestione dei cimiteri spetta ai Comuni che, in base alle leggi 
nazionali e regionali, emanano un proprio regolamento. Nei cimiteri 
possono essere seppelliti tutte le persone senza distinzione di 
origine, cittadinanza, religione, le salme delle persone decedute nel 
territorio del Comune o che, ovunque decedute, avevano nel Comune, al 
momento della morte, la propria residenza. Secondo la Costituzione 
(artt. 8, 19, 20) tutte le persone hanno gli stessi diritti nel 
professare una religione.


Fino alla revisione dei patti Lateranensi questo non era così 
scontato, tutti i cimiteri in Italia erano cattolici "de facto". Oggi 
con le revisioni costituzionali intervenute in questi anni i cimiteri 
italiani non sono cattolic ma strutture civiche in cui possono essere 
accolti tutti i credenti e i non credenti.


Detto ciò, per cause storiche, costruzione e gestioni dei cimiteri, 
oggi per essere sepolti in un cimitero con altri riti religioso ad 
es. ebraico o mussulmano, che prevedono ciascuno tecniche di 
sepoltura diverse da quella cattolica occorre individuare all'interno 
o fuori dei cimiteri cattolici una o più aree specifiche (speciali) e 
idonee al seppellimento delle salme ed alla conservazione dei resti 
di persone appartenenti a culto diverso da quello cattolico. Infatti, 
il regolamento nazionale di polizia mortuaria, D.P.R. n. 285/90, 
all’articolo 100, stabilisce che i piani regolatori cimiteriali 
“possono prevedere reparti speciali e separati per la sepoltura di 
cadaveri di persone professanti un culto diverso da quello 
cattolico”. Lo stesso articolo consente alle comunità straniere che 
ne facciano richiesta di avere in concessione dal sindaco un’area 
adeguata del cimitero per crearvi un reparto per la sepoltura dei 
connazionali. Per cui credo che ancora valga l'iter della richiesta 
da parte delle Amministrazioni comunali dell'autorizzazione delle 
Prefetture per accogliere nei cimiteri italiani sepolture diverse. 
Quindi, non è sufficiente leggere sulle lapidi cognomi arabi, 
ebraici, slavi, ecc. perchè non significa che ti trovi in un area 
cimiteriale dove le salme sono sepolte secondo riti religiosi specifici.


Se non si conosce nel cimitero l'esatta perimetrazione delle "aree 
speciali", ovvero, dove sono le sepolture ad es. con rito mussulmano, 
ebraico, ecc. non ha molto senso utilizzare i tag religion=christian 
e denomination=catholic ed è sufficiente il tag landuse=cemetery. 
Forse l'unico caso in cui religion e denomination possono essere 
usati con certezza è il cimitero che non presenta "aree speciali", 
ovvero quello dove esiste solo la sepoltura cattolica senza la 
sepoltura con rito ebraico, mussulmano, ortotosso, ecc.


Il 28.12.2017 12:24 Alessandro Palmas ha scritto:


Il 28/12/2017 12:08, Volker Schmidt ha scritto:

Due domand:


1)
I cimiteri in Italia sono separati per religione e confessione o no?

Pensavo, da ignorante completo nella materia, che i cimiteri 
(landuse=cemetery) in Italia, generalmente, sono comunali e quindi 
"usufruibili" da tutti, indipendentemente da religione o confessione.
In OSM per l'Italia trovo la maggior parte dei cimiteri senza 
religione e senza denomination. Trovo anche tanti con 
religion=christian, ma senza denomination. E trovo alcuni con 
religion=christian e denomination=catholic.
Di nuovo da ignorante, pensavo che i cimiteri attaccati alle chiese 
cristiane cattoliche (amenity=grave_yard) sono generalmente 
"riservati" ai cristiani cattolici
Io posso parlare per quello monumentale di Genova (che in questo 
periodo stiamo migliorando): lì si trovano tutte le religioni e 
anche gli atei.



Alessandro Ale_Zena_IT




Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di 
Internet e hai 200 minuti ed SMS a 12 cent. Passa a Tiscali Mobile! 
http://tisca.li/OPEN7GBFirma




___
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


--
Gianluca Boero

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

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

[Nicolas Frery]

Le 28/12/2017 à 16:15, Axelos a écrit :
> Le 28/12/2017 à 15:51, Nicolas Frery a écrit :
>> 2) voie cyclable sur trottoir, aucune délimitation
>> https://framapic.org/hYyk6SWFU5vY/duaHrKz1I5gv.PNG
> Pour ce cas je suis dubitatif de l'indiquer comme étant un trottoir, il
> n'y a pas de chaussée à proximité. Pas plutôt highway=path ?
>
> http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpath
Il y a bien un marquage au sol, des carrés vert de 10cm. Suffisamment
pour affirmer sa délimitation avec le cheminement piéton. L'Europe a
financé cet aménagement, la ville ne peut pas supprimer la voie cyclable
(elle aimerait bien).
Je lui ai collé un highway=path bicycle/foot=designated pour coller un
peu mieux à la réalité, même si ça le rapproche d'une voie verte, pas
d'une voie cyclable.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

[Axelos]

Le 28/12/2017 à 15:51, Nicolas Frery a écrit :
> 2) voie cyclable sur trottoir, aucune délimitation
> https://framapic.org/hYyk6SWFU5vY/duaHrKz1I5gv.PNG

Pour ce cas je suis dubitatif de l'indiquer comme étant un trottoir, il
n'y a pas de chaussée à proximité. Pas plutôt highway=path ?

http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpath

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

Re: [OSM-talk-fr] Différencier aménagement cyclables sur trottoir des autres

[Nicolas Frery]

Le 28/12/2017 à 00:25, marc marc a écrit :
> Le 27. 12. 17 à 20:02, Nicolas Frery a écrit :
>> Il faudrait créer une nouvelle valeur pour différencier les voies 
>> cyclables sur trottoir d'une piste cyclable en bonne et due forme.
> de cas cas sur la page wiki parles-tu ?
> tous les cas ont l'air différentié
Les cas S3 et S4 http://wiki.openstreetmap.org/wiki/Bicycle

Voie cyclable sur trottoir ou non ? Rappel qu'un trottoir se rapport à
un cheminement piéton qui n'est pas au niveau de la chaussée. Si la voie
cyclable est au même niveau que le cheminement piéton, alors elle est
sur le trottoir.

Exemple avec 4 cas:
1) voie cyclable sur trottoir bien délimitée (ne regardons pas les
largeurs honteuses des différents cheminements)
https://framapic.org/2X8j458fJxkC/NEMJqGVzxxGT.PNG

2) voie cyclable sur trottoir, aucune délimitation
https://framapic.org/hYyk6SWFU5vY/duaHrKz1I5gv.PNG

3) piste cyclable et trottoir séparé par une marche de quelques centimètres
https://framapic.org/97lY57zM6TEE/iLKmEw0MB4KY.PNG

Dans le cas 3 le scénario S4 convient tout à fait, c'est ici une piste
cyclable bien différente du trottoir. Trois
highway=cycleway/footway/secondary décrivent correctement la situation.
Dans le cas 2 la ville n'a pas marqué correctement la voie cyclable (qui
existe bien et aurait dû être tracée comme le cas 1), cette voie
cyclable est *sur* le trottoir. Pourtant elle sera taguée comme le cas
3, alors que tout à fait différente. La voie cyclable faisant partie
intégralement du trottoir. Pour un cycliste urbain, ce type de voie se
traduit par une vitesse de circulation très faible pour faire face à
l'affluence de piétons.
Dans le cas 1 le marquage ne prête pas à confusion, mais la voie
cyclable fait tout de même partie intégrante du trottoir.
Trois cas différents, mais une seule possibilité de taguer.

Avec un tag cycleway=sidewalk, les cas 1 et 2 auraient déjà pu être
différencié du 3.

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

Re: [Talk-it] cimiteri in Italia

[Giovanni Berti]

I cimiteri in Italia sono demanio pubblico come stabilisce l'articolo 
824 dl codice civile. Quindi le religioni non dovrebbero centrare.

GB

Il 28/12/2017 15:36, Dino Michelini ha scritto:
La gestione dei cimiteri spetta ai Comuni che, in base alle leggi 
nazionali e regionali, emanano un proprio regolamento. Nei cimiteri 
possono essere seppelliti tutte le persone senza distinzione di 
origine, cittadinanza, religione, le salme delle persone decedute nel 
territorio del Comune o che, ovunque decedute, avevano nel Comune, al 
momento della morte, la propria residenza. Secondo la Costituzione 
(artt. 8, 19, 20) tutte le persone hanno gli stessi diritti nel 
professare una religione.


Fino alla revisione dei patti Lateranensi questo non era così 
scontato, tutti i cimiteri in Italia erano cattolici "de facto". Oggi 
con le revisioni costituzionali intervenute in questi anni i cimiteri 
italiani non sono cattolic ma strutture civiche in cui possono essere 
accolti tutti i credenti e i non credenti.


Detto ciò, per cause storiche, costruzione e gestioni dei cimiteri, 
oggi per essere sepolti in un cimitero con altri riti religioso ad es. 
ebraico o mussulmano, che prevedono ciascuno tecniche di sepoltura 
diverse da quella cattolica occorre individuare all'interno o fuori 
dei cimiteri cattolici una o più aree specifiche (speciali) e idonee 
al seppellimento delle salme ed alla conservazione dei resti di 
persone appartenenti a culto diverso da quello cattolico. Infatti, il 
regolamento nazionale di polizia mortuaria, D.P.R. n. 285/90, 
all’articolo 100, stabilisce che i piani regolatori cimiteriali 
“possono prevedere reparti speciali e separati per la sepoltura di 
cadaveri di persone professanti un culto diverso da quello cattolico”. 
Lo stesso articolo consente alle comunità straniere che ne facciano 
richiesta di avere in concessione dal sindaco un’area adeguata del 
cimitero per crearvi un reparto per la sepoltura dei connazionali. Per 
cui credo che ancora valga l'iter della richiesta da parte delle 
Amministrazioni comunali dell'autorizzazione delle Prefetture per 
accogliere nei cimiteri italiani sepolture diverse. Quindi, non è 
sufficiente leggere sulle lapidi cognomi arabi, ebraici, slavi, ecc. 
perchè non significa che ti trovi in un area cimiteriale dove le salme 
sono sepolte secondo riti religiosi specifici.


Se non si conosce nel cimitero l'esatta perimetrazione delle "aree 
speciali", ovvero, dove sono le sepolture ad es. con rito mussulmano, 
ebraico, ecc. non ha molto senso utilizzare i tag religion=christian e 
denomination=catholic ed è sufficiente il tag landuse=cemetery. Forse 
l'unico caso in cui religion e denomination possono essere usati con 
certezza è il cimitero che non presenta "aree speciali", ovvero quello 
dove esiste solo la sepoltura cattolica senza la sepoltura con rito 
ebraico, mussulmano, ortotosso, ecc.


Il 28.12.2017 12:24 Alessandro Palmas ha scritto:


Il 28/12/2017 12:08, Volker Schmidt ha scritto:

Due domand:


1)
I cimiteri in Italia sono separati per religione e confessione o no?

Pensavo, da ignorante completo nella materia, che i cimiteri 
(landuse=cemetery) in Italia, generalmente, sono comunali e quindi 
"usufruibili" da tutti, indipendentemente da religione o confessione.
In OSM per l'Italia trovo la maggior parte dei cimiteri senza 
religione e senza denomination. Trovo anche tanti con 
religion=christian, ma senza denomination. E trovo alcuni con 
religion=christian e denomination=catholic.
Di nuovo da ignorante, pensavo che i cimiteri attaccati alle chiese 
cristiane cattoliche (amenity=grave_yard) sono generalmente 
"riservati" ai cristiani cattolici
Io posso parlare per quello monumentale di Genova (che in questo 
periodo stiamo migliorando): lì si trovano tutte le religioni e anche 
gli atei.



Alessandro Ale_Zena_IT




Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di 
Internet e hai 200 minuti ed SMS a 12 cent. Passa a Tiscali Mobile! 
http://tisca.li/OPEN7GBFirma




___
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] réflexion sur l'ia appliqué aux cartes

[Vincent Frison]

Article très intéressant !

Comme l'auteur je me demande quelle est la relation entre la technique leur
permettant d'avoir des modèles full 3D des villes lorsqu'on est en mode
satellite/3D et celle leur permettant d'avoir des empreintes de bâtiments
extrêmement précises (+ infos de hauteur visiblement) lorsqu'on en mode
carte / par défaut.

Mais dans le 1er cas c'est clairement fait avec de la photogrammétrie alors
que dans le 2e cas l'auteur laisse penser que les algos de Google se
seraient basés des images ariennes standards... ce qui me semble peu
probable. A mon avis ils font d'abord de la photogrammétrie, et une fois
qu'ils ont leur modèle 3D ils peuvent (re)dessiner les bâtiments pour le
mode carte / par défaut.


Le 25 décembre 2017 à 15:32,  a écrit :

> Autant l'exemple de Christian est bon (on peut détecter non seulement la
> forme mais aussi l'encombrement - un toit plat incliné vers le sud est
> idéal mais s'il est occupé par des cheminées et autres antennes, il est
> moins utilisable pour du solaire), autant l'exemple de Google alourdit la
> carte.
>
> Déjà nos empreintes de bâtiments sont la moitié de la base.
>
> Dans l'article de Google ils disent que ça permet de reconnaître plus
> facilement un bâtiment. Exact. Sauf qu'il ne faut le faire que pour les
> bâtiments remarquables et mettre en avant les traits remarquables.
>
> J'entends pour de la cartographie. Par exemple quand Google détecte une
> parabole sur un bâtiment, c'est utile si ça permet de le repérer parmi 10
> bâtiments identiques, sinon c'est sans intérêt pour la quasi totalité des
> utilisateurs et apportera plus un bruit de fond (aussi un aspect réaliste
> pour une simulation 3D).
>
> De même on trace les routes, on ne les dessine pas (avoir la largeur de la
> route n'est pas inutile, par contre le détail importe peu et peu nuire à la
> lisibilité : un bon livre d'ornithologie dessine des caractéristiques de
> l'oiseau et ne donne pas une photo de l'animal).
>
> Bon, super, avec de l'IA je fais un programme qui ajoute surface=aslphat
> sur des routes en fonction de la couleur et hop, plein de bitcoins sur mon
> compte.
>
> Donc IA oui, mais à bon escient.
>
>
> /\
>
>   /__\
>
> /\
>
>   /__\
>
> /\
>
>|_|
>
> Ceci n'est pas un sapin ;-)
>
> Jean-Yvon
>
> Le 24/12/2017 à 10:15, François Lacombe - fl.infosrese...@gmail.com a
> écrit :
>
> Bonjour
>
> Je partage également votre avis, les techniques d'apprentissage
> permettraient aussi de détecter les biais dans l'utilisation des tags.
> Surtout signaler à l'utilisateur que certaines combinaisons sont peu
> utilisées en proportion à l'utilisation des clés concernées donc
> probablement erronées  (building + man_made=street_cabinet par ex)
>
> Ca permettrait de faciliter le travail de developpelent d'osmose
>
> My 2 cents
>
> François
>
> Le 23 déc. 2017 1:15 PM, "Martin Noblecourt"  a
> écrit :
>
>> Tout à fait d'accord avec Christian !
>>
>> Les initiatives se multiplient de télédétection automatique, l'enjeu va
>> être une intégration harmonieuse avec la base de données et la culture OSM
>> existante, donc forcément avec une intervention humaine pour
>> contrôler/harmoniser.
>>
>> Côté CartONG on a plusieurs petites expérimentations dans les tuyaux
>> (pré-reconnaissance automatique des zones résidentielles avant validation
>> humaine notamment), si des gens sont intéressés pour aider nos bénévoles là
>> dessus, n'hésitez pas à me contacter ;-)
>>
>> Joyeux Noël à tous !
>>
>> Martin
>>
>> On 23/12/2017 13:00, talk-fr-requ...@openstreetmap.org wrote:
>>
>> Subject:
>> Re: [OSM-talk-fr] réflexion sur l'ia appliqué aux cartes
>>
>> From:
>> Christian Quest  
>>
>> Date:
>> 23/12/2017 12:49
>>
>> To:
>> Discussions sur OSM en français 
>> 
>> Je suis persuadé qu'on ira de plus en plus dans cette direction.
>> OpenSolarMap a permis d'apprendre dans ce domaine, ce sont des technique de
>> plus en plus accessibles et il serait dommage de s'en priver.
>>
>> Comme toujours, il faut bien voir ce que ça apporte et les limites.
>> Si on prend le GPS, il a permis à OSM de décoller, mais ce n'est pas pour
>> cela qu'on utilise les traces GPS brutes pour tracer les routes et chemins.
>>
>> Ce sont des outils qui servent à simplifier et automatiser ce qui peut
>> l'être sans perte de qualité par rapport à du travail de fourmis humaines.
>>
>>
>> Le 23 décembre 2017 à 12:41, marc marc  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> Petite article intéressant (même si un peu long)
>>> https://www.justinobeirne.com/google-maps-moat
>>> l’intéressant pour osm n'est pas la comparaison apple <> google mais
>>> l'utilisation de l'ia.
>>> pendant qu'on fait dessine à la main le contour des batiments dans
>>> certains pays, le computer vision le fait en masse.
>>> Il y a aussi un 

Re: [Talk-it] cimiteri in Italia

[Dino Michelini]

  La gestione dei cimiteri spetta ai Comuni che, in base alle leggi
nazionali e regionali, emanano un proprio regolamento. Nei cimiteri
possono essere seppelliti tutte le persone senza distinzione di origine,
cittadinanza, religione, le salme delle persone decedute nel territorio
del Comune o che, ovunque decedute, avevano nel Comune, al momento della
morte, la propria residenza. Secondo la Costituzione (artt. 8, 19, 20)
tutte le persone hanno gli stessi diritti nel professare una religione.


Fino alla revisione dei patti Lateranensi questo non era così
scontato, tutti i cimiteri in Italia erano cattolici "de facto". Oggi
con le revisioni costituzionali intervenute in questi anni i cimiteri
italiani non sono cattolic ma strutture civiche in cui possono essere
accolti tutti i credenti e i non credenti. 

Detto ciò, per cause
storiche, costruzione e gestioni dei cimiteri, oggi per essere sepolti
in un cimitero con altri riti religioso ad es. ebraico o mussulmano, che
prevedono ciascuno tecniche di sepoltura diverse da quella cattolica
occorre individuare all'interno o fuori dei cimiteri cattolici una o più
aree specifiche (speciali) e idonee al seppellimento delle salme ed alla
conservazione dei resti di persone appartenenti a culto diverso da
quello cattolico. Infatti, il regolamento nazionale di polizia
mortuaria, D.P.R. n. 285/90, all'articolo 100, stabilisce che i piani
regolatori cimiteriali "possono prevedere reparti speciali e separati
per la sepoltura di cadaveri di persone professanti un culto diverso da
quello cattolico". Lo stesso articolo consente alle comunità straniere
che ne facciano richiesta di avere in concessione dal sindaco un'area
adeguata del cimitero per crearvi un reparto per la sepoltura dei
connazionali. Per cui credo che ancora valga l'iter della richiesta da
parte delle Amministrazioni comunali dell'autorizzazione delle
Prefetture per accogliere nei cimiteri italiani sepolture diverse.
Quindi, non è sufficiente leggere sulle lapidi cognomi arabi, ebraici,
slavi, ecc. perchè non significa che ti trovi in un area cimiteriale
dove le salme sono sepolte secondo riti religiosi specifici. 

Se non si
conosce nel cimitero l'esatta perimetrazione delle "aree speciali",
ovvero, dove sono le sepolture ad es. con rito mussulmano, ebraico, ecc.
non ha molto senso utilizzare i tag religion=christian e
denomination=catholic ed è sufficiente il tag landuse=cemetery. Forse
l'unico caso in cui religion e denomination possono essere usati con
certezza è il cimitero che non presenta "aree speciali", ovvero quello
dove esiste solo la sepoltura cattolica senza la sepoltura con rito
ebraico, mussulmano, ortotosso, ecc. 

Il 28.12.2017 12:24 Alessandro
Palmas ha scritto: 

> Il 28/12/2017 12:08, Volker Schmidt ha scritto:

> 
>> Due domand: 
>> 
>> 1)
>> I cimiteri in Italia sono separati per
religione e confessione o no?
>> 
>> Pensavo, da ignorante completo
nella materia, che i cimiteri (landuse=cemetery) in Italia,
generalmente, sono comunali e quindi "usufruibili" da tutti,
indipendentemente da religione o confessione. 
>> In OSM per l'Italia
trovo la maggior parte dei cimiteri senza religione e senza
denomination. Trovo anche tanti con religion=christian, ma senza
denomination. E trovo alcuni con religion=christian e
denomination=catholic. 
>> Di nuovo da ignorante, pensavo che i cimiteri
attaccati alle chiese cristiane cattoliche (amenity=grave_yard) sono
generalmente "riservati" ai cristiani cattolici
> Io posso parlare per
quello monumentale di Genova (che in questo periodo stiamo migliorando):
lì si trovano tutte le religioni e anche gli atei.
> 
> Alessandro
Ale_Zena_IT
  


Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 
200 minuti ed SMS a 12 cent. Passa a Tiscali Mobile! 
http://tisca.li/OPEN7GBFirma

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

Re: [Talk-us] Walmart Import

[Ilya Zverev]

Hi Peter,

Thank you for the extended example of opening_hours containing holidays 
exceptions. While validating the Walmart import, I've encountered a couple of 
these, albeit simpler.

My opinion on tags does not have an extra weight in relation to other mappers. 
With the introduction of the "Conflation Audit" website, to which I link, the 
data owner does not dictate which tags to overwrite as well. By participating 
in validation, you choose which tags to keep and which to override, and where 
to place imported points.

For example, when seeing "24/7; Dec 25 off" on a Walmart, I clicked on that 
line, so it doesn't get overwritten on import. The line becomes highlighted, 
which means that's what will be in OSM after the import. See for an example 
this object:

http://audit.osmz.ru/browse/walmart/4404

Sorry I didn't get to answer earlier,
Ilya

> 22 дек. 2017 г., в 10:46, Peter Dobratz  написал(а):
> 
> Ilya,
> 
> I'm trying to wrap my head around how making this a "frictionless series of 
> imports" is going to work.  So if a local mapper edits details on a Walmart, 
> those details could potentially be swiftly overwritten with your data?
> 
> As you can see, the opening hours for next week are non-standard due to the 
> Christmas holiday.  What if someone decides they want to add that level of 
> detail to the opening_hours tag:
> opening_hours=00:00-01:00,05:00-24:00; Dec 24 5:00-18:00; Dec 25 off; Dec 26 
> 06:00-24:00
> 
> How long until you automatically replace this with "05:00-01:00" ?
> 
> Do you see the problem with doing that?
> 
> As you say there are differences of opinion in how things are tagged.  Why 
> does your opinion get to have more weight?
> 
> Peter
> 
> On Thu, Dec 21, 2017 at 1:12 AM, Ilya Zverev  wrote:
> Hi Peter,
> 
> Thank you for suggestions.
> 
> First, the highlighted tag value is what goes into OSM. In your case, the 
> import will keep the shop=department_store.
> 
> Regarding updates to opening_hours, you are suggesting I parse each 
> opening_hours value and then compare these? It would be quite hard and in my 
> opinion excessive. With the two values being equivalent, I don't how the data 
> becomes worse. A few times I omitted "Mo-Su", I was being told it's better to 
> specify the weekdays, so it is again a matter of opinion.
> 
> In your example, you override the definition for Monday, so it doesn't 
> demonstrate anything besides how complex the opening_hours notation is.
> 
> The rest I answered in imports@, and some of it goes against what other 
> community members suggest, so again I can conclude that is a matter of 
> opinion and not important one way or another:
> 
> * URL is provided by Walmart and is much better than what we have. /whats-new 
> can be fixed later, and does not really matter, because it still takes to a 
> store page.
> * addr:full is provided by Walmart and may be used to improve addressing 
> where there are no addr:* tags. Sorry the importing script cannot do 
> conditional tagging.
> * operator was recommended by community members, and is a good tag to filter 
> all Walmarts.
> * ref:walmart will be used for updating the data. Ref may refer not only to a 
> store, but to a building or another feature.
> 
> Please understand that this is not a one-off handcrafted import. We are 
> working on a process for frictionless series of imports, with regular updates 
> later on. I understand you have mapped a Walmart and feel protective of it. I 
> felt the same a few years into OSM, because everything you add to the map is 
> important. With this import, I believe it does not make the data worse. More 
> attributes is not bad, even if some of these are redundant. The main thing 
> is, until now there were zero mappers who care about keeping all the Walmart 
> stores in OSM up-to-date, and after, there will be more. To me, that is a 
> good thing.
> 
> Thanks,
> Ilya
> 
> 
> > 21 дек. 2017 г., в 1:22, Peter Dobratz  написал(а):
> >
> > Ilya,
> >
> > Here's a Walmart that's been built in the last few years I recently added 
> > to OSM:
> >
> > http://audit.osmz.ru/browse/walmart/5935
> >
> > What's currently in OSM represents my own mapping style, but I think it's 
> > worth discussing the differences before you change them across the whole 
> > country.
> >
> >
> > If I read this correctly, you are planning on changing the top-level tag 
> > from shop=department_store to shop=supermarket.  I have been using 
> > shop=supermarket only for Walmarts branded as "Walmart Neighborhood Market" 
> > and using shop=department_store for all other Walmarts.  For me the main 
> > distinction is that most Walmarts have departments for things like clothing 
> > and electronics that don't exist in the "Walmart Neighborhood Market" 
> > stores.
> >
> >
> > You are proposing changing the opening_hours tag from 
> > "00:00-01:00,05:00-24:00" to "Mo-Su 05:00-01:00".  When I'm adding opening 
> > hours, I 

[OSM-talk-fr] Rendu avec relief sur osm.org

[Vincent Frison]

Hello,

Je sais pas si je suis le seul mais pour moi les cartes affichant le
relief, c'est à dire avec hillshade et/ou courbes de niveaux, sont bien
plus jolies que celles sont relief. Je dirais même qu'en plus d'être plus
jolies elles sont beaucoup plus claires car elles permettent de se repérer
plus facilement avec le relief.

Le souci c'est que le rendu par défaut de osm.org n'a pas le relief et je
trouve ça plus que dommage.

Il y a des sites proposant des rendus avec reliefs qui sont magnifiques
comme par ex. http://opentopomap.org ou http://opensnowmap.org. Le problème
c'est qu'ils n'ont pas la rapidité d'osm.org, ni toutes ses fonctionnalités
(principalement celle qui permet de chercher les objets afin de voir tous
les détails).

Certes il y a le layer "carte cyclable" d'osm.org mais malheureusement le
relief est assez mal rendu et puis surtout il est vraiment orienté pour les
vélos en masquant la plupart des informations pour mettre en valeur celles
utiles aux cyclistes.

J'ai l'impression que ça ne serait pas un énorme travail de rajouter le
relief sur le rendu par défaut d'osm.org. L'idée serait d'avoir une option
pour afficher le hillshade et les courbes de niveaux. c'est à dire 2
petites checkboxes en plus de celles existantes (permettant d'afficher les
notes de carte, etc.).

Sur le site http://opensnowmap.org en allant dans les settings on peut
afficher le rendu standard d'OSM au lieu de celui d'OpenSnow.  J'ai
l'impression que c'est juste un layer supplémentaire (avec hillshade et
courbes de niveaux) qui s'affiche en plus de celui du rendu standard.. mais
qui du coup n'a plus rien à voir avec le rendu classique, pour moi la
valeur ajoutée est vraiment énorme !

Suis je le seul à qui ça manque ?

Et à qui devrais  je demander cette évolution ? Sur un mailing list
particulière ou directement en créant une issue ici:
https://github.com/gravitystorm/openstreetmap-carto ?

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

Re: [OSM-talk] Standard map style contributions

[Daniel Koć]

W dniu 28.12.2017 o 14:34, James pisze:
Although the rest seems like CSS or a variation there of the project 
is big and they may not grasp everything. Proper documentation for me 
is a major factor, if the project doesnt have 
documentation(developement not user guides or at least well placed 
comments) it helps people get into it faster as they know what parts 
do what vs reading all of the project and guessing what parts do what.


I've written a general overview on Wiki lately to understand the basic 
parts of osm-carto:


https://wiki.openstreetmap.org/wiki/Standard_tile_layer

Detailed documentation is in the repo, especially in this file:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md

However I'm not able to guess what exactly is needed, since I'm involved 
in it for too long and because nobody is asking questions about how to 
start.


It also depends on how many people are interested at all and what is 
their background. For 1-2 persons it'll be easier for me to help 
personally case by case (which I'm willing to do), while for 10-20 it 
makes sense to develop more documentation or explain some examples in 
the diary.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk] Standard map style contributions

[James]

Lack of time due to real life preoccupations?

On Dec 28, 2017 8:45 AM, "Mateusz Konieczny"  wrote:

> If somebody tried contributing and missing documentation was what
> stopped him/her - what was missing?
>
> On Thu, 28 Dec 2017 08:34:34 -0500
> James  wrote:
>
> > Although the rest seems like CSS or a variation there of the project
> > is big and they may not grasp everything. Proper documentation for me
> > is a major factor, if the project doesnt have
> > documentation(developement not user guides or at least well placed
> > comments) it helps people get into it faster as they know what parts
> > do what vs reading all of the project and guessing what parts do what.
> >
> > On Dec 28, 2017 8:25 AM, "Daniel Koć"  wrote:
> >
> > > W dniu 28.12.2017 o 14:04, James pisze:
> > >
> > >> not everyone knows lua scripting might be one of the major herdles
> > >>
> > >
> > > Is this what keeps you away from the code or there are some other
> > > obstacles? I'm most interested in hearing personal reasons,
> > > whatever they might be.
> > >
> > > Fortunately lua scripting is not needed most of the time. For
> > > example I never had to touch it, though I make a lot of changes in
> > > osm-carto, so I would not worry about it.
> > >
> > > --
> > > "My method is uncertain/ It's a mess but it's working" [F. Apple]
> > >
> > >
> > > ___
> > > 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-fr] Site de pêche litigieux

[LeTopographeFou]

Bonjour,

Je suis tombé par hasard sur la page 
https://ou-pecher.fr/coins-de-peche-detail/55a6344a2b6dff21167dcaa3/ruisseau-des-coutumes 
où je constate au moins deux infractions selon 
https://operations.osmfoundation.org/policies/tiles/ :


1. OpenStreetMap n'est pas crédité
2. Le site envoi des en-têtes qui désactivent le cache (“Cache-Control:
   no-cache” + “Pragma: no-cache”)

Le site utilise les serveurs de tuile {a,b,c}.tile.openstreetmap.org (ce 
qui n'est pas explicitement interdit tant que l'on respecte les règles).


Je suspect que le nombre de thread dépasse la limite autorisée mais ne 
me prononcerait pas avec assurance sur ce point (impression que toutes 
les tuiles sont téléchargées en simultané quand je regarde le graphique 
Réseau de mon navigateur).


Toutes les pages de coins de pêche (ruisseaux, étangs...) sont 
concernées. Le site parent http://comptoirdespecheurs.com semblant 
payant je n'ai pas pu y regarder plus loin.


Quelqu'un de chevronné ici est-il chargé de faire corriger ces problèmes 
ou bien dois-je aller au charbon avec doigté ?


En vous souhaitant de belles fêtes de fin d'années,
Cordialement,

--
LeTopographeFou

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

Re: [OSM-talk] Standard map style contributions

[Mateusz Konieczny]

If somebody tried contributing and missing documentation was what
stopped him/her - what was missing?

On Thu, 28 Dec 2017 08:34:34 -0500
James  wrote:

> Although the rest seems like CSS or a variation there of the project
> is big and they may not grasp everything. Proper documentation for me
> is a major factor, if the project doesnt have
> documentation(developement not user guides or at least well placed
> comments) it helps people get into it faster as they know what parts
> do what vs reading all of the project and guessing what parts do what.
> 
> On Dec 28, 2017 8:25 AM, "Daniel Koć"  wrote:
> 
> > W dniu 28.12.2017 o 14:04, James pisze:
> >  
> >> not everyone knows lua scripting might be one of the major herdles
> >>  
> >
> > Is this what keeps you away from the code or there are some other
> > obstacles? I'm most interested in hearing personal reasons,
> > whatever they might be.
> >
> > Fortunately lua scripting is not needed most of the time. For
> > example I never had to touch it, though I make a lot of changes in
> > osm-carto, so I would not worry about it.
> >
> > --
> > "My method is uncertain/ It's a mess but it's working" [F. Apple]
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >  


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

Re: [OSM-talk] Standard map style contributions

[James]

Although the rest seems like CSS or a variation there of the project is big
and they may not grasp everything. Proper documentation for me is a major
factor, if the project doesnt have documentation(developement not user
guides or at least well placed comments) it helps people get into it faster
as they know what parts do what vs reading all of the project and guessing
what parts do what.

On Dec 28, 2017 8:25 AM, "Daniel Koć"  wrote:

> W dniu 28.12.2017 o 14:04, James pisze:
>
>> not everyone knows lua scripting might be one of the major herdles
>>
>
> Is this what keeps you away from the code or there are some other
> obstacles? I'm most interested in hearing personal reasons, whatever they
> might be.
>
> Fortunately lua scripting is not needed most of the time. For example I
> never had to touch it, though I make a lot of changes in osm-carto, so I
> would not worry about it.
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Standard map style contributions

[Daniel Koć]

W dniu 28.12.2017 o 14:04, James pisze:

not everyone knows lua scripting might be one of the major herdles


Is this what keeps you away from the code or there are some other 
obstacles? I'm most interested in hearing personal reasons, whatever 
they might be.


Fortunately lua scripting is not needed most of the time. For example I 
never had to touch it, though I make a lot of changes in osm-carto, so I 
would not worry about it.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk] Standard map style contributions

[James]

not everyone knows lua scripting might be one of the major herdles

On Dec 28, 2017 5:49 AM, "Daniel Koć"  wrote:

> Hi,
>
> We have a lot of tickets waiting for solving in osm-carto (almost 400) and
> I'm interested how could we do it effectively.
>
> It's not realistic to expect that the core team would be able to catch up
> and that's why we took some care to help other people to contribute. Most
> important thing was preparing the Docker environment, which makes
> installing and testing a lot easier, but there are also some documents
> explaining the inner working of the project and even some very easy tasks
> to pick:
>
> https://github.com/gravitystorm/openstreetmap-carto/labels/
> good%20first%20issue
>
> However after almost half a year we still don't have too many
> contributions from other people and I'm curious what are the main obstacles
> which prevent it and what else could we possibly change to make it easier?
> There's also more basic question: how many people are interested in
> contributing to osm-carto at all?
>
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
> ___
> 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] massgis:MANAGR_ABR=M173BS, massgis:DEED_ACRES=0.00000000 and other useless(?) tags

[Mateusz Konieczny]

I encountered https://www.openstreetmap.org/way/29690455 that is
obviously result of some unfinished import - somebody dumped random
database fields into OSM such as

massgis:DEED_ACRES=0.
massgis:MANAGR_ABR=M173BS

and many other tags such as:

massgis:ARTICLE97
massgis:ASSESS_ACR
massgis:ASSESS_LOT
massgis:ASSESS_MAP
massgis:ATT_DATE
massgis:EOEAINVOLV
massgis:FEESYM
massgis:FY_FUNDING
massgis:LEV_PROT
massgis:MANAGR_ABR
massgis:MANAGR_TYP
massgis:OS_DEED_BO
massgis:OS_DEED_PA
massgis:OWNER_ABRV
massgis:PRIM_PURP

There are also tags that are an internal database info and seem to be
utterly useless for OSM.

massgis:SOURCE_MAP
massgis:SOURCE_TYP
massgis:BASE_MAP
massgis:DCAM_ID
massgis:OS_ID
massgis:POLY_ID
massgis:TOWN_ID

Area is already available from geometry itself - it should not be tagged
separately - so this tag is also probably useless.

massgis:DEED_ACRES

There are also some tags that in theory may be useful but meaning is
unclear.

massgis:PUB_ACCESS
massgis:OWNER_TYPE
massgis:FEE_OWNER
massgis:MANAGER

And there is massgis:SITE_NAME, useful if it is different from name tag
(there are even 1729 ways with massgis:SITE_NAME, without name tag
indicating either really poorly done import or probably unwanted data
deletion - see http://overpass-turbo.eu/s/u3L )

Such useless tags are confusing and may mislead future users
that dumping random tags into OSM is a good idea. I think that data
would be improved by deleting such tags (except massgis:SITE_NAME that
is potentially useful).

Would it be OK to delete 

massgis:ARTICLE97
massgis:ASSESS_ACR
massgis:ASSESS_LOT
massgis:ASSESS_MAP
massgis:ATT_DATE
massgis:EOEAINVOLV
massgis:FEESYM
massgis:FY_FUNDING
massgis:LEV_PROT
massgis:MANAGR_ABR
massgis:MANAGR_TYP
massgis:OS_DEED_BO
massgis:OS_DEED_PA
massgis:OWNER_ABRV
massgis:PRIM_PURP
massgis:SOURCE_MAP
massgis:SOURCE_TYP
massgis:BASE_MAP
massgis:DCAM_ID
massgis:OS_ID
massgis:POLY_ID
massgis:TOWN_ID
massgis:DEED_ACRES

tags across USA? Would it be OK to do it with a mechanical edit? If yes
- what should be done before doing that?

If such tags have some value - can you consider documenting them on the
OSM wiki?

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

Re: [Talk-it] cimiteri in Italia

[Edoardo Yossef Marascalchi]

ci sono cimiteri separati. alcuni grandi cimiteri hanno aree riservate a
non cristiani (ebrei, mussulmani, scomunicati...)
in varie parti d'Italia esistono cimiteri per soli ebrei (milano, roma,
venezia, rovigo...)
non so se ne esistano per mussulmami ma immagino di si



Il 28 dic 2017 1:25 PM, "Alessandro Palmas" 
ha scritto:

> Il 28/12/2017 12:08, Volker Schmidt ha scritto:
>
> Due domand:
>
>
> 1)
> I cimiteri in Italia sono separati per religione e confessione o no?
>
> Pensavo, da ignorante completo nella materia, che i cimiteri
> (landuse=cemetery) in Italia, generalmente, sono comunali e quindi
> "usufruibili" da tutti, indipendentemente da religione o confessione.
>
> In OSM per l'Italia trovo la maggior parte dei cimiteri senza religione e
> senza denomination. Trovo anche tanti con religion=christian, ma senza
> denomination. E trovo alcuni con religion=christian e denomination=catholic.
>
> Di nuovo da ignorante, pensavo che i cimiteri attaccati alle chiese
> cristiane cattoliche (amenity=grave_yard) sono generalmente "riservati" ai
> cristiani cattolici
>
> Io posso parlare per quello monumentale di Genova (che in questo periodo
> stiamo migliorando): lì si trovano tutte le religioni e anche gli atei.
>
>
> Alessandro Ale_Zena_IT
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-es] Talleres de iniciación a OSM en Madrid

[Miguel Sevilla-Callejo]

Lo he rebotado a la lista de geoinquietos general [1] a ver si desde Madrid
(algunos está en esta lista) para ver si pueden hacerse cargo.
Un saludo
M

[1] geoinquietos...@lists.osgeo.org /
https://lists.osgeo.org/pipermail/geoinquietos-es/2017-December/000353.html

--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2017-12-27 15:23 GMT+01:00 dcapillae :

> Hola,
>
> Inicialmente he pensado en Geoinquietos Madrid por su relación con OSM. Sé
> que hace poco organizaron un taller de iniciación al mapeo humanitario.
> Todavía no me he puesto en contacto con ellos, aunque doy por hecho que se
> animarán a colaborar. He preferido antes consultar con la lista, por si me
> podéis ofrecer alguna otra referencia.
>
> Salvo Geoinquietos Madrid, no conozco a ningún otro grupo en la capital. Si
> fueran de Zaragoza, les pondría sin duda en contacto con Mapeado
> Colaborativo, pero en Madrid no tengo referencias de ningún otro grupo de
> usuarios.
>
> Estoy en contacto con un grupo de personas de Madrid muy interesadas en
> aprender lo básico de OSM, sobre todo en temas relacionados con la
> bicicleta
> (aunque no sólo). He pensado que sería genial organizarles un taller de
> iniciación para orientarles en sus primeros pasos y animarles a seguir
> contribuyendo a mejorar el mapa de la ciudad.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] cimiteri in Italia

[Alessandro Palmas]

Il 28/12/2017 12:08, Volker Schmidt ha scritto:

Due domand:


1)
I cimiteri in Italia sono separati per religione e confessione o no?

Pensavo, da ignorante completo nella materia, che i cimiteri 
(landuse=cemetery) in Italia, generalmente, sono comunali e quindi 
"usufruibili" da tutti, indipendentemente da religione o confessione.


In OSM per l'Italia trovo la maggior parte dei cimiteri senza 
religione e senza denomination. Trovo anche tanti con 
religion=christian, ma senza denomination. E trovo alcuni con 
religion=christian e denomination=catholic.


Di nuovo da ignorante, pensavo che i cimiteri attaccati alle chiese 
cristiane cattoliche (amenity=grave_yard) sono generalmente 
"riservati" ai cristiani cattolici
Io posso parlare per quello monumentale di Genova (che in questo periodo 
stiamo migliorando): lì si trovano tutte le religioni e anche gli atei.



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

[Talk-it] cimiteri in Italia

[Volker Schmidt]

Due domand:


1)
I cimiteri in Italia sono separati per religione e confessione o no?

Pensavo, da ignorante completo nella materia, che i cimiteri
(landuse=cemetery) in Italia, generalmente, sono comunali e quindi
"usufruibili" da tutti, indipendentemente da religione o confessione.

In OSM per l'Italia trovo la maggior parte dei cimiteri senza religione e
senza denomination. Trovo anche tanti con religion=christian, ma senza
denomination. E trovo alcuni con religion=christian e denomination=catholic.

Di nuovo da ignorante, pensavo che i cimiteri attaccati alle chiese
cristiane cattoliche (amenity=grave_yard) sono generalmente "riservati" ai
cristiani cattolici

2)
Pensavo che landuse=cemetery e amenity=grave_yard sono alternative. Trovo
parecchi cimiteri con entrambi i tag.



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

Re: [OSM-talk] Generate polygons out of administrative Relations

[Nic]

Thanks Frederik!

I will give osm2pgsql a try.
Any recommended URL where I can start reading about the "style file"
approach to only load boundaries?

Nic

Am Donnerstag, den 28.12.2017, 11:19 +0100 schrieb Frederik Ramm:
> Hi,
> 
> On 28.12.2017 10:37, Nic wrote:
> > 
> > I want to generate a polygon out of the different members/ways of
> > an
> > administrative relation (e.g. Bundesland).
> > For that purpose I have loaded a pbf file via osmosis into a
> > postgresql/postgis database.
> That makes things unnecessarily difficult. Use osm2pgsql to load the
> data instead, and the polygons will be built for you. You can even
> use a
> so-called "style file" with osm2pgsql that will only import
> boundaries,
> leaving out roads, buildings etc., which will speed up the process a
> lot.
> 
> > 
> > However it seem that the random order of relation members causes
> > trouble generating a "simplified" (st_linemerge) linestring
> > suitable to
> > apply the st_makepolygon funktion to it.
> If you insist on continuing down your path, then st_polygonize would
> be
> the function to use (it does not depend on the ordering of segments),
> but osm2pgsl is really the better approach because it builds the
> polygons on a "topological" level (using OSM node IDs) instead of on
> the
> geometric level (looking only at coordinates).
> 
> Bye
> Frederik
> 

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

[OSM-talk] Standard map style contributions

[Daniel Koć]

Hi,

We have a lot of tickets waiting for solving in osm-carto (almost 400) 
and I'm interested how could we do it effectively.


It's not realistic to expect that the core team would be able to catch 
up and that's why we took some care to help other people to contribute. 
Most important thing was preparing the Docker environment, which makes 
installing and testing a lot easier, but there are also some documents 
explaining the inner working of the project and even some very easy 
tasks to pick:


https://github.com/gravitystorm/openstreetmap-carto/labels/good%20first%20issue

However after almost half a year we still don't have too many 
contributions from other people and I'm curious what are the main 
obstacles which prevent it and what else could we possibly change to 
make it easier? There's also more basic question: how many people are 
interested in contributing to osm-carto at all?



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [Talk-it] Trinceroni

[Damjan Gerl]

  
  
27.12.2017 - 20:53 - demon.box:


  Damjan Gerli wrote

  
Io userei
military=bunker  ( 
http://wiki.openstreetmap.org/wiki/Tag:military%3Dbunker )
per le parti costruite e/o scavate, usate come bunker. 

  
  
ciao Damjan in effetti era anche la mia idea iniziale ma poi mi sono
bloccato perchè la pagina wiki per military=bunker che anche tu mi citi,
dice che non è utilizzabile su una way ma solo su nodo oppure area ed allora
mi sono bloccato
che dici?
grazie
--enrico



Hai ragione, non avevo notato questo dettaglio. Allora basta
disegnare l'area, che è anche più sensato, almeno si capisce quanto
l'interno sia grande.

Damjan
  


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

Re: [OSM-talk] Generate polygons out of administrative Relations

[Frederik Ramm]

Hi,

On 28.12.2017 10:37, Nic wrote:
> I want to generate a polygon out of the different members/ways of an
> administrative relation (e.g. Bundesland).
> For that purpose I have loaded a pbf file via osmosis into a
> postgresql/postgis database.

That makes things unnecessarily difficult. Use osm2pgsql to load the
data instead, and the polygons will be built for you. You can even use a
so-called "style file" with osm2pgsql that will only import boundaries,
leaving out roads, buildings etc., which will speed up the process a lot.

> However it seem that the random order of relation members causes
> trouble generating a "simplified" (st_linemerge) linestring suitable to
> apply the st_makepolygon funktion to it.

If you insist on continuing down your path, then st_polygonize would be
the function to use (it does not depend on the ordering of segments),
but osm2pgsl is really the better approach because it builds the
polygons on a "topological" level (using OSM node IDs) instead of on the
geometric level (looking only at coordinates).

Bye
Frederik

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

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

[OSM-talk] Generate polygons out of administrative Relations

[Nic]

Hello list,

I want to generate a polygon out of the different members/ways of an
administrative relation (e.g. Bundesland).
For that purpose I have loaded a pbf file via osmosis into a
postgresql/postgis database.
However it seem that the random order of relation members causes
trouble generating a "simplified" (st_linemerge) linestring suitable to
apply the st_makepolygon funktion to it.
Any recommendation how to properly generated a polygon from the
relation members?

Thanks
Nic

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

Re: [Talk-it] MERGE-it: call for papers

[Roberto Brazzelli]

Grazie mille per i link.
In merito al riutilizzo di dati di osm e mappe collaborative
terrò aggiornata la mailing list con esempi vari quando saranno pronti.





Il giorno 22 dicembre 2017 19:45, Maurizio Napolitano 
ha scritto:

> > Mi interessava però sapere cose ne pensi nel dettaglio quando
> > scrivi.."potresti usare openstreetmap come fonte dati o - peggio - come
> > mappa di sfondo."
>
> spesso c'è chi fa soluzioni dicendo "Io uso openstreetmap" usando
> semplicemente le tile presenti su www.openstreetmap.org.
> Tile che hanno una loro policy di riuso
> https://operations.osmfoundation.org/policies/tiles/
> dove, di fatto, si dice di non esagerare.
>
> Sicuramente mostrare la mappa di OpenStreetMap è un passo avanti,
> anche se, di fatto, non si lavora sui dati (nel miglioramento o nel
> riuso).
> La mia è solo una posizione (forse estrema) legata al fatto di avere
> un po' di chiarezza di concetti e contribuire realmente al progetto.
>
> > Ti riferisci al fatto di utilizzare esclusivamente  un sw proprietario?
> o lo
> > estendi anche alla realizzazione di mappe web utilizzando sw open source?
>
> quello non cambia.
> Di mio preferisco che venga usato software libero, però, la licenza
> sui dati e i termini di riuso non mettono questo vincolo.
>
>
> > Nelle mie mappe web create con sw open source utilizzo a volte come
> render
> > di base i servizi offerti da mapbox..basati su osm, e considero positivo
> > il fatto che aggiornati vari di osm si vedano renderizzati sulla mia
> > mappa..anche se, piccolo problema, sembra che mapbox autdoor non si
> aggiorni
> > ai dati di osm con frequenza..ad oggi modifiche inserite in osm 3-4 mesi
> non
> > ci sono ancora.
>
> Il tuo è un esempio di riuso della mappa e non dei dati.
> Mapbox è uno dei provider di mappe che fa uso di parte dei dati di OSM.
> Poi è chiaro che dipende dal prodotto che vuoi mostrare: se si tratta
> di una mappa che mostra un determinato tipo di dato come sfondo,
> allora è importante anche ragionare sull'aggiornamento (la periodicità
> dipende da cosa si vuole mostrare)
>
> > Ne approfitto anche per chiedere consigli su metodi alternativi a mapbox
> per
> > creare sfondi personalizzati.
>
> puoi sempre tornare indietro e usare tilemill [1] (da cui è nato
> mapbox studio) o il fork tileoven [2] che usa nodejs 4 o anche
> kosmitk[3] o kartotherian di wikimedia [4] bene o male tutte soluzioni
> basate su mapnik [5]
> Di diverso puoi dare un occhio a maperitive [6] o tangram[7]
>
> puoi anche decidere di usare qgis o mapserver ecc...
> Sul wiki hai da perderti.
> Sono certo che arriveranno altri contributi su questo thread (e forse
> è meglio cambiare topic)
>
> [1] https://github.com/tilemill-project/tilemill
> [2] https://github.com/florianf/tileoven
> [3] https://github.com/kosmtik/kosmtik
> [4] https://github.com/kartotherian/kartotherian
> [5] http://mapnik.org/
> [6] http://maperitive.net/
> [7] https://mapzen.com/products/tangram/
>
> ___
> 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