Re: [Talk-us] User bumping all grade-separated intersections to motorway

[Joseph Barnes]

It’s bringing up nodes (when I delete the number after the 81); not sure where 
that’s coming from.

 

From: Martijn van Exel [mailto:m...@rtijn.org] 
Sent: Tuesday, June 14, 2016 9:06 AM
To: Joseph Barnes
Cc: Toby Murray; OSM Talk US
Subject: Re: [Talk-us] User bumping all grade-separated intersections to 
motorway

 

Does this help?

 

http://maproulette.org:8080/map/81/82653

 

Martijn

 

On Jun 14, 2016, at 7:50 AM, Joseph Barnes  wrote:

 

Just to make it easier for y’all, the offending changesets are from late 
January 2016 to mid-May 2016, and are mostly in the states of NE, KS, IA, and 
MO. My theory here was that there should be continuity between maps (i.e. Rand 
McNally shows the stretch of US 36 in Brown County, KS as freeway/motorway), 
and since this was already in place in Scottsbluff, NE, I decided to apply it 
everywhere (and got a little carried away in the process). I am trying to work 
on this when I have time, so if you have anything I need to cleanup, let me 
know (it’s my mess, I should fix it up).

 

From: Martijn van Exel [mailto:m...@rtijn.org] 
Sent: Tuesday, June 14, 2016 7:14 AM
To: Toby Murray
Cc: OSM Talk US
Subject: Re: [Talk-us] User bumping all grade-separated intersections to 
motorway

 

You could make a MapRoulette challenge out of it to have everyone help look 
things over.

Martijn

 

On Jun 13, 2016, at 6:17 PM, Toby Murray <  
toby.mur...@gmail.com> wrote:

 

Here is a link to the Overpass query (warning: a couple MB of JSON to render)
  http://overpass-turbo.eu/s/gMq

 

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

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

On Tue, Jun 14, 2016 at 8:24 PM, Kevin Kenny
 wrote:
> Now that I'm done with the NYC DEP Watershed Recreation Areas import,
> I've got some bandwidth to spend on this cleanup again.

I've added a sketch of the plan on the existing import page,
http://wiki.openstreetmap.org/wiki/NYS_DEC_Lands

Once again, the reimport will be only semi-automated, with new
multipolygons and tags being proposed over narrow geographic areas but
then stitched into the map manually. In no case do I wish to overwrite
any work that a mapper has done that still appears valid. I will be
discarding a fair number of armchair edits apparently conducted in
response to automated warnings about data quality, which really did
little to improve the situation.

The reimport, in addition to sorting out the tagging, will clear up a
great many awkward misalignments in places like
http://www.openstreetmap.org/relation/6304830#map=13/42.2111/-74.3611
- where the Balsam Mountain and Pine Island Mountain units are
correctly aligned, while the Hunter-West Kill Mountain Wilderness and
Rusk Mountain Wild Forest are not. There are currently gaffes like
that all over the Catskills. The root cause appears to be that some
program in the pipeline - perhaps in the import, perhaps at the DEC -
got the wrong conversions among the New York East state coordinate
plane (NAD27) on which the state Department of Transportation
projected its quadrangle maps, the Zone 18N UTM (NAD83) coordinates
that NYSGIS now prefers, and the WGS84 coordinates (either plate
carrée or spherical Mercator) that are used in OSM. Since the
projection errors are not consistent from parcel to parcel, I suspect
that the error was at the state's end. It appears to be corrected in
recent versions of the data set. (It also makes most of the property
lines contiguous with lines on the Greene County tax rolls, which are
also available on line, giving the possibility of an independent
cross-check of the data.)

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

Re: [Talk-us] [OSM-talk] Reporting Attribution Issues on Mapbox maps

[Serge Wroclawski]

On Tue, Jun 14, 2016 at 10:24 PM, Mikel Maron  wrote:

>
> > Webpages not hosted by Mapbox that are
> > using Mapbox tiles with
> > OSM-derived data would be responsible for
> > their own attribution, so
> > you'd need to contact them like with any other site.
>
> Actually, our support team will work to resolve attribution issues with
> maps using Mapbox tiles anywhere. Expect that this will resolve issues more
> expediently, since we likely have contact directly to responsible people
> for the site.
>
>
Glad to hear it.


> I believe Serge was wondering about attribution issues with sites using
> tiles or data not from Mapbox. That would include tiles from OSM.org.
>

I was specifically asked about a MapBox user who goes to MapBox, downloads
a map and then does not have proper attribution.

I'm glad to see that MapBox is pledging to handle these issues.

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

Re: [OSM-talk] [Talk-us] Reporting Attribution Issues on Mapbox maps

[Serge Wroclawski]

On Tue, Jun 14, 2016 at 10:24 PM, Mikel Maron  wrote:

>
> > Webpages not hosted by Mapbox that are
> > using Mapbox tiles with
> > OSM-derived data would be responsible for
> > their own attribution, so
> > you'd need to contact them like with any other site.
>
> Actually, our support team will work to resolve attribution issues with
> maps using Mapbox tiles anywhere. Expect that this will resolve issues more
> expediently, since we likely have contact directly to responsible people
> for the site.
>
>
Glad to hear it.


> I believe Serge was wondering about attribution issues with sites using
> tiles or data not from Mapbox. That would include tiles from OSM.org.
>

I was specifically asked about a MapBox user who goes to MapBox, downloads
a map and then does not have proper attribution.

I'm glad to see that MapBox is pledging to handle these issues.

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

Re: [Talk-us] [OSM-talk] Reporting Attribution Issues on Mapbox maps

[Mikel Maron]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important;  padding-left:1ex !important; background-color:white 
!important; } 
> Webpages not hosted by Mapbox that are > using Mapbox tiles with 
> OSM-derived data would be responsible for > their own attribution, so 
> you'd need to contact them like with any other site.
Actually, our support team will work to resolve attribution issues with maps 
using Mapbox tiles anywhere. Expect that this will resolve issues more 
expediently, since we likely have contact directly to responsible people for 
the site.
I believe Serge was wondering about attribution issues with sites using tiles 
or data not from Mapbox. That would include tiles from OSM.org. I don't have a 
solution, but would like to figure it out. I do believe that the more 
coordinated and respectful we make the process, the more likely issues will be 
resolved, and stronger relationships will develop with users of OSM data.

Mikel

On Tuesday, June 14, 2016, 4:49 PM, Paul Norman  wrote:

On 6/10/2016 3:03 PM, Serge Wroclawski wrote:
> But I'm a little concerned about non-MB hosted maps. If not this URL, 
> where can we report  attribution issues related to non-hosted Mapbox 
> maps and  can you link to that other place we can report attribution 
> issues related to that other kind of customer from the same web page?

Webpages not hosted by Mapbox that are using Mapbox tiles with 
OSM-derived data would be responsible for their own attribution, so 
you'd need to contact them like with any other site. If someone isn't 
comfortable doing this or not having success, they can forward the 
information to le...@osmfoundation.org and the LWG can look into the issue.

Also, if someone wants to contact Mapbox about an issue on mapbox.com 
and doesn't want to use the webform, they could use one of the contact 
methods for their designated agent for notifications of claimed 
infringement at http://www.copyright.gov/onlinesp/agents/m/map-box.pdf.

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

 

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

Re: [OSM-talk] [Talk-us] Reporting Attribution Issues on Mapbox maps

[Mikel Maron]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important;  padding-left:1ex !important; background-color:white 
!important; } 
> Webpages not hosted by Mapbox that are > using Mapbox tiles with 
> OSM-derived data would be responsible for > their own attribution, so 
> you'd need to contact them like with any other site.
Actually, our support team will work to resolve attribution issues with maps 
using Mapbox tiles anywhere. Expect that this will resolve issues more 
expediently, since we likely have contact directly to responsible people for 
the site.
I believe Serge was wondering about attribution issues with sites using tiles 
or data not from Mapbox. That would include tiles from OSM.org. I don't have a 
solution, but would like to figure it out. I do believe that the more 
coordinated and respectful we make the process, the more likely issues will be 
resolved, and stronger relationships will develop with users of OSM data.

Mikel

On Tuesday, June 14, 2016, 4:49 PM, Paul Norman  wrote:

On 6/10/2016 3:03 PM, Serge Wroclawski wrote:
> But I'm a little concerned about non-MB hosted maps. If not this URL, 
> where can we report  attribution issues related to non-hosted Mapbox 
> maps and  can you link to that other place we can report attribution 
> issues related to that other kind of customer from the same web page?

Webpages not hosted by Mapbox that are using Mapbox tiles with 
OSM-derived data would be responsible for their own attribution, so 
you'd need to contact them like with any other site. If someone isn't 
comfortable doing this or not having success, they can forward the 
information to le...@osmfoundation.org and the LWG can look into the issue.

Also, if someone wants to contact Mapbox about an issue on mapbox.com 
and doesn't want to use the webform, they could use one of the contact 
methods for their designated agent for notifications of claimed 
infringement at http://www.copyright.gov/onlinesp/agents/m/map-box.pdf.

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

 

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

Re: [Talk-br] name=Retorno

[thundercel]

Vou abrir um chamado no grupo do Mkgmap.

Quando eles alteraram a estrutura do renderizador distribuiram a alteração 
do style que começa assim:


# which may add info to a part of these highway=*_link roads:
# motorway_link, trunk_link, primary_link, secondary_link, tertiary_link

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 10:49 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 22:48 GMT-03:00 Nelson A. de Oliveira :

Estados Unidos tem 1257:
http://overpass-turbo.eu/s/gNE

Exemplo: http://overpass-turbo.eu/s/gNE


Errei no exemplo, mas só clicar em qualquer caminho do resultado que
dá pra ver as tags.

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



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

Re: [Talk-br] name=Retorno

[Nelson A. de Oliveira]

2016-06-14 22:48 GMT-03:00 Nelson A. de Oliveira :
> Estados Unidos tem 1257:
> http://overpass-turbo.eu/s/gNE
>
> Exemplo: http://overpass-turbo.eu/s/gNE

Errei no exemplo, mas só clicar em qualquer caminho do resultado que
dá pra ver as tags.

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

Re: [Talk-br] name=Retorno

[Nelson A. de Oliveira]

2016-06-14 22:21 GMT-03:00  :
> Omitiu o final dela que é: For details, see also the examples.
> Nos exemplos cita-se somente lanes e não a highway como um todo.

Exemplos não exaurem um assunto, mas mostram poucos casos para se ter uma ideia.

Só peguei de motorway até secondary, para ter uma noção (omitindo
tertiary, unclassified, residential, etc). Clica em "Run" se quiser
visualizar o resultado para cada consulta.

Alemanha tem 7278 rodovias com destination, que não são link:
http://overpass-turbo.eu/s/gNB

Um exemplo: https://www.openstreetmap.org/way/302705688


Inglaterra tem 122:
http://overpass-turbo.eu/s/gNC

Exemplo: https://www.openstreetmap.org/way/182323983


França tem 2376:
http://overpass-turbo.eu/s/gND

Exemplo: https://www.openstreetmap.org/way/108127607


Estados Unidos tem 1257:
http://overpass-turbo.eu/s/gNE

Exemplo: http://overpass-turbo.eu/s/gNE


Brasil tem 824:
http://overpass-turbo.eu/s/gNF

> Esse debate sobre destination ocorreu no ano passado, no grupo de
> desenvolvedores do Mkgmap. Por nossa solicitação eles fizeram com que também
> fossem reconhecidas as tags destination aplicadas em links primary,
> secundary e terciary, antes o Mkgmap só reconhecia até em links motorway e
> trunk.

Se não suporta então é bom verificar, porque é válido e utilizado.

> Tenho curisidade em saber se é somente o Mkgmap que tem essa restrição.
> Outro renderizador reconhece a tag destination aplicada na highway?

Do que eu sei e uso, o osmand suporta.

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

Re: [Talk-br] name=Retorno

[thundercel]

Não penso assim e também não interpreto assim.

na sua frase:

"Use destination=* together with highway=* on pieces of highway after
the position of the signpost or ground writing"

Omitiu o final dela que é: For details, see also the examples.
Nos exemplos cita-se somente lanes e não a highway como um todo.

Isso de se aplicar em somente lanes faz sentido para mim. A logica está em 
um condutor, que vai a um destino, se posicionar na faixa de pista que o 
conduzirá aquele destino. Dessa situação sai a função nos navegadores 
conhecida como "lane assistance".


Esse debate sobre destination ocorreu no ano passado, no grupo de 
desenvolvedores do Mkgmap. Por nossa solicitação eles fizeram com que também 
fossem reconhecidas as tags destination aplicadas em links primary, 
secundary e terciary, antes o Mkgmap só reconhecia até em links motorway e 
trunk.


Tenho curisidade em saber se é somente o Mkgmap que tem essa restrição. 
Outro renderizador reconhece a tag destination aplicada na highway?


-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:59 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 21:53 GMT-03:00  :

nos exemplos só é empregada em LANE de motorway e não na motorway.


É o mesmo caso, Marcio.
destination:lanes é só uma especialização de destination, da mesma
forma para destination:forward, destination:backward, etc

Mas de toda forma, não existe limitação por tipo:
https://wiki.openstreetmap.org/wiki/Key:destination#Where_to_use.3F

"Use destination=* together with highway=* on pieces of highway after
the position of the signpost or ground writing"

Qualquer highway serve.

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



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

Re: [Talk-br] name=Retorno

[Nelson A. de Oliveira]

destination:lanes é quando você quer marcar o destino individual de
cada faixa da rodovia (quando a faixa da esquerda vai pra cidade X e a
da direita pra Y)
destination quando você quer marcar o destino como um todo (qualquer
faixa vai levar ao mesmo local)

Mas o uso das tags é mesmo.

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

Re: [Talk-br] name=Retorno

[thundercel]

Complementando...

inclusive em https://wiki.openstreetmap.org/wiki/Lanes encontramos:

destination=* destination:lanes While the road specific key 
describes the direction of the highway by using the name of the city the 
highway is heading to, the destination:lanes allows tagging of cities when 
sign-posted for individual lanes. See destination=* for examples.


-Mensagem Original- 
From: thunder...@gpsinfo.com.br

Sent: Tuesday, June 14, 2016 9:53 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

Então,
nos exemplos só é empregada em LANE de motorway e não na motorway.

Observe nos dois ultimos exemplos o emprego: destination:lanes

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:45 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 21:42 GMT-03:00  :

Se aplicada em highway o Mkgmap não reconhece.


Mas aí é um problema/limitação do mkgmap.
No OSM pode-se utilizar destination em qualquer tipo de rua.

Pode ver inclusive nos exemplos
https://wiki.openstreetmap.org/wiki/Key:destination#Examples que tem
motorway_link e motorway apenas (sem ser _link).

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


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



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

Re: [Talk-br] name=Retorno

[Nelson A. de Oliveira]

2016-06-14 21:53 GMT-03:00  :
> nos exemplos só é empregada em LANE de motorway e não na motorway.

É o mesmo caso, Marcio.
destination:lanes é só uma especialização de destination, da mesma
forma para destination:forward, destination:backward, etc

Mas de toda forma, não existe limitação por tipo:
https://wiki.openstreetmap.org/wiki/Key:destination#Where_to_use.3F

"Use destination=* together with highway=* on pieces of highway after
the position of the signpost or ground writing"

Qualquer highway serve.

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

Re: [Talk-br] name=Retorno

[thundercel]

Então,
nos exemplos só é empregada em LANE de motorway e não na motorway.

Observe nos dois ultimos exemplos o emprego: destination:lanes

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:45 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 21:42 GMT-03:00  :

Se aplicada em highway o Mkgmap não reconhece.


Mas aí é um problema/limitação do mkgmap.
No OSM pode-se utilizar destination em qualquer tipo de rua.

Pode ver inclusive nos exemplos
https://wiki.openstreetmap.org/wiki/Key:destination#Examples que tem
motorway_link e motorway apenas (sem ser _link).

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



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

Re: [Talk-br] name=Retorno

[Nelson A. de Oliveira]

2016-06-14 21:42 GMT-03:00  :
> Se aplicada em highway o Mkgmap não reconhece.

Mas aí é um problema/limitação do mkgmap.
No OSM pode-se utilizar destination em qualquer tipo de rua.

Pode ver inclusive nos exemplos
https://wiki.openstreetmap.org/wiki/Key:destination#Examples que tem
motorway_link e motorway apenas (sem ser _link).

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

Re: [Talk-br] name=Retorno

[thundercel]

Nelson,
pelo que compreendi no grupo de desenvolvimento do Mkgmap ela só é suportada 
quando empregada em classe link_ e por isso que foi alterado o Mkgmap e o 
style para isso.


Em http://wiki.openstreetmap.org/wiki/Key:destination , nos exemplos podemos 
identificar que só é aplicada em links_  e também em lanes, pelo menos na 
Alemanha.


Se aplicada em highway o Mkgmap não reconhece.



-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:28 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 20:53 GMT-03:00  :

Lembro que essa tag destination só pode ser implantada em vias de classe
link_*


Não.
"destination" pode ser usado em qualquer tipo de via.

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



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

Re: [Talk-br] name=Retorno

[Nelson A. de Oliveira]

2016-06-14 20:53 GMT-03:00  :
> Lembro que essa tag destination só pode ser implantada em vias de classe
> link_*

Não.
"destination" pode ser usado em qualquer tipo de via.

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

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Now that I'm done with the NYC DEP Watershed Recreation Areas import,
I've got some bandwidth to spend on this cleanup again.

MECHANICAL EDITING

I've come to the conclusion that a 'mechanical edit' is appropriate
only in the sense that I will have a program providing me with
suggested geometry and tags. I'll need to go through all the edits
individually, because very few of the areas have actually survived
unchanged from the original import. Most of the changes appear to have
been from what Frederik Ramm referred to as 'drive-by mapping' -
armchair mappers silencing warnings from automated tools - but they
still need to be vetted individually. Moreover, there are various
weird tagging inconsistencies, such as conflicting tags between ways
in a relation, or between the ways and the relation itself.

PROTECTED_AREA

I'm going to maintain the protected_area tagging close to what I
specified below, except that 'Wild Forest,' 'Detached Parcel' and
'Unclassified' will all be upgraded to protect_class=1b. The only
significant differences between these and Wilderness is that slightly
more intensive use is allowed in Wild Forests. Nevertheless, it is
expected that those who enter the Wild Forests will have the skills
and equipment to operate on their own. About the only concessions that
they will find are hardened trail surfaces (NOT paved - but with more
erosion prevention than would be typical in Wilderness), the
occasional marked campsite (with no amenities other than brush
clearance and possibly a privy) and, in rare and exceptional cases,
permission to ride a mountain bike, horse, ATV or snowmobile.

LANDUSE (or leisure=nature_reserve, or landuse=forest, or
natural=wood, or landcover=trees, or what?)

I'm still in a quandary about how to tag the land use, because nothing
makes much sense.

leisure=nature_reserve at least renders, and is consistent with the
actual management - which ls largely, 'protect from encroachment, and
let Nature take her course.' The Wiki suggests that nature_reserve
ought to be used for relatively small areas and that
boundary=national_park might be more appropriate for these large ones.
Since the lands in question are located within the Adirondack and
Catskill parks (which exist as a public and private partnership), and
the outer boundaries of these immense parks are already tagged
'boundary=national_park', having something else designate the specific
land use seems appropriate, and nature_reserve seems as good as
anything, even if the High Peaks Wilderness is, at 832 square
kilometers, small in any sense other than relative to the Adirondack
Park's over 24,000 square kilometers. My inclination is to go with
this tag.

Most of the lands are at present tagged landuse=forest. This appears,
to me, to be incorrect. They are not managed for the production of
forest products. On the contrary, timber harvest is forbidden there in
perpetuity. The big advantage is that it renders with a pretty green
overlay, with trees.

natural=wood or landcover=trees are just plain wrong. There are woods,
fens and bogs, meadows, scrublands, and even some amount of
high-alpine tundra and bare rock. And I'm not about to tag what's
what. I get that information from the National Landcover Dataset when
I want to render a map.

landuse=conservation is formally deprecated.

I fall back on leisure=nature_reserve unless someone screams.

INFORMALITY

Since this is not a new import, and since all changes will be reviewed
(yes, I know it's a big job, but I can take it a few at a time in idle
moments and get it done in weeks to months), I don't plan to go
through an extensive formal review. I'll wikify what I'm doing and run
it by this list again before I start, but I consider this to be more
along the lines of manual editing to clean up a
less-than-ideally-executed import than of a massive mechanical edit to
conduct an import. I'l post again and allow a few days comment before
I start editing in earnest, again, just in case there are screams of
protest.


On Wed, May 25, 2016 at 2:04 PM, Kevin Kenny
 wrote:
> I've been continuing to investigate the NYS DEC Lands file, because,
> as Paul Norman identified, the original import is not up to current
> OSM standards. I'm not going to apologize for reimporting - a reimport
> will surely leave less of a mess than what is there!
>
> It's become clear to me that for most of these lands, and certainly
> for the entirety of the Forest Preserve, leisure=nature_reserve is a
> correct description for legacy renderers. landuse=forest is
> emphatically not correct. These lands are not used for timber
> production. natural=wood may or may not be correct, depending on
> landcover. boundary=national_park would also be semantically close for
> the Forest Preserve lands, except that the Forest Preserve is not
> administered at the national level.
>
> It would be desirable to include boundary=protected_area for these
> parcels, since all of them enjoy some 

Re: [Talk-us] highway=service + landuse=residential

[Steven Johnson]

More suited to planimetrics than transportation.

-- SEJ
-- twitter: @geomantic
-- skype: sejohnson8

A serious and good philosophical work could be written consisting entirely
of jokes. --*Ludwig Wittgenstein*

On Tue, Jun 14, 2016 at 7:20 PM, David Chiles  wrote:

> both the use of landuse=residential overall and highway=service for foot
> paths are a bit strange.
>
> On Tue, Jun 14, 2016 at 3:34 PM, Clifford Snow 
> wrote:
>
>> Interesting - mapping curb to curb. I doubt it could be used for routing
>> but it sure renders [1] nice.
>>
>>
>> [1]
>> http://www.openstreetmap.org/changeset/38868796#map=18/34.15966/-117.41187
>>
>> On Tue, Jun 14, 2016 at 2:21 PM, Martijn van Exel  wrote:
>>
>>> I don't think this is a great combination of tags?
>>>
>>> http://overpass-turbo.eu/s/gNy
>>>
>>> Ideas? Is this mapper on this list?
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>>
>>
>>
>> --
>> @osm_seattle
>> osm_seattle.snowandsnow.us
>> OpenStreetMap: Maps with a human touch
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-br] name=Retorno

[thundercel]

Roger,
como ja citado anteriormente o retorno não deve ser incluído no campo name.

Solicitamos que, na medida do possível, abra para a via de retorno a tag 
destination e nela inclua retorno


Essa ação facilitará os renderizadores que reconhecem a tag destination e 
utilizam o nela escrito para instrução em voz de manobra nos navegadores.


Lembro que essa tag destination só pode ser implantada em vias de classe 
link_*


[]s
Marcio

-Mensagem Original- 
From: Roger C. Soares

Sent: Tuesday, June 14, 2016 6:37 PM
To: OSM talk-br
Subject: [Talk-br] name=Retorno

Só para confirmar, no OSM agente não nomeia retornos, acessos, etc,
certo? Posso remover names do tipo:
http://www.openstreetmap.org/way/214229462

Outra dúvida, para que serve colocar addr:street com o mesmo valor da
tag name em highways? Por exemplo:
http://www.openstreetmap.org/way/171470967

Atenciosamente,
Roger.


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



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

Re: [Talk-us] highway=service + landuse=residential

[David Chiles]

both the use of landuse=residential overall and highway=service for foot
paths are a bit strange.

On Tue, Jun 14, 2016 at 3:34 PM, Clifford Snow 
wrote:

> Interesting - mapping curb to curb. I doubt it could be used for routing
> but it sure renders [1] nice.
>
>
> [1]
> http://www.openstreetmap.org/changeset/38868796#map=18/34.15966/-117.41187
>
> On Tue, Jun 14, 2016 at 2:21 PM, Martijn van Exel  wrote:
>
>> I don't think this is a great combination of tags?
>>
>> http://overpass-turbo.eu/s/gNy
>>
>> Ideas? Is this mapper on this list?
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] highway=service + landuse=residential

[Clifford Snow]

Interesting - mapping curb to curb. I doubt it could be used for routing
but it sure renders [1] nice.


[1]
http://www.openstreetmap.org/changeset/38868796#map=18/34.15966/-117.41187

On Tue, Jun 14, 2016 at 2:21 PM, Martijn van Exel  wrote:

> I don't think this is a great combination of tags?
>
> http://overpass-turbo.eu/s/gNy
>
> Ideas? Is this mapper on this list?
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>


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

Re: [Talk-br] name=Retorno

[Tarcisio Oliveira]

addr:* pode remover pois essas informações são retiradas das relações 
que eles fazem parte.



Em 14-06-2016 19:03, Roger C. Soares escreveu:

Em 14-06-2016 18:45, Nelson A. de Oliveira escreveu:

Pra nada (e também pode remover).
Pode ser que, por estar utilizando o iD e existir campos para serem
preenchidos, o usuário acabe preenchendo todos os itens, mesmo quando
não fazem sentido.
Tem esse ticket que abri
https://github.com/openstreetmap/iD/issues/2908 justamente para esse
problema.


Legal o ticket!

Os addr:city das highways então também é melhor remover ou deixar?

Atenciosamente,
Roger.


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



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

Re: [Talk-br] name=Retorno

[Roger C. Soares]

Em 14-06-2016 18:45, Nelson A. de Oliveira escreveu:

Pra nada (e também pode remover).
Pode ser que, por estar utilizando o iD e existir campos para serem
preenchidos, o usuário acabe preenchendo todos os itens, mesmo quando
não fazem sentido.
Tem esse ticket que abri
https://github.com/openstreetmap/iD/issues/2908 justamente para esse
problema.


Legal o ticket!

Os addr:city das highways então também é melhor remover ou deixar?

Atenciosamente,
Roger.


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

[Talk-de] FOSSGIS-Konferenz 2016 - Sessionleiter BITTE EINTRAGEN

[Michael Kugelmann]

Hallo,

selber Aufruf an die OSM'ler, welche auf der Konfernz sind.


Grüße,
Michael.

 Weitergeleitete Nachricht 
Betreff: 	[Konferenz] FOSSGIS-Konferenz 2016 - Sessionleiter BITTE 
EINTRAGEN

Datum:  Tue, 14 Jun 2016 14:52:16 +0200
Von:Katja Haferkorn 
An: Konferenz liste 



Hallo Zusammen,

die FOSSGIS-Vorbereitung läuft.
Wie in jedem Jahr brauchen wir in jedem Track eine Sessionleitung.
Zur Aufgabe des Sessionleiters/der Sessionleiterin gehören:
* Moderation Block/ Vorträge
* Moderation Diskussion
* Programmänderungen, wichtige Infos durchsagen

Bitte tragt Euch in die Wikitabelle ein. Das Argument, dass es sich vor
Ort schon finden wird, hat sich dahingehend nicht so bewährt, weil dann
kurz vor der Session jemand herumrennen muss, um einen Sessionleiter zu
organisieren. Ich schlage vor, dass wir uns das ersparen.

https://www.fossgis.de/wiki/Konferenz_2016/Videoaufzeichnung_Sessionleitung

Viele Grüße
Katja

--

FOSSGIS-Konferenz vom 04.-06. Juli 2016 im Vorfeld der AGIT an der Uni
Salzburg.



--

FOSSGIS 2016, Die Konferenz für Open Source GIS mit OpenData und
OpenStreetMap in Zusammenarbeit mit der AGIT 2016!
4.-6. Juli 2016 in Salzburg (3. Juli OpenStreetMap Workshoptag)
http://www.fossgis.de/konferenz/2016/

AGIT 2016 vom 6.-8. Juli 2016
http://agit.at/

FOSS4G 2016 Bonn - annual global event of the Open Source Geospatial
Foundation (OSGeo) - 24.-26. August 2016 in Bonn (zusätzlich noch
FOSS4G Hacking Event und Workshops)
http://2016.foss4g.org


FOSSGIS e.V, der Verein zur Förderung von Freier Software aus dem
GIS-Bereich und Freier Geodaten!
http://www.fossgis.de/ https://twitter.com/fossgis_eV


Konferenz-Liste mailing list
konferenz-li...@fossgis.de
https://lists.fossgis.de/mailman/listinfo/konferenz-liste


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

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[Sylvain Maillard]

Les bases spatialite ça marche bien pour de la carto, j'utilise ça pour
plusieurs projets au boulot !

Il faut surtout éviter de créer de trop grosses bases, au delà de 2Go il y
a une perte de performance ...


Sylvain

Le 14 juin 2016 à 16:35, Tony Emery  a écrit :

> Du coup, quand on créé une requête overpass pour récupérer les données dans
> un fichier xml (par défaut), est-ce qu'on peut paramétrer la requête pour
> qu'elle ne télécharge que la différence entre la base osm et ce qui est
> dans
> le fichier xml ?
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Import-de-donnees-OSM-dans-PostGIS-tp5875478p5875492.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-br] name=Retorno

[Gerald Weber]

Oi Roger

no primeiro caso eu movo o name para a tag description
description=retorno

senão arrisca depois vir alguém e colocar de volta name=retorno

sobre a sua segunda pergunta, a tag addr:street me parece incorreta mesmo.

abraço

Gerald



On 14 June 2016 at 18:37, Roger C. Soares  wrote:

> Só para confirmar, no OSM agente não nomeia retornos, acessos, etc, certo?
> Posso remover names do tipo:
> http://www.openstreetmap.org/way/214229462
>
> Outra dúvida, para que serve colocar addr:street com o mesmo valor da tag
> name em highways? Por exemplo:
> http://www.openstreetmap.org/way/171470967
>
> Atenciosamente,
> Roger.
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] name=Retorno

[Nelson A. de Oliveira]

On Tue, Jun 14, 2016 at 6:37 PM, Roger C. Soares  wrote:
> Só para confirmar, no OSM agente não nomeia retornos, acessos, etc, certo?

Se tiver uma placa dizendo "Retorno" pode deixar com
"destination=Retorno", mas no nome não.
Nome genérico ou descritivo, pra qualquer que seja o tipo de objeto,
não se deve utilizar.

> Outra dúvida, para que serve colocar addr:street com o mesmo valor da tag

Pra nada (e também pode remover).
Pode ser que, por estar utilizando o iD e existir campos para serem
preenchidos, o usuário acabe preenchendo todos os itens, mesmo quando
não fazem sentido.
Tem esse ticket que abri
https://github.com/openstreetmap/iD/issues/2908 justamente para esse
problema.

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

Re: [Talk-at] Wichtige Frage - Haben Drachenaugen-Plätze einen Platz auf OSM?

[gppes_osm]

Obwohl es eine sehr zwiespaeltige Angelegenheit ist, leuchtet mir das jetzt ein.

Ich will die Originalposter jetzt aber nicht zur Illegalitaet animieren! ;-)

-Ursprüngliche Nachricht-
Gesendet: Tuesday, 14 June 2016 um 23:21:55 Uhr
Von: "Stefan Kopetzky" 
An: talk-at@openstreetmap.org
Betreff: Re: [Talk-at] Wichtige Frage - Haben Drachenaugen-Plätze einen Platz 
auf OSM?
On 2016-06-14 23:07, gppes_...@web.de wrote:
> oder nicht legal existieren

Das ist doch eher ein Schmonzes...
Wenn da ein Haus steht, wirds gemappt. Unabhänging davon ob es etwa der
Bauordnung widerspricht. Selbiges gilt für nahezu alle anderen Objekte.
Wenn du dein Schild auf die fremde Wiese stellst und der Eigentümer
lässt es dort stehen, wird auch das Schild gemappt. Wenn der Eigentümer
es sehr lange stehen lässt, heisst wahrscheinlich die Wiese irgendwann
auch so...

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

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

Re: [Talk-at] Wichtige Frage - Haben Drachenaugen-Plätze einen Platz auf OSM?

[eest9]

Am 14. Juni 2016 um 23:21 schrieb Stefan Kopetzky :
> On 2016-06-14 23:07, gppes_...@web.de wrote:
>> oder nicht legal existieren
>
> Das ist doch eher ein Schmonzes...
> Wenn da ein Haus steht, wirds gemappt. Unabhänging davon ob es etwa der
> Bauordnung widerspricht. Selbiges gilt für nahezu alle anderen Objekte.
> Wenn du dein Schild auf die fremde Wiese stellst und der Eigentümer
> lässt es dort stehen, wird auch das Schild gemappt. Wenn der Eigentümer
> es sehr lange stehen lässt, heisst wahrscheinlich die Wiese irgendwann
> auch so...


Seh ich auch so, ansonsten würde die OSM bei einigen Wegen 30 Jahre
hinterherhinken, denn so lange dauert es bis ein Trampelpfad das
Wegerecht erhält.

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

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

[Talk-us] highway=service + landuse=residential

[Martijn van Exel]

I don't think this is a great combination of tags?

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

Ideas? Is this mapper on this list?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Avis de thèse à l'IGN

[Emilie Laffray]

Peut etre que c'est mon ticket pour rentrer en France :p

2016-06-14 8:14 GMT-07:00 Frédéric Rodrigo :

> Le 14/06/2016 à 15:24, Nicolas Moyroud a écrit :
>
>> Même réflexion en lisant le titre. Certians diront peut-être que j'ai
>> l'esprit mal placé mais en lisant  le résumé voici ce que j'entend à
>> demi-mot : comment nous le grand IGN pouvons-nous aider ces pauvres diables
>> qui se démènent avec un système collaboratif (donc défectueux par nature) à
>> faire des choses aussi bonnes que les notres ? Quand je vois certains des
>> trucs qu'il propose dans le sujet, je ne sais pas si ils croient innover,
>> mais moi la plupart du temps j'ai juste l'impression qu'ils parlent
>> d'osmose... Fred devrait postuler il a déjà presque fait les 3 ans de
>> travail ;-)
>>
>> Ça a été posté aujourd'hui sur georezo avec une date limite de
> candidature au 12 juin... les candidats n'ont pas du se bousculer, j'ai
> encore toutes mes chances ;-), et puis ça fait 6 ans que je bosse sur
> Osmose !
>
> Frédéric, Dr. ès QA.
>
>
>
> ___
> 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] [Talk-us] Reporting Attribution Issues on Mapbox maps

[Paul Norman]

On 6/10/2016 3:03 PM, Serge Wroclawski wrote:
But I'm a little concerned about non-MB hosted maps. If not this URL, 
where can we report  attribution issues related to non-hosted Mapbox 
maps and  can you link to that other place we can report attribution 
issues related to that other kind of customer from the same web page?


Webpages not hosted by Mapbox that are using Mapbox tiles with 
OSM-derived data would be responsible for their own attribution, so 
you'd need to contact them like with any other site. If someone isn't 
comfortable doing this or not having success, they can forward the 
information to le...@osmfoundation.org and the LWG can look into the issue.


Also, if someone wants to contact Mapbox about an issue on mapbox.com 
and doesn't want to use the webform, they could use one of the contact 
methods for their designated agent for notifications of claimed 
infringement at http://www.copyright.gov/onlinesp/agents/m/map-box.pdf.


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

Re: [Talk-cz] Mapa na mapio.net nemá attribution

[Miroslav Suchý]

Dne 14.6.2016 v 19:24 Marián Kyral napsal(a):

Ahoj,
objevilo se na fóru: http://forum.openstreetmap.org/viewtopic.php?id=54896

Ujme se toho někdo? Já na to moc nejsem.


Ja jim napisu. Akorat na to forum nemuzu odpovedet nebo tam neprijimaji 
nove registrace.


Mirek



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

Re: [Talk-us] [OSM-talk] Reporting Attribution Issues on Mapbox maps

[Paul Norman]

On 6/10/2016 3:03 PM, Serge Wroclawski wrote:
But I'm a little concerned about non-MB hosted maps. If not this URL, 
where can we report  attribution issues related to non-hosted Mapbox 
maps and  can you link to that other place we can report attribution 
issues related to that other kind of customer from the same web page?


Webpages not hosted by Mapbox that are using Mapbox tiles with 
OSM-derived data would be responsible for their own attribution, so 
you'd need to contact them like with any other site. If someone isn't 
comfortable doing this or not having success, they can forward the 
information to le...@osmfoundation.org and the LWG can look into the issue.


Also, if someone wants to contact Mapbox about an issue on mapbox.com 
and doesn't want to use the webform, they could use one of the contact 
methods for their designated agent for notifications of claimed 
infringement at http://www.copyright.gov/onlinesp/agents/m/map-box.pdf.


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

Re: [Talk-it] Cancellazioni sospette nuovo utente

[Federico Cortese]

Ok ho controllato gli altri changeset, ma non c'erano grossi problemi,
aveva cancellato dei landuse=brownfield che ho recuperato con
undelete, tutto il resto erano poligoni e strade che aveva disegnato
lui stesso e poi cancellato.
Ciao

Federico

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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Tony Emery]

verdy_p wrote
> L'ennui c'est que les adresses ne se limitent pas seulemetn à un
> housenumber (notion liée à la propriété cadastrale, formée sur une ou
> plusieurs parcelles). 

Le tag "housenumber" porte sur le numéro de l'adresse. Dans ce cas, cette
information n'est absolument pas liée à la propriété cadastrale car je peux
te donner des milliers d'exemples en France où l'adresse cadastrale ne
contient pas de numéro.


verdy_p wrote
> Elle est même insuffisante puisqu'à cette notion de propriété vient se
> greffer celle de résidents/locataires (qui ont aussi une existence
> fiscale, mais non cadastrale) : ils ont aussi leurs adresses toutes aussi
> importantes, et quand le housenumber ne suffit plus, on doit rentrer dans
> plus de détails : numéo ou nom de bâtiment, étage, numéro de porte... (des
> propriétés aussi importantes du schéma addr:*).

Là encore, ce n'est pas juste, mais je ne détaille pas car j'en aurais pour
la semaine à expliquer les différences.


verdy_p wrote
> Je crois qu'ici on est trop obnubilé par vouloir une base BANO "propre" ne
> tenant qu'à établir une liste des propriétés et ignorer totalement ceux
> qui les occupent (résidents/locataires).
> 
> A vouloir utiliser contact:* pour lever les ambiguités, on a détourné la
> finalité de contact:* et crée de nouvelles ambiguités (ou impossibilités
> de codification).

Au contraire, utiliser contact:* permet d'utiliser, pour les commerces et
autres activités, des adresses qui peuvent être postale et, donc, pas du
tout des adresses physiques.


verdy_p wrote
> Si vous voulez absolument un housenumber unique pour faire plaisir à BANO
> (j'appelle ça taguer pour le rendu, ici les rendus et analyses BANO  !) je
> ne vois pas comment procéder autrement que de créer des relations
> associatedHousenumber pour pouvoir y rattacher les *différents* objets
> distincts qui y sont rattachés (les résidents/locataires, et dans le cas
> présent les commerces).

Encore une fois, au contraire, je prône plutôt pour doubler les numéros
d'adresses identiques dans certains cas à définir.

Reste à définir comment qualifier les noms/numéros de bâtiments ou des
entrées dans les résidences collectives.
De même pour les numéros de lot dans certains lotissement qui ne sont pas
forcément de numéros d'adresse de voie mais pour lesquels on n'a rien
d'autre pour distinguer chaque logement ou maison.

C'est d'ailleurs le sujet en plein de mon message "Adresses, lotissements et
résidences"



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875508.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-it] Cancellazioni sospette nuovo utente

[Federico Cortese]

2016-06-14 21:03 GMT+02:00 John Doe :
> L'utente ha confermato di aver sbagliato nei commenti.
> Qualcuno potrebbe occuparsi del revert del changeset?
> Ho visto che l'utente ha già diversi changesets se qualcuno volesse fare un
> ulteriore controllo.
>

Ho fatto il revert e tolto alcuni tag ridondanti (tipo gli area=yes).
Purtroppo però ora non riesco a controllare gli altri changeset.
Ciao
Federico

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

[Talk-it] Cancellazioni sospette nuovo utente

[John Doe]

L'utente ha confermato di aver sbagliato nei commenti.
Qualcuno potrebbe occuparsi del revert del changeset?
Ho visto che l'utente ha già diversi changesets se qualcuno volesse fare un
ulteriore controllo.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Mapping Party Esino Lario

[Dario Crespi]

No, magari una visita al museo a Mandelli è poi a mappare nei paesini più
nord, tipo Bella o quelli ancora più su.

Dario
Il 14/giu/2016 20:43, "Andrea Lattmann"  ha
scritto:

> >Dario pensava ad un MP a Mandello del Lario con visita al Museo Guzzi.
>
> Be, Mandello del Lario non è una zona bisognosa, esistono altre realtà
> dove c' è il nulla. Il buon RColombo a Mandello ha lavorato moltissimo...
>
> Andrea Lattmann
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Mapping Party Esino Lario

[Andrea Lattmann]

>Dario pensava ad un MP a Mandello del Lario con visita al Museo Guzzi. 

Be, Mandello del Lario non è una zona bisognosa, esistono altre realtà dove c' 
è il nulla. Il buon RColombo a Mandello ha lavorato moltissimo...

Andrea Lattmann

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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

Le 14 juin 2016 à 19:01, Christian Rogel 
a écrit :

> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
>
> Bonjour,
>
> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>
>
>> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
>> des noeuds différents, proches mais taguant des objets différents ayant
>> *certaines* propriétés communes (dont le numéro de rue associé).
>>
>
> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de ne
> décrire un objet qu'une fois, et c'est une règle générale pas spécifique
> aux adresses.*"
>
>
>> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
>> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
>> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
>> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
>> que les deux autres, il n'ajoute rien de mieux.
>>
>
> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
> justement l'adresse en question. Partant du constat qu'on ne décrit un
> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
> sens.
>
>
> Malgré l’accord entre vous, je suis convaincu que vous mélangez deux
> objets différents qui ne font jamais des doublons, principalement parce que
> cela vous irrite l’œil de voir côte à côte deux nombres (esprit geek ?).
> En réalité, la création de chaque objet relève d’une logique différente
> qui doit empêcher d’appliquer la règle «  one feature, one tag ».
> Vouloir fusionner les expressions apparemment identiques de deux objets
> est, commme je l’ai dit, une variété de taggage pour le rendu.
>

Le fait est que l'adresse où Romain l'entends est réduite à sa seule
définition communale/cadastrale, du point de vue de son unique propriétaire
(une personne ou une communauté de personnes dans le cas d'une
copropriété). le schéma addr:* n'est pas réduit à seulement cela. Vouloir
éliminer les résidents/locataires est quelquechose que même
l'administration fiscale ne fait pas. Sinon il n'y aurait que les taxes
foncières, pas les taxes locatives et autres taxes communales à la charge
non du propriétaire mais du/des résident(s).

Et ce n'est d'ailleurs pas spécifiquement français, partout dans le monde
il y a des adresses partagées *en partie* par leurs occupants: si on place
le curseur de l'unicité sur le seul numéro dans une rue on oublie
totalement les résidents et dans ce cas on peut oublier une bonne partie du
schéma addr:*

De plus la pseudo-solution qui consiste à surcharger "contact:housebumber"
n'a jamais été documentée ou approuvée. On la découvre par hasard mais
c'est undétournement de la fonction qui crée une nouvelle ambiguïté. le
schéma contact:* a justement été fait pour mentionner des infos qui ne sont
pas directement liées à la position géographique de l'objet qui est annoté
de cette façon: les numéros de téléphones sont portables, comme les email,
comme les adresses de facturation; dans le commerce et les entrerprises en
général il est extrèmement courant qu'un établissement ne soit pas
contactable sur place mais dans un autre établissement, voire même dans une
autre société, même pas nécessairement dans le même pays.

Il faut revenir au schéma addr:* tel qu'il est standardisé. Si le doublon
de valeurs vous choque à cause de BANO créez un objet ad hoc pour les
housenumber, tout en étant conscient que les adresses BANO de cette façon
ne peuvent représenter de façon correcte les adresses exactes des occupants.

Ces adresses sont insuffisantes, il manque des détails: batiment, escalier
,étage, porte, nom de l'occupant réel, et la géométrie du noeud est tout
aussi insuffisante, quelle que soit la précision de placement de ce noeud
totalement virtuel qui ne correspond en rien à ce que connait le cadastre
ou la commune, sa position étant en fait dans OSM étant en fait totalement
arbitraire: l'adresse réelle c'est une surface délimitée (pas un noeud dans
cette surface et encore moins en bordure ce cette surface sur une ligne
mitoyenne avec la voirie publique, une ligne qui n'est en fait même pas
tracée dans OSM puisqu'on n'a pas inclus le découpage parcellaire, et
qu'une adresse se compose souvent de plusieurs parcelles réunies pour des
raisons historiques !)

Ajoutez à ça que la numérotation des rues peut avoir des trous très
irréguliers (notammeent dans les communes à numérotation métrique), on voit
bien qu'on ne peut rien déduire de l'adresse d'un occupant en cherchant un
noeud d'adresse proche: on a toutes les chances de se planter de numéro !
Admettons que ce numéro serve au repérage, c'est alors juste une
alternative aux coordonnées géographiques mais ça n'indique rien de précis
autour. On n'a rien pour réunir des objets proches et aucun critère fiable
pour déterminer le numéro si ce numéro n'est pas 

[Talk-cz] Mapa na mapio.net nemá attribution

[Marián Kyral]

Ahoj,
objevilo se na fóru: http://forum.openstreetmap.org/viewtopic.php?id=54896

Ujme se toho někdo? Já na to moc nejsem.

Marián



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

[Talk-br] Ajuda para Mover o Mapa?

[raphaelmirc .]

Boa Tarde,

 Gostaria de saber como faço para mover o mapa para ficar no centro das
ruas, o mapa está de forma errada no lugar errado, fica ao lado das ruas, o
bairro e a Cohab, em Recife.

  Gostaria de saber como faço para concertar, já que estou editando e
incluindo as ruas e os nomes.

 Aguardo Ajuda!!!


-- 

Att;
Um Forte Abraço,


*Raphael de Assis*
Recife/PE
raphaelm...@gmail.com
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Christian Rogel]

> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
> 
> Bonjour,
> 
> Le 13 juin 2016 à 20:19, Philippe Verdy  > a écrit :
>  
> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont des 
> noeuds différents, proches mais taguant des objets différents ayant 
> *certaines* propriétés communes (dont le numéro de rue associé).
> 
> Je suis de l'avis de l'autre Christian soit "Le principe d'OSM est de ne 
> décrire un objet qu'une fois, et c'est une règle générale pas spécifique aux 
> adresses."
>  
> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide de 
> tags et PAS les deux deux des POIs distincts des deux commerces qui sont au 
> 40: en effet ce noeud vierge a toutes ses propriétés communes avec les deux 
> autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité que les 
> deux autres, il n'ajoute rien de mieux.
> 
> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier justement 
> l'adresse en question. Partant du constat qu'on ne décrit un objet qu'une 
> seule fois, si tu supprimes ce nœud, il te faudrait choisir entre les deux 
> POI pour y associer l'adresse... or cela n'a pas plus de sens.

Malgré l’accord entre vous, je suis convaincu que vous mélangez deux objets 
différents qui ne font jamais des doublons, principalement parce que cela vous 
irrite l’œil de voir côte à côte deux nombres (esprit geek ?).
En réalité, la création de chaque objet relève d’une logique différente qui 
doit empêcher d’appliquer la règle «  one feature, one tag ».
Vouloir fusionner les expressions apparemment identiques de deux objets est, 
commme je l’ai dit, une variété de taggage pour le rendu.

L’adresse est attribuée par la commune à une parcelle de terrain, uniquement 
celle-ci supporte un immeuble taxable (hors immeubles non clos ou légers, comme 
les abris de jardin, taxables forfaitairement).
J’insiste sur le fait qu’il s’agit de l’immeuble et de la parcelle.Les données 
sur la nouvelle construction sont transmises au cadastre (impôts) qui utilise 
le numéro de parcelle et l’adresse, si la commune a numéroté la rue.

Dans le cas du quartier commerçant de Dinan, certains usagers d’une fraction de 
l’immeuble utilisent légitimemen un bien commun à tous les occupants, 
l’adresse, pour fournir un repère géospatial à leurs éventuels clients.
C’est donc favoriser la privatisation d’un bien commun que d’effacer l’adresse 
qui préexistait pour donner le pas pour des raisons esthétiques et moins 
logiques qu’il n’y paraît.

C’est d’alleurs moi qui l’année dernière avait mis ces adresses et, finalement, 
je trouve cavalier qu’un point de vue fondé aussi légèrement aboutisse à une 
sorte de vandalisme.


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

Re: [Talk-at] Wichtige Frage - Haben Drachenaugen-Plätze einen Platz auf OSM?

[eest9]

Ich kann mich dieser Ansicht in dieser Form anschließen und möchte
dich auch für deine Akzeptanz loben. (War über die ersten Mails
schockiert; kenn solche Aussagen eher von anderen (Streit-)Vereinen.)

lg eest9

Am 14. Juni 2016 um 16:26 schrieb Christian Aigner :
> Als ich damals den Drachenaugenplatz auf dem Schafberg auf der OSM
> entdeckt habe, dachte ich mir "WTF ist das?". Also habe ich den
> Fehler-Report eröffnet. Ich wollte mehr darüber wissen, bevor ich etwas
> verändere oder gar lösche.
>
> Als ich dann erfahren habe, was es damit auf sich hat, war ich zuerst
> der Meinung, so etwas hat auf der OSM nichts verloren. Aber ich wollte
> noch ein bißchen abwarten und überlegen.
>
> Heute, nach reiflicher Überlegung und abwägen, bin ich zu folgender
> Einsicht gekommen:
>
> 1) Wenn religöse Plätze (z.B. Marterl am Wegesrand) auf der OSM
> verzeichnet sind, so können auch esoterische Plätze eingezeichnet
> werden. Niemand hat ein An- oder Vorrecht auf die eine und wahre
> Weltanschauung.
>
> 2) Wenn es sich bei einem Drachenaugenplatz um etwas permanentes
> handelt, und wenn dort vor Ort auch etwas zusehen ist, dann darf es auch
> auf der OSM verzeichnet sein.
>
> 3) Wenn Denkmäler und Statuen auf der OSM verzeichnet sind, dann dürfen
> auch neue künstlerische Projekte darauf verzeichnet werden, sofern denn
> vor Ort etwas Physisches vorhanden ist. Es reicht nicht, daß es ein
> Kraftplatz ist, es muß für jeden auch als solcher unabhängig, ob man
> daran glaubt, oder nicht, ersichtlich sein.
>
> Auch wenn ich als Techniker und naturwissenschaftlich orientierter
> Mensch von Esoterik nichts halte, so muß ich dennoch akzeptieren, daß es
> Menschen gibt, die daran glauben und die die OSM genauso wie ich
> benutzen wollen, um sich zu orientieren.
>
> Ich bin ja auch Atheist und akzeptiere, daß es Menschen gibt, die
> tatsächlich an eine oder mehrere Gottheit/en glauben. Und ich habe auch
> schon Kirchen, Kapellen, Marterl und Waldandachten auf der OSM
> eingetragen. Da war vor Ort oft nicht mehr als nur ein Heiligenbild auf
> einem Baum mitten im Wald angebracht.
>
> Also: Was soll's?! Von mir aus sollen auch Drachenaugenplätze auf der
> OSM sein.
>
> Aber: Wenn ich mal dort vorbei komme, und da ist nichts, dann werde ich
> wieder einen OSM-Bugreport eröffnen.
>
> In diesem Sinne: Liebe Grüße, und möge heute Abend das bessere Team
> gewinnen. ;-)
>
> Christian
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [OSM-talk-fr] Avis de thèse à l'IGN

[Frédéric Rodrigo]

Le 14/06/2016 à 15:24, Nicolas Moyroud a écrit :
Même réflexion en lisant le titre. Certians diront peut-être que j'ai 
l'esprit mal placé mais en lisant  le résumé voici ce que j'entend à 
demi-mot : comment nous le grand IGN pouvons-nous aider ces pauvres 
diables qui se démènent avec un système collaboratif (donc défectueux 
par nature) à faire des choses aussi bonnes que les notres ? Quand je 
vois certains des trucs qu'il propose dans le sujet, je ne sais pas si 
ils croient innover, mais moi la plupart du temps j'ai juste 
l'impression qu'ils parlent d'osmose... Fred devrait postuler il a 
déjà presque fait les 3 ans de travail ;-)


Ça a été posté aujourd'hui sur georezo avec une date limite de 
candidature au 12 juin... les candidats n'ont pas du se bousculer, j'ai 
encore toutes mes chances ;-), et puis ça fait 6 ans que je bosse sur 
Osmose !


Frédéric, Dr. ès QA.


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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

L'ennui c'est que les adresses ne se limitent pas seulemetn à un
housenumber (notion liée à la propriété cadastrale, formée sur une ou
plusieurs parcelles). Elle est même insuffisante puisqu'à cette notion de
propriété vient se greffer celle de résidents/locataires (qui ont aussi une
existence fiscale, mais non cadastrale) : ils ont aussi leurs adresses
toutes aussi importantes, et quand le housenumber ne suffit plus, on doit
rentrer dans plus de détails : numéo ou nom de bâtiment, étage, numéro de
porte... (des propriétés aussi importantes du schéma addr:*).

Je crois qu'ici on est trop obnubilé par vouloir une base BANO "propre" ne
tenant qu'à établir une liste des propriétés et ignorer totalement ceux qui
les occupent (résidents/locataires).

A vouloir utiliser contact:* pour lever les ambiguités, on a détourné la
finalité de contact:* et crée de nouvelles ambiguités (ou impossibilités de
codification).

Si vous voulez absolument un housenumber unique pour faire plaisir à BANO
(j'appelle ça taguer pour le rendu, ici les rendus et analyses BANO  !) je
ne vois pas comment procéder autrement que de créer des relations
associatedHousenumber pour pouvoir y rattacher les *différents* objets
distincts qui y sont rattachés (les résidents/locataires, et dans le cas
présent les commerces).

Faut de quoi (sans relation), renseigner addr:housenumber est parfairtement
propre (et tant pis si l'analyse BANO "gueule" sur de speudo-doublons:
c'est l'analyse BANO qu'il faudra corriger si elle ne sait pas tenir compte
de la réalité.

En attendant, un simple noeud pour BANO ne décrit pas correctement
l'adresse puisqu'il n'a aucune géométrie suffisante, il a une surface nulle
et le reste n'est qu'une approximation (il n'y a rien de solide pour
rattacher ce qui voisine ce noeud à la même adresse, et on le voit bien
ici: un numéro 40 sera en fait placé à mi-chemin entre le noeud 40 et le
noeud 44, et ce n'est pourtant pas le 42 !  On a le même problème aux
angles de rues. On a aussi le problème pour rattacher une même résidence à
plusieurs numéros d'adresse (parfois sur deux rues différentes).

Bref c'est bancale, et je suis contre le fait de surcharger contact:* pour
tenter maladroitement de contourner le problème des analyses BANO. Le but
n'est pas pour nous de dégommer systématiquement tous les signalements BANO
en faisant de façon aussi "dégueu" (et aussi insuffisante, peu précise et
toujours aussi ambiguë au final).




Le 14 juin 2016 à 16:52, Tony Emery  a écrit :

> Si on part du principe d'écarter la notion d'adresse postale (on laisse ça
> à
> La Poste), il faut définir les enjeux de l'adresse physique pour savoir
> comment on la décrit.
>
> On a dit que, pour les adresses des commerces, on utilise les tags
> contact:xxx. Quant à la description des plaques des noms des rues et des
> numéros d'adresse mais, en soit, cela n'a pas beaucoup d'utilité.
>
> Par contre, la notion d'adresse physique pour la navigation routière, le
> déplacement des services d'urgence, le dénombrement des logements,...
>
> De fait, si une adresse dessert plusieurs bâtiments physiquement séparés,
> cela ne me semble pas incohérent d'attribuer à chaque bâtiment  (Exemple)
>   .
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875494.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-br] Avenida Rio Branco, Rio de Janeiro

[Arlindo Pereira]

Feito: http://www.openstreetmap.org/changeset/40019416

[]s

2016-06-14 8:48 GMT-03:00 Erick de Oliveira Leal <
erickdeoliveiral...@gmail.com>:

> Opa, já que esteve lá corrige para nós Arlindo, ela está definida como
> somente para pedestres.
>
> Em 14 de junho de 2016 08:38, Arlindo Pereira <
> arli...@openstreetmap.com.br> escreveu:
>
>> Retomando, aqui está o trecho no Mapillary:
>> https://www.mapillary.com/map/im/_cUGEo5IXul0Khgm7RPRjA/photo
>>
>> É possível ver que este quarteirão tem circulação de veículos.
>>
>> []s
>>
>> 2016-06-12 20:54 GMT-03:00 Arlindo Pereira 
>> :
>>
>>> Opa, respondi sem olhar o ponto. Sim, entre a Rua do Passeio e a Mestre
>>> Valentim está liberado para veículos sim. O boulevard vai só até a
>>> Cinelândia mesmo.
>>>
>>> Mais tarde edito e corrijo (se ninguém o fizer primeiro).
>>>
>>> 2016-06-12 20:53 GMT-03:00 Arlindo Pereira >> >:
>>>
 Exatamente. Coincidentemente passei por lá hoje e registrei fotos para
 o Mapillary nos dois sentidos. Quando terminar de subir e processar mando o
 link.

 []s

 On Sun, Jun 12, 2016 at 12:03 PM, Paulo Carvalho <
 paulo.r.m.carva...@gmail.com> wrote:

> Entre esse ponto e o aterro não passa mais carros.  Se o waze indica
> outra coisa, está errado.
>
> Em 12 de junho de 2016 11:16, Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com> escreveu:
>
>> No waze mostra que a partir deste ponto eh pra veículos.
>> Em 12 de jun de 2016 10:53 AM, "Paulo Carvalho" <
>> paulo.r.m.carva...@gmail.com> escreveu:
>>
>>> Não.  A partir daí só passam o VLT, ciclistas e pedestres.
>>>
>>> Em 12 de junho de 2016 09:37, Erick de Oliveira Leal <
>>> erickdeoliveiral...@gmail.com> escreveu:
>>>
 Amigos do Rio, a Avenida Rio Branco a partir do ponto
 http://www.openstreetmap.org/node/1981177106 é permitida para
 carros, não?

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


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

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

Re: [Talk-us] User bumping all grade-separated intersections to motorway

[Martijn van Exel]

Does this help?

http://maproulette.org:8080/map/81/82653 


Martijn

> On Jun 14, 2016, at 7:50 AM, Joseph Barnes  wrote:
> 
> Just to make it easier for y’all, the offending changesets are from late 
> January 2016 to mid-May 2016, and are mostly in the states of NE, KS, IA, and 
> MO. My theory here was that there should be continuity between maps (i.e. 
> Rand McNally shows the stretch of US 36 in Brown County, KS as 
> freeway/motorway), and since this was already in place in Scottsbluff, NE, I 
> decided to apply it everywhere (and got a little carried away in the 
> process). I am trying to work on this when I have time, so if you have 
> anything I need to cleanup, let me know (it’s my mess, I should fix it up).
>  
> From: Martijn van Exel [mailto:m...@rtijn.org] 
> Sent: Tuesday, June 14, 2016 7:14 AM
> To: Toby Murray
> Cc: OSM Talk US
> Subject: Re: [Talk-us] User bumping all grade-separated intersections to 
> motorway
>  
> You could make a MapRoulette challenge out of it to have everyone help look 
> things over.
> Martijn
>  
>> On Jun 13, 2016, at 6:17 PM, Toby Murray > > wrote:
>>  
>> Here is a link to the Overpass query (warning: a couple MB of JSON to render)
>> http://overpass-turbo.eu/s/gMq 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Tony Emery]

Si on part du principe d'écarter la notion d'adresse postale (on laisse ça à
La Poste), il faut définir les enjeux de l'adresse physique pour savoir
comment on la décrit.

On a dit que, pour les adresses des commerces, on utilise les tags
contact:xxx. Quant à la description des plaques des noms des rues et des
numéros d'adresse mais, en soit, cela n'a pas beaucoup d'utilité.

Par contre, la notion d'adresse physique pour la navigation routière, le
déplacement des services d'urgence, le dénombrement des logements,...

De fait, si une adresse dessert plusieurs bâtiments physiquement séparés,
cela ne me semble pas incohérent d'attribuer à chaque bâtiment  (Exemple)
  .



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875494.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

Tu peux encadrer. Trouve moi ce noeud sur le terrain et dis moi pourquoi
les noeuds voisins à la même adresse ne sont pas non plus cette adresse !
C'est un problème de représentation car le noeud ne désigne que lui-même et
le reste c'est de l'approximation.

Je maintiens qu'il n'y a strictement rien qui rattache ce noeud à ce qui
est autour et qui a besoin pourtant d'être distingué (deux commerces
différents).

Et si les adresses de contact de ces commerces sont totalement ailleurs
(pas à l'adresse du noeud d'adresse le plus proche), ta "pseudo-solution"
avec contact:* est totalement bancale et ne tient pas la route.

Je maintiens que cces commerces sont distincts, qu'ils ne sont représenyés
qu'une seule fois mais qu'ils ont chacun besoin d'être rattaché à une
adresse qui n'est pas positionné dessus: il n'y a aucune solution sans
relation ni sans attribut addr:* qui a été détourné dans votre vision
franco-française, de la vision initiale de ces attributs tels qu'ils ont
été définis.

Note: je n'ai jamais dit qu'il ne faillait pas fusionner les noeuds quand
c'est possible, mais là c'est impossible car les deux commerces sont
voisins et bien distincts.

Franchement je ne vois absolument pas le problème à mettre un attribut (pas
un nouvel objet) addr:housenumber sur chacun des deux commerces, **même**
si la valeur est identique. Il n'y a aucun doublon "d'objet" ce ne sont pas
les mêmes objets !

Le 14 juin 2016 à 16:28, Romain MEHUT  a écrit :

> On les encadre où celles-ci "*Une adresse cadastrale n'est même pas un
> objet en soit (le noeud anonyme qu'on met dans OSM est arbitraire et ne
> correspond pas à la réalité qui désigne une surface incluant plusieurs
> éléments.*" et "*Le noeud d'adresse n'est qu'une position approximative.
> Ce n'est pas un objet, il n'a aucune réalité en lui-même sur le terrain.*"
> ?
>
> Help...
>
> Romain
>
> Le 14 juin 2016 à 16:23, Philippe Verdy  a écrit :
>
>> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
>>
>>> Bonjour,
>>>
>>> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>>>
>>>
 Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
 des noeuds différents, proches mais taguant des objets différents ayant
 *certaines* propriétés communes (dont le numéro de rue associé).

>>>
>>> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de
>>> ne décrire un objet qu'une fois, et c'est une règle générale pas spécifique
>>> aux adresses.*"
>>>
>>
>> Une adresse cadastrale n'est même pas un objet en soit (le noeud anonyme
>> qu'on met dans OSM est arbitraire et ne correspond pas à la réalité qui
>> désigne une surface incluant plusieurs éléments. Et non il ne s'agit PAS
>> des mêmes objets puisqu'ils n'ont PAS les mêmes attributs. Et RIEN du tout
>> n'attanche réelelment les POIs (batiments entiers ou noeuds d'un commerce)
>> à son adresse réelle hormis une très relative proximité entre eux et un
>> point arbitraire d'adresse !
>>
>>
>>>
 Dans le cas présent, le doublon est en fait le noeud d'adresse "40"
 vide de tags et PAS les deux deux des POIs distincts des deux commerces qui
 sont au 40: en effet ce noeud vierge a toutes ses propriétés communes avec
 les deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus
 d'autorité que les deux autres, il n'ajoute rien de mieux.

>>>
>>> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
>>> justement l'adresse en question. Partant du constat qu'on ne décrit un
>>> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
>>> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
>>> sens.
>>>
>>
>> Le noeud d'adresse n'est qu'une position approximative. Ce n'est pas un
>> objet, il n'a aucune réalité en lui-même sur le terrain. Tu peux tourner la
>> question comme tu veux mais il ne décrit que lui-même et pas du tout ce qui
>> est autour !
>>
>>>
>>>
 En revanche le "contact:housenumber" n'est pas une indication
 géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
 pour en faire une adresse suffisante comme adresse de contact) il n'est
 même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
 aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
 avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
 objet).

>>>
>>> D'accord, qu'il manque un contact:street.
>>>
>>
>>
>> ___
>> 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

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[Tony Emery]

Du coup, quand on créé une requête overpass pour récupérer les données dans
un fichier xml (par défaut), est-ce qu'on peut paramétrer la requête pour
qu'elle ne télécharge que la différence entre la base osm et ce qui est dans
le fichier xml ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-de-donnees-OSM-dans-PostGIS-tp5875478p5875492.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Romain MEHUT]

On les encadre où celles-ci "*Une adresse cadastrale n'est même pas un
objet en soit (le noeud anonyme qu'on met dans OSM est arbitraire et ne
correspond pas à la réalité qui désigne une surface incluant plusieurs
éléments.*" et "*Le noeud d'adresse n'est qu'une position approximative. Ce
n'est pas un objet, il n'a aucune réalité en lui-même sur le terrain.*" ?

Help...

Romain

Le 14 juin 2016 à 16:23, Philippe Verdy  a écrit :

> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
>
>> Bonjour,
>>
>> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>>
>>
>>> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
>>> des noeuds différents, proches mais taguant des objets différents ayant
>>> *certaines* propriétés communes (dont le numéro de rue associé).
>>>
>>
>> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de
>> ne décrire un objet qu'une fois, et c'est une règle générale pas spécifique
>> aux adresses.*"
>>
>
> Une adresse cadastrale n'est même pas un objet en soit (le noeud anonyme
> qu'on met dans OSM est arbitraire et ne correspond pas à la réalité qui
> désigne une surface incluant plusieurs éléments. Et non il ne s'agit PAS
> des mêmes objets puisqu'ils n'ont PAS les mêmes attributs. Et RIEN du tout
> n'attanche réelelment les POIs (batiments entiers ou noeuds d'un commerce)
> à son adresse réelle hormis une très relative proximité entre eux et un
> point arbitraire d'adresse !
>
>
>>
>>> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
>>> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
>>> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
>>> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
>>> que les deux autres, il n'ajoute rien de mieux.
>>>
>>
>> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
>> justement l'adresse en question. Partant du constat qu'on ne décrit un
>> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
>> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
>> sens.
>>
>
> Le noeud d'adresse n'est qu'une position approximative. Ce n'est pas un
> objet, il n'a aucune réalité en lui-même sur le terrain. Tu peux tourner la
> question comme tu veux mais il ne décrit que lui-même et pas du tout ce qui
> est autour !
>
>>
>>
>>> En revanche le "contact:housenumber" n'est pas une indication
>>> géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
>>> pour en faire une adresse suffisante comme adresse de contact) il n'est
>>> même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
>>> aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
>>> avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
>>> objet).
>>>
>>
>> D'accord, qu'il manque un contact:street.
>>
>
>
> ___
> 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] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :

> Bonjour,
>
> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>
>
>> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
>> des noeuds différents, proches mais taguant des objets différents ayant
>> *certaines* propriétés communes (dont le numéro de rue associé).
>>
>
> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de ne
> décrire un objet qu'une fois, et c'est une règle générale pas spécifique
> aux adresses.*"
>

Une adresse cadastrale n'est même pas un objet en soit (le noeud anonyme
qu'on met dans OSM est arbitraire et ne correspond pas à la réalité qui
désigne une surface incluant plusieurs éléments. Et non il ne s'agit PAS
des mêmes objets puisqu'ils n'ont PAS les mêmes attributs. Et RIEN du tout
n'attanche réelelment les POIs (batiments entiers ou noeuds d'un commerce)
à son adresse réelle hormis une très relative proximité entre eux et un
point arbitraire d'adresse !


>
>> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
>> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
>> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
>> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
>> que les deux autres, il n'ajoute rien de mieux.
>>
>
> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
> justement l'adresse en question. Partant du constat qu'on ne décrit un
> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
> sens.
>

Le noeud d'adresse n'est qu'une position approximative. Ce n'est pas un
objet, il n'a aucune réalité en lui-même sur le terrain. Tu peux tourner la
question comme tu veux mais il ne décrit que lui-même et pas du tout ce qui
est autour !

>
>
>> En revanche le "contact:housenumber" n'est pas une indication
>> géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
>> pour en faire une adresse suffisante comme adresse de contact) il n'est
>> même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
>> aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
>> avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
>> objet).
>>
>
> D'accord, qu'il manque un contact:street.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT ALCA APPUI PERFORMANCE)]

Quelques liens : 
http://www.gaia-gis.it/gaia-sins/
https://www.gaia-gis.it/spatialite-2.3.0/install-windows.html
https://www.gaia-gis.it/spatialite-2.3.0/docs.html 
https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/index.html#haute_cuisine 

je sais pas si c'est assez user-friendly pour toi.

-Message d'origine-
De : Tony Emery [mailto:tony.em...@yahoo.fr] 
Envoyé : mardi 14 juin 2016 15:59
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Import de données OSM dans PostGIS

Tu as de la doc "user friendly" là-dessus ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-de-donnees-OSM-dans-PostGIS-tp5875478p5875487.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Romain MEHUT]

Bonjour,

Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :


> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
> des noeuds différents, proches mais taguant des objets différents ayant
> *certaines* propriétés communes (dont le numéro de rue associé).
>

Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de ne
décrire un objet qu'une fois, et c'est une règle générale pas spécifique
aux adresses.*"


> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
> que les deux autres, il n'ajoute rien de mieux.
>

Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
justement l'adresse en question. Partant du constat qu'on ne décrit un
objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
sens.


> En revanche le "contact:housenumber" n'est pas une indication
> géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
> pour en faire une adresse suffisante comme adresse de contact) il n'est
> même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
> aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
> avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
> objet).
>

D'accord, qu'il manque un contact:street.

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

Re: [OSM-co] La Unidad de Mapeo Humanitario (UMH) estrena su drone en el volcán Machín

[Artesano]

En hora buena.
El 14/6/2016 8:47 a. m., "hyan...@gmail.com"  escribió:

> Estimados maperos,
>
> con un vuelo sobre el volcán Machín
> , uno de los más
> peligrosos del mundo; un dragón que duerme en la cordillara central de los
> Andes colombianos, la Unidad de Mapeo Humanitario de OSM Colombia hace el
> vuelo inaugural de su primer drone, un multirotor adquirido gracias al
> aporte de Fredy Rivera tras resultar ganador en el programa Titán Caracol.
>
> https://twitter.com/OpenStreetMapCo/status/742704669991047168
>
> Como complemento para la capacidad de capturar imágenes aéreas durante
> desastres y crisis humanitarias, el deseo es contar con otro drone de ala
> fija, pronto se estará compartiendo con ustedes un enlace para recibir sus
> donaciones, desde $10.000 pesitos en adelante.
>
> Mil gracias,
>
> Humberto Yances
> OSM Colombia
>
> ___
> Talk-co mailing list
> Talk-co@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-co
>
>
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-us] User bumping all grade-separated intersections to motorway

[Joseph Barnes]

Just to make it easier for y'all, the offending changesets are from late
January 2016 to mid-May 2016, and are mostly in the states of NE, KS, IA,
and MO. My theory here was that there should be continuity between maps
(i.e. Rand McNally shows the stretch of US 36 in Brown County, KS as
freeway/motorway), and since this was already in place in Scottsbluff, NE, I
decided to apply it everywhere (and got a little carried away in the
process). I am trying to work on this when I have time, so if you have
anything I need to cleanup, let me know (it's my mess, I should fix it up).

 

From: Martijn van Exel [mailto:m...@rtijn.org] 
Sent: Tuesday, June 14, 2016 7:14 AM
To: Toby Murray
Cc: OSM Talk US
Subject: Re: [Talk-us] User bumping all grade-separated intersections to
motorway

 

You could make a MapRoulette challenge out of it to have everyone help look
things over.

Martijn

 

On Jun 13, 2016, at 6:17 PM, Toby Murray  wrote:

 

Here is a link to the Overpass query (warning: a couple MB of JSON to
render)
  http://overpass-turbo.eu/s/gMq

 

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

[OSM-talk-fr] Adresses, lotissements et résidences

[Tony Emery]

Bonjour à tous,

Bon, allez, comme je suis en forme aujourd'hui, je vous propose un autre
défi qui concerne les adresses.

*Le contexte :* 
- Création des adresses directement dans OpenStreetMap ;
- Utilisation de la relation associatedStreet pour lier les points d'adresse
et les tronçons de voies ;
- Utilisation de l'outil http://cadastre.openstreetmap.fr/ pour importer les
adresses ;
- Travail avec les communes pour récupérer les délibérations de création,
dénomination et numérotation des voies ;
- Travail avec les services urbanisme pour récupérer les permis de
construire et de lotir (= nouveaux logements et donc nouvelles adresses
potentielles) ;
- Travail de terrain pour consolider tout ça ;
- Travail avec l'INSEE pour mettre à jour et corriger le Répertoire des
Immeubles Localisés, qui sert de base pour les recensements annuels de la
population.

Tout ça fonctionne plutôt bien avec des adresses normées numéro, type voie,
libellé voie (ex : 3 Avenue de la République).

*La problématique voirie*
Par contre, dès que l'on entre dans une résidence ou un lotissement, c'est
le caca.
J'ai pris le parti de dessiner dans OSM les contours des lotissements et des
résidences (immeubles collectifs) avec les tags landuse=residential et
place=neighbourhood. C'est peut-être pas le bon tag, mais j'ai pas trouvé
mieux.
Du coup, j'ai un problème pour gérer dans un système unique les voies qui
sont à l'intérieur d'un lotissement ou d'une résidence et qui, soit:
- contienne un nom officiel (délibération de la commune) ;
- contienne un nom non-officiel (donné par les riverains) ;
- sont officiellement ou non dénommées comme le lotissement ;
- n'ont pas de nom ;

*La problématique adresses*
Et à tout cela, y ajouter :
- les adresses avec un numéro qui peut être le même dans 2 lotissement
différents et desservis pas la même voie ;
- les anciennes numérotations classiques qui côtoient les nouvelles
numérotations métriques ;
- la notion de bâtiment ou de porte dans les résidences (et qu'ils
apparaissent dans osm.org) ;
- les voies qui n'ont jamais été numérotées mais pour lesquelles on a
recensé des logements ;

Voilà, si c'est trop compliqué à traiter ici, on peut, peut-être, ouvrir une
page spéciale dans le wiki.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Adresses-lotissements-et-residences-tp5875483.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-co] La Unidad de Mapeo Humanitario (UMH) estrena su drone en el volcán Machín

[hyan...@gmail.com]

Estimados maperos,

con un vuelo sobre el volcán Machín
, uno de los más
peligrosos del mundo; un dragón que duerme en la cordillara central de los
Andes colombianos, la Unidad de Mapeo Humanitario de OSM Colombia hace el
vuelo inaugural de su primer drone, un multirotor adquirido gracias al
aporte de Fredy Rivera tras resultar ganador en el programa Titán Caracol.

https://twitter.com/OpenStreetMapCo/status/742704669991047168

Como complemento para la capacidad de capturar imágenes aéreas durante
desastres y crisis humanitarias, el deseo es contar con otro drone de ala
fija, pronto se estará compartiendo con ustedes un enlace para recibir sus
donaciones, desde $10.000 pesitos en adelante.

Mil gracias,

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

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT ALCA APPUI PERFORMANCE)]

Tu as pensé à une solution spatialite ?
Avantages :
- installation enfantine
- multi-plateforme
- s'intègre directement dans ArcGIS (v 10.3 minimum) selon la doc (mais pas 
encore testé)
- base mono-utilisateur
- très paramétrable (et automatisable, y compris avec du python)
- fonctionne très bien aussi avec QGis (testé du coup ;-)
- export possible en shapefile
-  compatbible OGC

Inconvénients
- je ne sais pas comment ça tient la charge si volume très important de données.

Pour ma part c'est les choix sur lesquels je m'oriente pour un projet similaire 
que je vais démarrer très prochainement.
Pourquoi une geodatabase ?

Denis


-Message d'origine-
De : Tony Emery [mailto:tony.em...@yahoo.fr] 
Envoyé : mardi 14 juin 2016 15:18
À : talk-fr@openstreetmap.org
Objet : [OSM-talk-fr] Import de données OSM dans PostGIS

Bonjour à tous,

Suite aux différentes présentations du dernier SOTM-FR et en lien avec une 
réflexion que je mène déjà depuis quelques temps, je me lance (enfin) dans le 
grand bain de l'import quasi-big data.

En fait, je souhaite aller plus loin dans la démarche d'import des données OSM 
en local que celle que j'ai présenté à Clermont-Ferrand.

Jusqu'à présent, j'utilise un script python pour automatiser l'import de 
certaines données OSM dans des fichiers planet en local, puis, avec la 
bibliothèque arcpy d'ESRI, qui renvoi tout ça dans une géodatabase ESRI (je 
vous entends siffler dans le fond).

J'ai bien écouté les présentations qui expliquaient comment utiliser osm2pgsql, 
switch2osm et autre imposm3. Mais il y a 2 contraintes que je n'arrive pas à 
lever :
- comment ça s'installe, ça se paramètre et ça fonctionne ?
- Est-ce qu'il existe la même chose pour un environnement Windows, car nos 
serveurs sont ainsi ?

Du coup, je recherche un tutoriel à jour (donc récent) et qui explique
(très) simplement comment mettre en place une solution automatisée permettant :
- de télécharger les données d'une emprise géographique tous les soirs (ou, à 
défaut, le différentiel)
- que ces données soient versées plus ou moins directement dans une Base 
PostGIS.
Pour le coup, je suis aussi éventuellement preneur d'une solution full open 
source Ubuntu que je testerai chez moi.

Merci d'avance pour vos idées.

Tony



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-de-donnees-OSM-dans-PostGIS-tp5875478.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Avis de thèse à l'IGN

[Nicolas Moyroud]

Même réflexion en lisant le titre. Certians diront peut-être que j'ai 
l'esprit mal placé mais en lisant  le résumé voici ce que j'entend à 
demi-mot : comment nous le grand IGN pouvons-nous aider ces pauvres 
diables qui se démènent avec un système collaboratif (donc défectueux 
par nature) à faire des choses aussi bonnes que les notres ? Quand je 
vois certains des trucs qu'il propose dans le sujet, je ne sais pas si 
ils croient innover, mais moi la plupart du temps j'ai juste 
l'impression qu'ils parlent d'osmose... Fred devrait postuler il a déjà 
presque fait les 3 ans de travail ;-)


Nicolas

Le 14/06/2016 14:53, Tony Emery a écrit :

La problématique est peine orientée : "fraude, confiance et crédibilité".
Ils auraient pu écrire "Dites-nous pourquoi OSM est pourri ?"





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

[Talk-it] fotomappatura del Canal Grande?

[Marco Predicatori]

Guardate l'aggeggino visto galleggiare il 3 giugno scorso:
http://s31.postimg.org/vql01oqfv/leica_pegasus_two.jpg

Info del produttore:
http://leica-geosystems.com/products/mobile-sensor-platforms/capture-platforms/leica-pegasus_two

-- 
Bye, Marco
https://www.openstreetmap.org/user/marco69

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

[OSM-talk-fr] Import de données OSM dans PostGIS

[Tony Emery]

Bonjour à tous,

Suite aux différentes présentations du dernier SOTM-FR et en lien avec une
réflexion que je mène déjà depuis quelques temps, je me lance (enfin) dans
le grand bain de l'import quasi-big data.

En fait, je souhaite aller plus loin dans la démarche d'import des données
OSM en local que celle que j'ai présenté à Clermont-Ferrand.

Jusqu'à présent, j'utilise un script python pour automatiser l'import de
certaines données OSM dans des fichiers planet en local, puis, avec la
bibliothèque arcpy d'ESRI, qui renvoi tout ça dans une géodatabase ESRI (je
vous entends siffler dans le fond).

J'ai bien écouté les présentations qui expliquaient comment utiliser
osm2pgsql, switch2osm et autre imposm3. Mais il y a 2 contraintes que je
n'arrive pas à lever :
- comment ça s'installe, ça se paramètre et ça fonctionne ?
- Est-ce qu'il existe la même chose pour un environnement Windows, car nos
serveurs sont ainsi ?

Du coup, je recherche un tutoriel à jour (donc récent) et qui explique
(très) simplement comment mettre en place une solution automatisée
permettant :
- de télécharger les données d'une emprise géographique tous les soirs (ou,
à défaut, le différentiel)
- que ces données soient versées plus ou moins directement dans une Base
PostGIS.
Pour le coup, je suis aussi éventuellement preneur d'une solution full open
source Ubuntu que je testerai chez moi.

Merci d'avance pour vos idées.

Tony



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Import-de-donnees-OSM-dans-PostGIS-tp5875478.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-us] User bumping all grade-separated intersections to motorway

[Martijn van Exel]

You could make a MapRoulette challenge out of it to have everyone help look 
things over.
Martijn

> On Jun 13, 2016, at 6:17 PM, Toby Murray  wrote:
> 
> Here is a link to the Overpass query (warning: a couple MB of JSON to render)
> http://overpass-turbo.eu/s/gMq 

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

Re: [Talk-cz] WeeklyOSM CZ 303

[jzvc]

Dne 10.6.2016 v 21:04 Marián Kyral napsal(a):

Tak mělo by to být provizorně opraveno. Bohužel Firefox se z toho sám
nevzpamatuje. Je potřeba vymazat "Nastavení pro daný server".

1) Předvolby / Soukromí / "vymazat nedávnou historii"
2) Vybrat časové období: "Vše"
3) Rozkliknout "Podrobnosti"
4) Vybrat pouze "Nastavení pro daný server" - zbytek odškrknout.
5) Kliknout na vymazat


Cus,
pokud mas nastaveno vlastni, tak tam pro jistotu ta volba na smazani 
historie vubec neni. A zcela zjevne si u tohoto proste nemuzes vybrat, 
jestli to ulozit chces nebo nechces. Dtto interni databaze (o ktery 
vetsina lidi ani nevi, ze existuje) atd.



FF je cim dal horsi a horsi.



Pak by to mělo zase fungovat.

V případě neúspěchu zavřít všechny taby s openstreetmap.cz a zkusit znova.

http://stackoverflow.com/a/34033592

Marián

Dne 7.6.2016 v 14:23 Jan Martinec napsal(a):


Z HTTP to redirectuje :(

HPM

Dne 7. 6. 2016 13:13 napsal uživatel "Marián Kyral" >:

Ahoj,
určitě koukáš přes http? Nemáš nějaký doplněk, který to přepíná
na https? Je tam bohužel mixed content a novější prohlížeče s tím
mají existenční problémy :-(

http mi jinak jede normálně.

Marián

-- Původní zpráva --
Od: MatějCepl >
Komu: talk-cz@openstreetmap.org 
Datum: 7. 6. 2016 13:05:50
Předmět: Re: [Talk-cz] WeeklyOSM CZ 303


On 2016-06-07, 08:54 GMT, Tom Ka wrote:
> http://www.weeklyosm.eu/cz/archives/7456

Tak jsem si početl jak je http://openstreetmap.cz/ úžasný
a chtěl jsem se tedy podívat na nové dlaždice (normálně používám
http://osm.org) a dočkal jsem se akorát šedého fleku a chybové
hlášky ve Firefoxu 45.1.1:

12:19:42.202 TypeError: L.Control.Search is not a constructor
osmcz.controls() controls.js:15
initmap() osmcz.js:21
 osmcz.js:10
1 controls.js:15:23

Hezký den,

Matěj

--
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz

GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

But if we find we have left our bones to bleach in these desert
sands for nothing, beware the fury of the legions...
-- Centurion in a letter home from North Africa
3rd Century


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


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



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




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




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

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

[Alessandro]

Il 18/05/2016 09:01, Gianmario Mengozzi ha scritto:

per quanto per alcuni già noto, segnalo che in alcune province dell'ER i
civici sono già stati importati.

sono disponibile fin d'ora , nel caso si decida di formare un gruppo di
lavoro ad-hoc



Mi pare che sia calato l'interesse sull'argomento. Mi potrei rendere 
disponibile per la città di Piacenza.


Alessandro Ale_Zena_IT


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

Re: [Talk-it] Cancellazioni sospette nuovo utente

[Martin Koppenhoefer]

sent from a phone

> Il giorno 14 giu 2016, alle ore 14:42, Federico Cortese 
>  ha scritto:
> 
> mi pare un caso da revert immediato


+1


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

Re: [OSM-talk-fr] Avis de thèse à l'IGN

[Tony Emery]

La problématique est peine orientée : "fraude, confiance et crédibilité".
Ils auraient pu écrire "Dites-nous pourquoi OSM est pourri ?"



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Avis-de-these-a-l-IGN-tp5875464p5875473.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-it] aggiornamento Wiki

[Federico Cortese]

2016-06-14 14:38 GMT+02:00 Alessandro :
>
> Quelle informazione erano lì già da un sacco di tempo :-)
>
Ops me le ero perse :)
Grazie Alessandro

Ciao
Federico

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

Re: [Talk-it] Cancellazioni sospette nuovo utente

[Federico Cortese]

2016-06-14 14:21 GMT+02:00 John Doe :

> Buongiorno,
>
> non so se qualcuno può o vuole verificare:
> https://overpass-api.de/achavi/?changeset=39995612
> Dalle immagini satellitari sembra che l'utente abbia combinato un
> pasticcio ma non conoscendo la situazione attuale della zona chiedo a voi.
>

Nemmeno io conosco la zona, ma mi pare un caso da revert immediato, perchà
ha:
- cancellato una linea elettrica lasciando le torri;
- eliminato il perimetro dell'ospedale;
- eliminato il poligono del Consiglio Regionale (anche se alcuni tag
andavano tolti tipo area=yes e amenity=townhall);
- eliminata viabilità interna;
- spostato nodo della viabilità pubblica in posizione arbitraria.
Ciao

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

Re: [Talk-it] aggiornamento Wiki

[Alessandro]

Il 13/06/2016 22:06, Federico Cortese ha scritto:



Grazie, informazioni molto interessanti!
Tra l'altro avevo proprio un N900 da riciclare.
Ciao



Quelle informazione erano lì già da un sacco di tempo :-)

Ne approfitto per segnalare che ho aggiunto un pò d'informazioni sulla 
configurazione di RTKGPS+, al prossimo giro aggiungo qualche schermata.
Per chi ha perso le puntate precedenti, il sistema completo viene a 
costare intorno i 150€ e nei migliori dei casi si ottengono precisioni 
intorno ai 10cm Il modello u-blox M8T permette anche di ottenere i dati 
in formato adatto al postprocessing coi file RINEX (in questo caso non 
occorre avere la connessione ad internet sullo smartphone perchè il 
tutto avviene in una fase successiva.


http://wiki.openstreetmap.org/wiki/IT:GPS_Reviews

Alessandro Ale_Zena_IT


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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

[Sven Geggus]

Martin Koppenhoefer  wrote:

> ja, gibt es:
> http://wiki.openstreetmap.org/wiki/Map_Icons
> 14x14, pixel aligned, so simpel wie möglich

Die "Dokumentengröße" ist aber normalerweise rundum ein Pixel mehr also die
bereits genannten 16x16.

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[Talk-it] Cancellazioni sospette nuovo utente

[John Doe]

Buongiorno,

non so se qualcuno può o vuole verificare:
https://overpass-api.de/achavi/?changeset=39995612
Dalle immagini satellitari sembra che l'utente abbia combinato un pasticcio
ma non conoscendo la situazione attuale della zona chiedo a voi.

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

[OSM-talk-fr] Avis de thèse à l'IGN

[Vincent de Château-Thierry]

Bonjour,
vu passer à l'instant : 
http://georezo.net/forum/viewtopic.php?pid=283341#p283341

Sujet :
"Qualification des contributions dans un système de saisie cartographique 
collaborative : fraude, confiance et crédibilité"

Le PDF avec les détails : 
http://recherche.ign.fr/labos/cogit/pdf/PROPOSITIONS/2016/sujet-these-2016_touya.pdf

vincent

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

Re: [Talk-us] User bumping all grade-separated intersections to motorway

[Joseph Barnes]

I'm slowly working on it, specifically on the non-grade-separated areas. I got 
this from the Scottsbluff, NE bypass (which I did NOT do), so that's the 
originator. I just happened to have a lot of time on my hands and be bored.

I only started doing this after late January this winter, so that should narrow 
it down a bit.

-Original Message-
From: Toby Murray [mailto:toby.mur...@gmail.com] 
Sent: Monday, June 13, 2016 6:18 PM
To: talk-us
Subject: [Talk-us] User bumping all grade-separated intersections to motorway

I just discovered some misguided edits and the user in question seems to have 
made many of them over a wide area so I thought I would put people on notice to 
be aware of this.

While on the Biking Across Kansas tour last week I saw some odd looking 
segments in OsmAnd along US 36 in Kansas. I got home this weekend and saw the 
same thing locally.

Upon investigation it looks like user "SD Mapman" has gone around upgrading 
grade-separated intersections to highway=motorway, regardless of any other 
criteria. So US 36 in Kansas had a random section of highway=motorway for less 
than a mile even though the rest of it is highway=primary and it is a two-lane 
highway with nothing between the lanes but a dashed yellow line and sometimes a 
center rumble strip.

He also did not use the oneway=no tag so it has ruined routing of single 
carriageway highways in one direction because routers assume motorways are 
one-way by default.

I made a comment on one of the changesets. I have not received a response yet 
however he is now going back and downgrading them from motorway to trunk. I 
still think this is not correct and will probably go back and reclassify them 
to what they were before his edits, at least in Kansas.

According to a quick overpass query, he is the last editor of highway=motorway 
ways in 22 states so these will probably need to be reviewed.

Here is a link to the Overpass query (warning: a couple MB of JSON to render) 
http://overpass-turbo.eu/s/gMq

Toby

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


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

Re: [Talk-br] Avenida Rio Branco, Rio de Janeiro

[Erick de Oliveira Leal]

Opa, já que esteve lá corrige para nós Arlindo, ela está definida como
somente para pedestres.

Em 14 de junho de 2016 08:38, Arlindo Pereira 
escreveu:

> Retomando, aqui está o trecho no Mapillary:
> https://www.mapillary.com/map/im/_cUGEo5IXul0Khgm7RPRjA/photo
>
> É possível ver que este quarteirão tem circulação de veículos.
>
> []s
>
> 2016-06-12 20:54 GMT-03:00 Arlindo Pereira :
>
>> Opa, respondi sem olhar o ponto. Sim, entre a Rua do Passeio e a Mestre
>> Valentim está liberado para veículos sim. O boulevard vai só até a
>> Cinelândia mesmo.
>>
>> Mais tarde edito e corrijo (se ninguém o fizer primeiro).
>>
>> 2016-06-12 20:53 GMT-03:00 Arlindo Pereira 
>> :
>>
>>> Exatamente. Coincidentemente passei por lá hoje e registrei fotos para o
>>> Mapillary nos dois sentidos. Quando terminar de subir e processar mando o
>>> link.
>>>
>>> []s
>>>
>>> On Sun, Jun 12, 2016 at 12:03 PM, Paulo Carvalho <
>>> paulo.r.m.carva...@gmail.com> wrote:
>>>
 Entre esse ponto e o aterro não passa mais carros.  Se o waze indica
 outra coisa, está errado.

 Em 12 de junho de 2016 11:16, Erick de Oliveira Leal <
 erickdeoliveiral...@gmail.com> escreveu:

> No waze mostra que a partir deste ponto eh pra veículos.
> Em 12 de jun de 2016 10:53 AM, "Paulo Carvalho" <
> paulo.r.m.carva...@gmail.com> escreveu:
>
>> Não.  A partir daí só passam o VLT, ciclistas e pedestres.
>>
>> Em 12 de junho de 2016 09:37, Erick de Oliveira Leal <
>> erickdeoliveiral...@gmail.com> escreveu:
>>
>>> Amigos do Rio, a Avenida Rio Branco a partir do ponto
>>> http://www.openstreetmap.org/node/1981177106 é permitida para
>>> carros, não?
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>

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


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

[Talk-ca] Northcumberlain Strait

[Marco]

Hi, I'm a foreign mapper from Italy who ran into a note [1] in Canada 
and I'd like you to have a look at that and see what do you guys think 
about it, given that you are the landlord here.


Searching for "Northumberland Strait" in OSM gives back almost ten 
results of which just one is in the middle of the strait, the remaining 
6 or 7 seems randomly placed into the Strait area. My doubt is: wouldn't 
be possible (or more correct) to create a relation including every 
square mile of the Strait, as it is happening for cities, lakes,...? 
Does the Strait size is a problem?


[1] https://www.openstreetmap.org/note/219629


Thanks for your time

Best regards

Marco


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

Re: [Talk-it] Nomi dei luoghi

[Paolo Monegato]

Il 10/06/2016 09:32, Alessandro Palmas ha scritto:
I nomi in lingue e alfabeti diversi sono già ampiamente supportati, 
guarda qui ad esempio

http://www.openstreetmap.org/relation/44915
Milano è nominata in 25 lingue diverse e diversi alfabeti; in più, col 
tag loc_name è stato usato il dialetto locale.


imho quel loc_name dovrebbe essere un name:lmo...

ciao
Paolo M


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

Re: [Talk-it] [Tagging] mugnaio

[Paolo Monegato]

Il 13/06/2016 11:33, Cascafico Giovanni ha scritto:


Con taginfo non ho molta familiarità, ma non ho trovato come taggare 
chi macina e vende farina.
Sul territorio che conosco ci sono almeno un paio di casi, che non 
catalogherei come greengrocer




Sul wiki c'è "industrial=grinding_mill" che potrebbe essere adatto, in 
combinazione con "sells:flour=yes".
Forse se la produzione non è a livello industriale potrebbe essere 
adattato anche a craft.


ciao
Paolo M


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

Re: [Talk-cz] Cykloznačení - puntík se stříškou

[Petr Vozdecký]

Ahoj vsem,

pro jistotu jeste jednou zopakuji, ze zatim jde o diskusi o nejakem 
"idealnim" tagovacim schematu. Jak jej aplikovat je diskuse jina.

Souhlasim s navrhem Mariana - viz níže, pokusím se to tam brzy nakopírovat.

Vítány jsou návrhy jak přesně postupovat dál, tedy např. zda a jak (jak 
dlouho etc.) vést diskusi v komunitě nad tímto návrhem schematu a poté jak a
kdy provéstr aplikaci (tedy to je ta věc kdy a zda něco mazat apod.).

vop



-- Původní zpráva --
Od: Pavel Machek 

"Ale ja pochopil ze Petr Vozecky chce hromadne v cele CR smazat
kct_*. A to by bylo na revert.
Pavel
"






-- Původní zpráva --
Od: Marián Kyral 

"

Řekl bych, že teď by bylo ideální popsat na wiki návrh nového tagování. 
Ideálně přidat novou sekci do http://wiki.openstreetmap.org/wiki/WikiProject
_Czech_Republic/Editing_Standards_and_Conventions#Turistick.C3.A9_zna.C4.8
Den.C3.AD 





Ať to máme pěkně pohromadě ;-)





Marián


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

Re: [Talk-cz] Proč je zde písmeno s?

[Matěj Cepl]

On 2016-06-14, 08:52 GMT, Petr Kadlec wrote:
> Vpravo je nástroj „průzkum prvků“ označený otazníčkem. Na ten 
> klikni, načež klikni na to S. Dostaneš přehled [1], ve kterém 
> v umístění prvku uvidíš také les pojmenovaný S [2]. Nevím, 
> jestli Milancer [3] má rád Medvídka Pú, nebo to byl jen nějaký 
> nechtěný překlep. 

Vím, že se nemá švindlovat, ale tohle snad není kopírování 
ničeho z ničeho, když řeknu, že Geoportál ČÚZK v souřadnicích 
ETRS89 (geographic 2D): X=49°40'47.99" Y=16°51'35.99" (čili 
S-JTSK / Krovak East North: X=-574142 Y=-1109056) neudává nic co 
by vypadalo jako možný překlep.

Takže můj soukromý závěr je, že se Milancer 
v https://www.openstreetmap.org/changeset/37870485 uklepnul 
a přidal nesmyslný název něčemu co název mít nemělo (resp. název 
je neznámý), a že bych ten název prostě smazal.

Hezký den,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Two things fill the heart with renewed and increasing awe and
reverence the more often and the more steadily that they are
meditated on: the starry skies above me and the moral law inside
me.
-- Immanuel Kant: Critique of Practical Reason


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

Re: [Talk-it] scontrini fiscali come fonte dati

[Martin Koppenhoefer]

sent from a phone

> Il giorno 14 giu 2016, alle ore 11:33, Max1234Ita  ha 
> scritto:
> 
> Che senso avrebbe far stampare opuscolo/volantino pubblicitario e poi
> mettere il copyright sulle informazioni riportate? :-)


non si può mettere copyright su fatti/informazioni 


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

Re: [Talk-it] scontrini fiscali come fonte dati

[girarsi_liste]

Il 14/06/2016 11:33, Max1234Ita ha scritto:
> Francesco Gargano wrote
>> grazie martin , ancora una domanda-curiosità che m'è venuta in mente :
>> spesso troviamo distribuite in locali pubblici , bar ristoranti etc. delle
>> riviste e degli opuscoli gratuiti (quelli di annunci per esempio) che
>> hanno
>> piccoli spazi o intere pagine pubblicitarie di attività economiche della
>> zona interessata. Le informazioni contenute su queste pubblicità possono
>> essere inserite per creare o aggiornare i dati presenti in OSM?
> 
> 
> IMHO, sì: la maggior diffusione possibile delle informazioni-chiave
> (indirizzo, telefono, orari di apertura) è virtualmente nell'interesse degli
> stessi esercizi pubblicizzati. 
> 
> Che senso avrebbe far stampare opuscolo/volantino pubblicitario e poi
> mettere il copyright sulle informazioni riportate? :-)
> 
> Max
> Max 
> 
In realtà il problema si sposta dalle informazioni al supporto ivi le
contiene, è quello coperto da copyright che di fatto ne impedisce la
copia (non so se leggere è compreso nella copia però :)).



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



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

Re: [Talk-it] scontrini fiscali come fonte dati

[Max1234Ita]

Francesco Gargano wrote
> grazie martin , ancora una domanda-curiosità che m'è venuta in mente :
> spesso troviamo distribuite in locali pubblici , bar ristoranti etc. delle
> riviste e degli opuscoli gratuiti (quelli di annunci per esempio) che
> hanno
> piccoli spazi o intere pagine pubblicitarie di attività economiche della
> zona interessata. Le informazioni contenute su queste pubblicità possono
> essere inserite per creare o aggiornare i dati presenti in OSM?


IMHO, sì: la maggior diffusione possibile delle informazioni-chiave
(indirizzo, telefono, orari di apertura) è virtualmente nell'interesse degli
stessi esercizi pubblicizzati. 

Che senso avrebbe far stampare opuscolo/volantino pubblicitario e poi
mettere il copyright sulle informazioni riportate? :-)

Max
Max 



--
View this message in context: 
http://gis.19327.n5.nabble.com/scontrini-fiscali-come-fonte-dati-tp5875359p5875457.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] tempo di percorrenza

[pietro marzani]

>Invece per la lunghezza della costa vale lo stesso ragionamento che hai

>fatto per l'area: dalla teoria degli errori [1] possiamo sapere lo scarto
>d'errore (+/-) della nostra misurazione, e la lunghezza "esatta" è
>sicuramente compresa in quell'intervallo.
>E' lo stesso errore del paradosso di Achille e la tartaruga [2], che
>matematicamente è spiegato dalle serie convergenti [3].


Interessante anche questo contributo, avevo pensato anche io a questo
paradosso quando parlavo di filosofia.
Resta il fatto che se disponessimo di un DEM al millimetro, per cui ogni
sassolino su un sentiero comporterebbe una salita ed una discesa il
dislivello totale potrebbe esplodere.
Se però teniamo presente che né a piedi né in bicicletta scaliamo i 
sassolini ci possiamo senz'altro accontentare di un DEM a un metro o
50 cm, e sono convinto, pensando alle strade ed ai sentieri che
affronto di solito, che con un DEM a 5 o 10 metri si può perdere
qualche metro ma non più di tanto.
Poi ovvio che se passi a un DEM a 50 o 100 metri o la traccia taglia
in piano un pendio particolarmente ripido o continua a passare da salita
a discesa ogni 2 metri l'errore aumenta.
Ciao
Pietro

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

[OSM-talk-be] Wegen en Verkeer

[Marc Gemis]

Onlangs kreeg ik een link van een mede mapper naar de website van
Wegen en Verkeer. Ze gebruiken ook een kaart gebaseerd op
OpenStreetMap. Jammer genoeg ontbrak de copyright.
Dit is zopas recht gezet nadat ik vorige week een mailtje had
gestuurd. Dus weer een website die "(C) OpenStreetMap auteurs" draagt.

mvg

p.s. http://wegenenverkeer.be/werken/regio

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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

[Martin Koppenhoefer]

sent from a phone

>> Aber ich habe noch eine allgemeine Frage zu den Icons für den Stil.
>> Gibt es eine Beschreibung wie die optimal gebaut sein sollen.


ja, gibt es:
http://wiki.openstreetmap.org/wiki/Map_Icons
14x14, pixel aligned, so simpel wie möglich


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

Re: [Talk-cz] Proč je zde písmeno s?

[Petr Kadlec]

2016-06-14 10:15 GMT+02:00 Miroslav Suchý :

> S tímhle si nedokážu poradit:
> http://www.openstreetmap.org/note/593489#map=14/49.6867/16.8902
>
> Nejdříve jsem si myslel, že to je pramen, pak někde zapomenuté s v názvu
> lesa, ale nemohu to najít.
> Nevíte někdo?
>

Vpravo je nástroj „průzkum prvků“ označený otazníčkem. Na ten klikni, načež
klikni na to S. Dostaneš přehled [1], ve kterém v umístění prvku uvidíš
také les pojmenovaný S [2]. Nevím, jestli Milancer [3] má rád Medvídka Pú,
nebo to byl jen nějaký nechtěný překlep.

-- Petr Kadlec / Mormegil

[1]:
https://www.openstreetmap.org/query?lat=49.68011=16.86938#map=17/49.67907/16.87040
[2]: https://www.openstreetmap.org/relation/24796
[3]: https://www.openstreetmap.org/relation/24796/history
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Proč je zde písmeno s?

[Miroslav Suchý]

S tímhle si nedokážu poradit:
http://www.openstreetmap.org/note/593489#map=14/49.6867/16.8902

Nejdříve jsem si myslel, že to je pramen, pak někde zapomenuté s v názvu 
lesa, ale nemohu to najít.

Nevíte někdo?

Mirek

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

Re: [OSRM-talk] OSRM map update

[sergi_jini]

Understood. Thanks again!

Br,
Sergi

On Mon, Jun 13, 2016 at 9:40 PM, Daniel Patterson  wrote:

> Sergi,
>
>   There is no data compatibility between releases.  You basically need to
> start from scratch.
>
> 1) Get the new code, and compile it
> 2) Get a new OSM file
> 3) Process it
> 4) Update your client code to use the new OSRM HTTP API
>
> daniel
>
> On Jun 13, 2016, at 11:09 AM, sergi_jini  wrote:
>
> Thanks for the hints Daniel,
>
> Map update is clear.
> As for the backend upgrade (I'm going to try 5.1.0), could you also advice
> few words how it's done?
>
> Br,
> Sergi
>
> On Mon, Jun 13, 2016 at 1:37 PM, Daniel Hofmann 
> wrote:
>
>> Here's how to run the toolchain:
>> https://github.com/Project-OSRM/osrm-backend/wiki/Running-OSRM
>>
>> Your release is a couple of years old (!), please upgrade to 5.1.0 or try
>> a 5.2.0 RC:
>> https://github.com/Project-OSRM/osrm-backend/releases
>>
>> Cheers,
>> Daniel
>>
>> On Mon, Jun 13, 2016 at 11:30 AM, sergi_jini 
>> wrote:
>>
>>> Hi,
>>>
>>> I have OSRM backend-0.3.7 running on Centos.
>>> Can someone advise how I can update the map for it? My assumption, I
>>> should run osrm-prepare and extract on new [some_map].pbf file? Are there
>>> any particular steps I should consider?
>>>
>>> Many thanks in advance.
>>> Sergi
>>>
>>> ___
>>> OSRM-talk mailing list
>>> OSRM-talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-it] tempo di percorrenza

[mbranco]

@martin
/faccio un paragone: per me ha senso parlare dell'area di un'isola, ma non
ha senso parlare della lunghezza della costa di un isola. Anche in questo
caso si possono sempre migliorare i numeri, ma la differenza è che l'area
non varia moltissimo tra una versione approssimativa ed una più precisa, si
avvicina sempre più alla cifra giusta, mentre nel caso della lunghezza della
costa non c'è questo limite, la costa diventa sempre più lunga più che si
guarda nel dettaglio./

Anch'io quando ho scoperto per la prima volta i frattali ho fatto lo stesso
errore di ragionamento.
Invece per la lunghezza della costa vale lo stesso ragionamento che hai
fatto per l'area: dalla teoria degli errori [1] possiamo sapere lo scarto
d'errore (+/-) della nostra misurazione, e la lunghezza "esatta" è
sicuramente compresa in quell'intervallo.
E' lo stesso errore del paradosso di Achille e la tartaruga [2], che
matematicamente è spiegato dalle serie convergenti [3].
La fisica quantistica ci ha poi dimostrato che su scala atomica e subatomica
le leggi della fisica a noi note non valgono più: non ha più senso parlare
di spazio, di tempo, di teoria della misura, ecc. 
Quindi non si pone neanche il problema di far tendere ad infinito la serie.
Per quanto ci interessa, ci possiamo fermare ben prima di arrivare alla
scala atomica: come è stato detto prima, ci possiamo accontentare degli 80
cm del passo umano (vogliamo tener conto anche dei bambini? facciamo 50cm
allora).

Venendo alla tua isola: anche ad OSM non interessa la lunghezza di una
costa, però se c'è una strada costiera che fa il periplo dell'isola, allora
vorrei saperlo se si parla di 20km o di 2000km (e pazienza se c'è l'errore
dello 0,001).

Ciao,

  Marco

[1} https://it.wikipedia.org/wiki/Teoria_degli_errori
[2] https://it.wikipedia.org/wiki/Paradosso_di_Achille_e_la_tartaruga
[3] https://it.wikipedia.org/wiki/Serie_convergente



--
View this message in context: 
http://gis.19327.n5.nabble.com/tempo-di-percorrenza-tp5875361p5875452.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-de] Verwendung von Markenlogos in Karten?

[Sven Geggus]

gmbo  wrote:

> Aber ich habe noch eine allgemeine Frage zu den Icons für den Stil.
> Gibt es eine Beschreibung wie die optimal gebaut sein sollen.

Mir nicht bekannt.

> Dateiformat möglichst SVG sonst eventuell PNG.
> Größe bei 16x16 px oder ?
> Farben ?
> gibt es sonst noch etwas wichtiges zu berücksichtigen.

SVG in 16x16px für die amenity und Shop Icons, dann muss man nicht im Style
skalieren.

Sven

-- 
Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit
Office nicht kompatibles Bürosoftwarepaket einzuführen.
(Florian Weimer in de.alt.sysadmin.recovery)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [OSM-talk-fr] Nouvelle affiche disponible : on s'amuse avec les cathédrales !

[Nicolas Moyroud]

Salut JB,

Génial le résultat ! Merci pour l'explication détaillée de la procédure.
Si je peux me permettre une remarque je trouve que dans le résultat 
final c'est dommage de mettre un carré rouge et aussi de faire 
apparaître le label sur la cathédrale. Dans la feuille de style utilisée 
avec Maperitive il me semble qu'il serait relativement facile de faire 
disparaître le carré et de positionner le label en dessous de chaque 
objet. Peut-être même qu'avec un autre couleur mieux choisie que ce 
rouge un peu pétard ce serait encore mieux.
Dans l'idée d'automatiser quasi intégralement le processus peux tu me 
dire quelles sont les manips finales que tu réalises avec Gimp ? Je 
pense notamment à l'utilisation d'magemagick qui permet également de 
faire des retouches d'images mais en ligne de commande.


Nicolas

Le 13/06/2016 19:33, JB a écrit :

Bonjour,

Après l'essai de faisabilité vite fait avec les églises d'Auvergne 
pour le SotM-FR pour ceux qui y étaient, j'ai essayé de faire quelque 
chose de plus complet : l'affiche des cathédrales de France. Le final 
ici : http://jb.isonoe.net/demo/Cathedrales_A1_400dpi_v0.png, fait 
pour être imprimé en A1 à 400dpi.


La démarche :

 - trouver une source de données qui liste les cathédrales. J'ai 
utilisé wikipédia, qui n'est peut-être pas forcément parfait (voir 
plus loin) :

https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_de_France
https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_catholiques_de_France 

https://upload.wikimedia.org/wikipedia/commons/b/b7/Cath%C3%A9drales_catholiques_romaines_de_France.png 



 - vérifier les données dans OSM :

- première extraction des building=cathedral. Quelques petits 
villages se sont attribués des cathédrales, je les repasse en 
building=church


- plus embêtant, trouver les batiments non indiqués en cathédrales 
: il faut se payer la comparaison entre la liste des existants dans 
OSM et la liste globale. Dans la plupart des cas, ça se fait 
relativement bien. Parfois c'est un peu plus tordu, rarement, aucune 
information ne recoupe les indications de wikipédia. Dans ces quelques 
cas, je n'ai touché à rien. La liste des éléments : 
http://jb.isonoe.net/cath/cath.csv (parmi les plus litigieux : Mâcon 
et celles marquées comme telles dans la dernière colonne). Je 
n'affirme pas avoir été parfait ni que ma source de données l'était : 
je pense avoir amélioré la qualité globale de la base de données mais 
si vous n'êtes pas d'accord avec le résultat, n'hésitez pas à modifier.


 - ré-extraire les données : Geofabrik est là pour la France d'ici 
avec un coup d'Osmosis derrière, Overpass pour les dom-tom. On 
rassemble les deux, on élimine la cathédrale de Monaco (et on gère 
l’éphémère doublon de Rodez).


La suite se fait par un petit script python/Maperipy exécuté sous 
Maperitive.


 - géocoder : l'api d'adresse.data.gouv.fr fait le gros du travail. 
Dans quelques territoires éloignés où la ban avoue son échec, le 
géocodage est fait à la main.


 - déplacer les éléments et les placer « au carré » : toujours 
python/Maperipy. Une première version assez crado ne reprojetait pas 
les objets, d'où des déformations assez importantes, surtout pour les 
éléments des dom-tom mais aussi certains en métropole : 
http://jb.isonoe.net/cath/Reproj.png. Le script est modifié pour 
respecter distances/formes (si je m'y suis bien pris).


 - exporter l'image, mettre en forme sous Gimp.

Le code, pas fait pour être partagé et qui ne fonctionnera 
probablement pas (très moche, non retravaillé, à peine commenté), est 
visible ici : http://jb.isonoe.net/cath/Eglises_rel1.py


Quelques autres documents intermédiaires :

 - Cathédrales utilisées, avec géocodage : 
http://jb.isonoe.net/cath/cath_brut_geocode_manuel.osm


 - Cathédrales au carré :
- non reprojetées : 
http://jb.isonoe.net/cath/Egl_offset_direct_ok.osm

- reprojetées : http://jb.isonoe.net/cath/Egl_offset_reproj_ok.osm

Ma version personnelle : http://jb.isonoe.net/cath/Photo_affiche.jpg

JB.


PS : pour le teasing, j'ai une autre idée plus matérielle… ça arrive 
dans quelques semaines !



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



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

Re: [Talk-at] Affenschaukel/Jumpsessel mappen

[Friedrich Volkmann]

On 14.06.2016 09:19, Robin Däneke wrote:

Ein User hat nahe des Schillwassers 2 Nodes gemappt, denen er den Namen
"Affenschaukel" verpasse hat. Ich denke, dass es sich dabei um sowas wie [0]
handelt. Soll sowas (wenn es öffentlich ist) erfasst werden, und gibt es da
sinnvolle Tags für sowas? Ist das eine "bench" oder was eigenes?


Na sicher kann das erfasst werden, aber das Tagging wird davon abhängen, 
wofür diese Schaukel hauptsächlich verwendet wird: zum Schaukeln 
(playground=basketswing ?) oder zum Ausruhen. In letzterem Fall würde ich, 
wenn ich kein passenderes Tag finde, das ähnlichste nehmen, eben 
amenity=bench. Das hab ich auch schon für Liegen, Sessel u.ä. verwendet.


Nominatim findet übrigens kein Schillwasser, ist das nur ein Tippfehler 
(statt Schillerwasser), oder gehört der Name in OSM noch eingetragen?


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[Talk-GB] London meetup on Thursday

[Andrew Hain]

The next London pub meetup will be on Thursday 16th June at 7pm in the Monkey 
Puzzle near Paddington station (http://themonkeypuzzlepub.co.UK). Sorry for the 
short notice.

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

Re: [Talk-it] Mapping Party Esino Lario

[Alessandro Palmas]

Il 07/06/2016 12:40, Alessandro Palmas ha scritto:

Ho creato la pagina wiki
http://wiki.openstreetmap.org/wiki/2016_Mapping_party_Esino_Lario
e messo l'evento nel calendario
http://wiki.openstreetmap.org/wiki/Template:Calendar



Dal 29 maggio al 3 giugno ci sono state 20 mail sull'argomento, dal 
giorno che ho pubblicato la notizia sulla wiki è calato il silenzio.

A questo punto direi di rinviarlo.

Dario pensava ad un MP a Mandello del Lario con visita al Museo Guzzi. 
Date un segno


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

[Talk-at] Affenschaukel/Jumpsessel mappen

[Robin Däneke]

Hallo,
Ein User hat nahe des Schillwassers 2 Nodes gemappt, denen er den Namen 
"Affenschaukel" verpasse hat. Ich denke, dass es sich dabei um sowas wie [0] 
handelt. Soll sowas (wenn es öffentlich ist) erfasst werden, und gibt es da 
sinnvolle Tags für sowas? Ist das eine "bench" oder was eigenes?
Mit freundlichen GrüßenRobinD
[0]: 
http://file1.npage.de/009750/83/bilder/rattanschaukel_affenschaukel_haengesessel_rattansessel.jpg
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] tempo di percorrenza

[Alfredo Gattai]

Per route=hiking è quasi inesistente il caso in cui siano due. Può esistere
per brevissimi tratti esposti e stretti ad esempio presso siti archeologici
dove per motivi di sicurezza viene attrezzato un percorso a senso unico per
non fare incontrare quelli che salgono con quelli che scendono. Nella quasi
totalità dei casi è un percorso solo che si fa nei due sensi.

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