date:20130923



 Am 23/set/2013 um 11:03 schrieb Pieren pier...@gmail.com:
 
 Check cities with tens of thousands buildings. You will have sometime
 the building tag on ways, sometimes on relations. Having the tag
 always on the surrounding way is more consistent and easier to catch
 for everybody, including newcomers.


it has a different meaning. tags on a closed way are for the whole area inside 
the way, tags on a mp relation are for the area of the outer minus the inner 
ways.

Where to put which tag depends on what you want to express.

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

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013-09-23 Per discussione Paul Norman

 From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com]
 Subject: Re: [OSM-talk] osm2pgsql multipolygon parsing

 it has a different meaning. tags on a closed way are for the whole area
 inside the way, tags on a mp relation are for the area of the outer
 minus the inner ways.

Unless the closed way is a member of a multipolygon relation with no other
tags on the relation - then you'll have a resulting area with a hole. This
is a very well established means of tagging areas with holes (~22% of
type=multipolygon relations have no other tags).

The issues raised originally in the ticket are best explored through
examples

The first case is a way with natural=water and a MP relation with no other
tags. Both old osm2pgsql (0.82) and latest master version from git create an
area with a hole with natural=water on the area. There are no suggestions of
changing this.

The second is a way with natural=water and a MP relation with name=foo (with
the way as a member). Old osm2pgsql created an area with a hole with
natural=water, name=foo, latest master does too.

The third is the second with the same as the 2nd, but a name:de tag added.
In old osm2pgsql this created an area without a hole, in latest master it
creates one with a hole.

The fourth is a way with natural=water and a MP relation with foo=bar. In
old osm2pgsql this created an area without a hole, in latest master it
depends on the .style file used for import.

To make #3 consistent with #2 without breaking backwards compatibility
latest osm2pgsql doesn't use a pre-defined list of tags to differentiate
between old-style and new-style MPs, it uses its list of tags that
denote an area.

The specific issue that brought this up is actually fixed by only bringing
tags onto the MP area where all outer members have the tag, but there's
still a more general question.

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

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013-09-23 Per discussione Peter Wendorff

Am 23.09.2013 11:59, schrieb Paul Norman:
 From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com]
 Subject: Re: [OSM-talk] osm2pgsql multipolygon parsing

 it has a different meaning. tags on a closed way are for the whole area
 inside the way, tags on a mp relation are for the area of the outer
 minus the inner ways.

 Unless the closed way is a member of a multipolygon relation with no other
 tags on the relation - then you'll have a resulting area with a hole. This
 is a very well established means of tagging areas with holes (~22% of
 type=multipolygon relations have no other tags).
It's well established, but it's less correct from a theoretical point of
view, and establishment is produced here by software that supports wrong
tagging - in the past.
You propose to leave it as it is, which means software should estimate
the meaning because often there are errors in the tagging, while I
proposed (and as far as I understand at least Martin supports that) not
to ignore these errors with the goal to teach mappers about what's
correct instead of teaching them what's correct enough for application X
(be it the default mapnik style and -pipeline).

 The issues raised originally in the ticket are best explored through
 examples

 The first case is a way with natural=water and a MP relation with no other
 tags. Both old osm2pgsql (0.82) and latest master version from git create an
 area with a hole with natural=water on the area. There are no suggestions of
 changing this.
Problem:
Let's say the multipolygon relation was tagged before as depth=shallow
(and someone wanted to mark parts of the water as not deep - e.g. not
deep enough for boats). Let's say another mapper came along and found
this strange tags and - removing them - accidently left a multipolygon
without tags. This changes the meaning of stuff never touched again, as
you would now count the natural=water only for the area covered by the
multipolygon, excluding the hole.

 The second is a way with natural=water and a MP relation with name=foo (with
 the way as a member). Old osm2pgsql created an area with a hole with
 natural=water, name=foo, latest master does too.
What if the inner part does NOT have that name, but only the outer ring?
What if that is what somebody wanted to say?

regards
Peter

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

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013-09-23 Per discussione Petr Morávek [Xificurk]

Dne 23.9.2013 11:59, Paul Norman napsal(a):
 Unless the closed way is a member of a multipolygon relation with no other
 tags on the relation - then you'll have a resulting area with a hole. This
 is a very well established means of tagging areas with holes (~22% of
 type=multipolygon relations have no other tags).

Yes, but if the relation has any[*] additional tags, you can't reliably
decide what was the intended purpose of this tagging. Imho the only
logical thing is to treat the relation and ways separately.
[*] Maybe some internal keys could be ignored, e.g. odbl, fixme, ...

 The issues raised originally in the ticket are best explored through
 examples
 
 The first case is a way with natural=water and a MP relation with no other
 tags. Both old osm2pgsql (0.82) and latest master version from git create an
 area with a hole with natural=water on the area. There are no suggestions of
 changing this.

Agreed.

 The second is a way with natural=water and a MP relation with name=foo (with
 the way as a member). Old osm2pgsql created an area with a hole with
 natural=water, name=foo, latest master does too.

Is this really correct?
In case of the name=foo it is probably safe assumption, but how about
multipolygon relation with only access=* tag (or something similar)? How
do you decide, if it means the area with holes is
natural=water+access=*, or that the whole area (with no holes) is
natural=water and only some parts have access=*?

 The fourth is a way with natural=water and a MP relation with foo=bar. In
 old osm2pgsql this created an area without a hole, in latest master it
 depends on the .style file used for import.

The dependence on on the .style file bothers me, I think it's a mistake
and will ultimately come back to haunt us. If you don't care about some
features and delete the lines from your .style file, the multipolygon
parsing should not change.

--

I propose that:
1) By default the relation and ways are treated separately
 - relation creates polygon with tags from the relation and ways are
processed on their own.
2) If and only if the relation has only type=multipolygon tag go to
backward compatibility mode. Copy over tags from outer ways that are
present on all of them and create polygon. Go over all member ways and
if all their tags are present on the created polygon, then mark them as
done, otherwise process them separately.

--

I have looked at all the multipolygon relations that do not have any of
the well-known polygon tags (the ones defined in default.style), this is
less than 27% of all the multipolygon relations. 85% of these relations
have type=multipolygon tag only, so the proposed change in fact affects
less than 4% of all the multipolygons.

More detailed breakdown of tags on multipolygons without well-known
polygon tags:
percentage  keys
85.5%   type
3.7%ref,type,id_ob,adr_les
1.7%type,name
1.5%area,type,highway


Best regards,
Petr Morávek aka Xificurk


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

Re: [OSM-talk] Who interprets semicolon in tag values?

2013-09-23 Per discussione Jochen Topf

On Fri, May 31, 2013 at 05:03:26PM +0200, Jochen Topf wrote:
 We have had an informal convention for a long time to use a semicolon
 (;) in tag values to separate multiple values, for instance
 ref=I 70; US 40 to denote that there are two numbered roads on a way.
 But most software out there doesn't actually interpret this in any
 special way.
 
 If you know of any software that actually does interpret this specially,
 please tell me. I am trying to get an idea where and how this is used in
 the real world. You can answer here on the list or write to me
 privately, I'll summarize for the list later. Thanks!

I finally wrote down what I found out about semicolons in tag values and what I
think about them. Turns out there isn't much software that interprets them and
where it does, only in special cases. Thanks to all who replied and sorry that
I haven't mentioned every case in my blog post.

http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013-09-23 Per discussione Peter Wendorff

Am 23.09.2013 15:20, schrieb Petr Morávek [Xificurk]:
 
 I propose that:
 1) By default the relation and ways are treated separately
  - relation creates polygon with tags from the relation and ways are
 processed on their own.
 2) If and only if the relation has only type=multipolygon tag go to
 backward compatibility mode. Copy over tags from outer ways that are
 present on all of them and create polygon. Go over all member ways and
 if all their tags are present on the created polygon, then mark them as
 done, otherwise process them separately.

+0.75 ;)

Agree, but I would use (2) if and only if backward compatibility mode
is active.
Additionally I would not use the backward compatibility mode for the
mapnik default sheet (after some time with big announcements an probably
a tool detecting/reporting possible problems for fixing).

With this we could
- enforce more correct tagging in future
- engage the mappers community to fix where the bad-style tagging is
used yet
- gracefully allow any other application to fall back to the old style
as long as they want to.

This might (!) degrade the perceived quality of the default mapnik layer
for some time (!), but IMHO it's worth it as it simplifies multipolygon
interpretation and on the long term teaches mappers to use the tagging
that is correct and matches that simplified interpretation.

regards
Peter

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

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013-09-23 Per discussione Yves

Sorry, I meant osm2pgsql is not used for the slippy map ONLY.
Thanks for all the feedback :)
Yves
-- 
Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013-09-23 Per discussione Petr Morávek [Xificurk]

Dne 23.9.2013 16:03, Peter Wendorff napsal(a):
 Am 23.09.2013 15:20, schrieb Petr Morávek [Xificurk]:

 I propose that:
 1) By default the relation and ways are treated separately
  - relation creates polygon with tags from the relation and ways are
 processed on their own.
 2) If and only if the relation has only type=multipolygon tag go to
 backward compatibility mode. Copy over tags from outer ways that are
 present on all of them and create polygon. Go over all member ways and
 if all their tags are present on the created polygon, then mark them as
 done, otherwise process them separately.
 
 +0.75 ;)
 
 Agree, but I would use (2) if and only if backward compatibility mode
 is active.
 Additionally I would not use the backward compatibility mode for the
 mapnik default sheet (after some time with big announcements an probably
 a tool detecting/reporting possible problems for fixing).
 
 With this we could
 - enforce more correct tagging in future
 - engage the mappers community to fix where the bad-style tagging is
 used yet
 - gracefully allow any other application to fall back to the old style
 as long as they want to.
 
 This might (!) degrade the perceived quality of the default mapnik layer
 for some time (!), but IMHO it's worth it as it simplifies multipolygon
 interpretation and on the long term teaches mappers to use the tagging
 that is correct and matches that simplified interpretation.
 
 regards
 Peter

This is probably a good idea in the long-run, but there are things that
need to be done before this cut-off and all of them need a certain
transitional period.
1) You need to edit wiki and make people aware that this tagging scheme
is considered deprecated.
2) You need to make sure, that all the editors produce correct
multipolygon relations.
3) Fix the deprecated tagging on most of the elements.

I really don't think it's a good idea to suddenly stop rendering quarter
of the multipolygons out there just to enforce some thought-out
policy... I don't see who would benefit from this.


Anyway, this thread was not started to debate tagging schemes, the
question I (and others) wanted to discuss here is this:
Given the data that are currently in the database, how should osm2pgsql
handle the import to get as much as possible multipolygons right?


Best regards,
Petr Morávek aka Xificurk

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

Re: [OSM-talk] osm2pgsql multipolygon parsing

2013-09-23 Per discussione Kai Krueger

quot;Petr Morávek [Xificurk]quot;-2 wrote
 Anyway, this thread was not started to debate tagging schemes, the
 question I (and others) wanted to discuss here is this:
 Given the data that are currently in the database, how should osm2pgsql
 handle the import to get as much as possible multipolygons right?

Indirectly it is a question of tagging schemas. With osm2pgsql being the
tool used in the default map rendering on osm.org and the prevalence of
tagging for the renderer decisions on how it handles multipolygons will
(and imho to a limited degree should) influence how people tag and what they
perceive as correct tagging. Therefore it is important that there is a
consensus of what the correct tagging schema is and make sure that is
correctly supported by osm2pgsql. That is also why I think having this
discussion on talk, rather than on github or the dev list is appropriate.

We need to come to a consensus between all of the main tools (at least iD,
P2, JOSM, osm2pgsql, osrm, ...) and the mappers to what the preferred,
encouraged and supported standard for tagging multi-polygons is and make
sure that all documentation is in line with this.

 



--
View this message in context: 
http://gis.19327.n5.nabble.com/osm2pgsql-multipolygon-parsing-tp5778300p5778654.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

Re: [OSM-talk] Who interprets semicolon in tag values?

2013-09-23 Per discussione Paul Norman

 From: Jochen Topf [mailto:joc...@remote.org]
 Sent: Monday, September 23, 2013 6:51 AM
 To: talk@openstreetmap.org
 Subject: Re: [OSM-talk] Who interprets semicolon in tag values?

 I finally wrote down what I found out about semicolons in tag values and
 what I think about them. Turns out there isn't much software that
 interprets them and where it does, only in special cases. Thanks to all
 who replied and sorry that I haven't mentioned every case in my blog
 post.

 http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html

It's worth noting that when two objects are merged in iD it splits the 
tag's value into lists at semicolons, merges the lists from the two objects,

and then turns the resulting list into a semicolon separated list. See 
https://github.com/systemed/iD/issues/943. I believe iD is actually the 
only editor that attempts to support semicolon lists in tags. JOSM and 
P2 emit them, but don't interpret them.

This of course doesn't avoid contradictory tags like tiger:separated=yes;no 
but it at least avoids tiger:separated=yes;no;no;no;yes;no;yes;...

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

Re: [OSM-talk] Who interprets semicolon in tag values?

2013-09-23 Per discussione Jochen Topf

On Mon, Sep 23, 2013 at 01:44:23PM -0700, Paul Norman wrote:
  From: Jochen Topf [mailto:joc...@remote.org]
  Sent: Monday, September 23, 2013 6:51 AM
  To: talk@openstreetmap.org
  Subject: Re: [OSM-talk] Who interprets semicolon in tag values?

  I finally wrote down what I found out about semicolons in tag values and
  what I think about them. Turns out there isn't much software that
  interprets them and where it does, only in special cases. Thanks to all
  who replied and sorry that I haven't mentioned every case in my blog
  post.

  http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html

 It's worth noting that when two objects are merged in iD it splits the 
 tag's value into lists at semicolons, merges the lists from the two objects,

 and then turns the resulting list into a semicolon separated list. See 
 https://github.com/systemed/iD/issues/943. I believe iD is actually the 
 only editor that attempts to support semicolon lists in tags. JOSM and 
 P2 emit them, but don't interpret them.

 This of course doesn't avoid contradictory tags like tiger:separated=yes;no 
 but it at least avoids tiger:separated=yes;no;no;no;yes;no;yes;...

This would be better if semicolons always indicated sets of values, which,
as I describe in my blog post, is the wrong assumption. For 'ref' tags this
is probably the right behaviour, for about anything else it is wrong.

IMHO editors should either do something clever, if they know the specific
tag and how it is used, or fall back to forcing the user to make a decision.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-721-388298

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

[talk-au] New data sets - City of Gold Coast

2013-09-23 Per discussione Daniel O'Connor

Hey folks,
Just spotted a few updated/new data sets for
http://data.gov.au/organization/city-of-gold-coast

Included are:
Fitness Stations
The layer refers to a symbol indicating the location of Fitness Stations on
public land adjacent to waterways in the Gold Coast area.

Fences on Public Land
The layer refers to lines and symbols indicating the location of various
types of Fences (Bollards, Perimeter Fences, Barrier Fences, etc.) on
public land in the Gold Coast area.

Drinking Fountain
The layer refers to a symbol indicating the location of Drink Fountains on
public land in the Gold Coast area.

Cleaning Sinks
The layer refers to a symbol indicating the location of Cleaning Sinks (for
cleaning fish) on public land in the Gold Coast area.

Buildings
The layer refers to a polygon indicating the location of various types of
Buildings (Amenities Blocks, Kiosks, Sheds, etc.) on public land in the
Gold Coast area.

Boat Ramps
The layer refers to a polygon indicating the location of Boat Ramps on
public land in the Gold Coast area.

Bike Racks
The layer refers to a symbol indicating the location of Bike Racks on
public land in the Gold Coast area.

Public Barbeques
The layer refers to a symbol indicating the location of Barbeques on public
land in the Gold Coast area.


Most seems to be shapefiles, and given
http://wiki.openstreetmap.org/wiki/Attribution/data.gov.au_explicit_permission
there
should be one less barrier to importing/making use of the data sets.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-br] Comportamento suspeito de Moovit

2013-09-23 Per discussione Martin Weilandt

 Date: Sun, 22 Sep 2013 17:42:49 -0300
 From: Gerald Weber gwebe...@gmail.com
 Pelo que entendi há 2 assuntos distintos aqui.

 1) o serviço Moovit http://www.moovitapp.com/ fazendo uso dos mapas do OSM
 sem atribuição, aparentemente inclusive usando o tile server

Dá para sabermos se eles usam o servidor do OSM? Pelo menos no código-fonte do 
site não vi nenhum link para OSM.

 2) um usuário chamado Moovit Team, provavelmente associado ao serviço
 moovit, fazendo mapeamendo ao redor do mundo, aparentemente pegando coisas
 do Google

 acho que os dois caso tem que ser tratados separadamente.
[...]

A resposta que recebi hoje referente ao problema 2 indica que os responsáveis 
nessa empresa não sabem (ou fingem que não sabem) o que são direitos autorais - 
o que também pode ter causado problema 1. Pedi para eles entrarem em contato 
com o Data Working Group (ou conosco pela lista) e mencionei o IBGE (ou as 
prefeituras que já coloboram com eles) como alternativa. Já aviso que recomendo 
não trabalhar com dados colocados pelo usuário Moovit Team (como em Fortaleza, 
Bauru ou Itajaí). Vou esperar a reação deles (ou avisar o DWG se necessário) e 
dar mais informações para vocês em breve.
(Não gosto de citar mensagens que foram só para mim numa lista aberta. Mas se 
tiver alguém particularmente interessado em analisar esse problema, posso 
encaminhar todo o material para ele.)

Martin

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

[Talk-br] Fwd: Comportamento suspeito de Moovit

2013-09-23 Per discussione Marcos Pereira

Bom dia!
Em meu modesto entendimento, se Movit Team é um nome genérico que se
repete várias vezes, sem um responsável, que utiliza sistematicamente
métodos de mapeamento e fontes incompatíveis com os termos  do
Openstreetmap, notadamente para fins particulares (aparentemente
evidenciado pelo aplicativo google e mac que oferecem - é preciso verificar
os aplicativos), com certeza este deve ser notificado.  E reincidindo, deve
ser bloqueado. Isso pode comprometer a seriedade e qualidade do projeto
Openstreetmap.
É apenas um ponto de vista que tenho.

Marcos Pereira
http://lattes.cnpq.br/7286163637647707
http://www.facebook.com/MarcosAntonioDeJesusPereira24649184827



-- Mensagem encaminhada --
De: Martin Weilandt martin...@gmx.net
Data: 23 de setembro de 2013 11:01
Assunto: Re: [Talk-br] Comportamento suspeito de Moovit
Para: talk-br@openstreetmap.org


 Date: Sun, 22 Sep 2013 17:42:49 -0300
 From: Gerald Weber gwebe...@gmail.com
 Pelo que entendi há 2 assuntos distintos aqui.

 1) o serviço Moovit http://www.moovitapp.com/ fazendo uso dos mapas do OSM
 sem atribuição, aparentemente inclusive usando o tile server

Dá para sabermos se eles usam o servidor do OSM? Pelo menos no código-fonte
do site não vi nenhum link para OSM.

 2) um usuário chamado Moovit Team, provavelmente associado ao serviço
 moovit, fazendo mapeamendo ao redor do mundo, aparentemente pegando coisas
 do Google

 acho que os dois caso tem que ser tratados separadamente.
[...]

A resposta que recebi hoje referente ao problema 2 indica que os
responsáveis nessa empresa não sabem (ou fingem que não sabem) o que são
direitos autorais - o que também pode ter causado problema 1. Pedi para
eles entrarem em contato com o Data Working Group (ou conosco pela lista) e
mencionei o IBGE (ou as prefeituras que já coloboram com eles) como
alternativa. Já aviso que recomendo não trabalhar com dados colocados pelo
usuário Moovit Team (como em Fortaleza, Bauru ou Itajaí). Vou esperar a
reação deles (ou avisar o DWG se necessário) e dar mais informações para
vocês em breve.
(Não gosto de citar mensagens que foram só para mim numa lista aberta. Mas
se tiver alguém particularmente interessado em analisar esse problema,
posso encaminhar todo o material para ele.)

Martin

___
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] Comportamento suspeito de Moovit

2013-09-23 Per discussione Cassio Eskelsen

O tile server é do OSM mesmo (um tile pego lá:
http://b.tile.osm.org/14/4823/6155.png  )

Cássio Rogério Eskelsen
3Geo


2013/9/23 Martin Weilandt martin...@gmx.net

  Date: Sun, 22 Sep 2013 17:42:49 -0300
  From: Gerald Weber gwebe...@gmail.com
  Pelo que entendi há 2 assuntos distintos aqui.
 
  1) o serviço Moovit http://www.moovitapp.com/ fazendo uso dos mapas do
 OSM
  sem atribuição, aparentemente inclusive usando o tile server

 Dá para sabermos se eles usam o servidor do OSM? Pelo menos no
 código-fonte do site não vi nenhum link para OSM.

  2) um usuário chamado Moovit Team, provavelmente associado ao serviço
  moovit, fazendo mapeamendo ao redor do mundo, aparentemente pegando
 coisas
  do Google
 
  acho que os dois caso tem que ser tratados separadamente.
 [...]

 A resposta que recebi hoje referente ao problema 2 indica que os
 responsáveis nessa empresa não sabem (ou fingem que não sabem) o que são
 direitos autorais - o que também pode ter causado problema 1. Pedi para
 eles entrarem em contato com o Data Working Group (ou conosco pela lista) e
 mencionei o IBGE (ou as prefeituras que já coloboram com eles) como
 alternativa. Já aviso que recomendo não trabalhar com dados colocados pelo
 usuário Moovit Team (como em Fortaleza, Bauru ou Itajaí). Vou esperar a
 reação deles (ou avisar o DWG se necessário) e dar mais informações para
 vocês em breve.
 (Não gosto de citar mensagens que foram só para mim numa lista aberta. Mas
 se tiver alguém particularmente interessado em analisar esse problema,
 posso encaminhar todo o material para ele.)

 Martin

 ___
 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-de] Gebäude in Nodes umwandeln für Exportzwecke

2013-09-23 Per discussione pmsg

Hallo Liste!

Mit der Overpass API und Overpass Turbo kann ich eine GPX-Datei mit allen
Hotels in einem bestimmten (großen) Bereich exportieren und auf mein
Smartphone kopieren. Für Hotels die als Nodes gemappt sind, kann ich die
GPX-Datei direkt verwenden:
query type=node
  has-kv k=tourism v=hotel/
  bbox-query {{bbox}}/
/query
print/


Viele Hotels sind aber als Flächen gemappt.

Wie kann ich diese mit in die GPX-Datei kriegen? Ich möchte nur Waypoints
haben, keine Umrisse der Hotels. Ich kann eine Overpass-Abfrage machen, um
die Punkte und Wege der Hotelumrisse zu generieren. Gibt es ein Tool, mit
dem ich automatisch die Mittelpunkte der Flächen berechnen kann, und diesen
Mittelpunkt-Nodes mit den Tags von der Fläche zu versehen?

Vielen Dank und Grüße,
pmsg
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zensur in OSM?

2013-09-23 Per discussione Jimmy_K


Am 21.09.2013 20:54, schrieb Martin Koppenhoefer:

Was die Nummernschilder angeht habe ich mich besonnen, zusammen mit 
dem Ortsbezug ist das hinsichtlich Datenschutz vielleicht wirklich 
kritisch. 



Die große rechtliche Frage wird sein, ist das überhaupt ein Nummernschild?
Es wäre dann ein Nummernschild, wenn man den Platz so taggen würde, weil 
dort das Fahrzeug mit den Nummernschild XY Parkt. Wenn man aber einfach 
die Buchstaben/Zahlenkombination, welche auf einem Holzschild steht 
eintragt, frage ich mich ob hier auch der Datenschutz greifen würde.


LG Jimmy


PS: Wenngleich ich auch wenig Sinn sehe, das in OSM einzutragen.

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

Re: [Talk-de] Zensur in OSM?

2013-09-23 Per discussione Jörg Frings-Fürst

Am Samstag, den 21.09.2013, 08:40 +0200 schrieb Jörg Frings-Fürst:

ich denke mal ich muss jetzt doch noch einmal antworten:

Zuerst einmal warum waren die KFz-Kennzeichen getagget:

http://gis.19327.n5.nabble.com/Bundestagswahl-2013-Wahlkreise-in-OSM-tp5774101p5778218.html

Und wie man aus den Changesets sehen kann habe ich das so getaggt das
die Tags unter Nominatim nicht mehr zu finden waren.

Am Samstag, den 21.09.2013, 13:47 -0700 schrieb Walter Nordmann:
[...]
Sorry, aber das ist - für mich - totaler Quatsch mit Soße.
[...]

Und für mich ist es absoluter unverständlich das ich jetzt wenn ich
durch Bonn fahre anstatt der Straßennamen Stimmbezirk XYZ sehe. Ich
habe mir aber nicht angemaßt die Stimmbezirke zu löschen.

Am Samstag, den 21.09.2013, 04:35 -0700 schrieb Walter Nordmann:
[...]
Darauf habe ich angekündigt, dass ich hier am Abend etwas aufräumen werde
(Datenschutz).
[...]

Auch ich habe ein RL außerhalb von OSM und erlaube mir durchaus mal ohne
Computer durchs Leben zu gehen.

Am Samstag, den 21.09.2013, 23:53 +0200 schrieb Frederik Ramm:
[...]
Dabei geht es dann natuerlich nicht um Datenschutz, sondern um
unerwuenschte Werbung - der betreffende *will* ja meistens seinen
Firmennamen (und am liebsten noch eine Beschreibung seines
Dienstleistungsangebots) auf der Karte sehen, und wir wollen es nicht.
[...]
Das ist natürlich ein Argument das ich sofort akzeptiere. Ok, es war ein
Fehler von mir. Es heißt ja: Aus Fehlern kann man ja nur lernen.
Nur muss man die zum lernen auch kennen. IMHO wäre es besser gewesen
mich über meinen Fehler zu informieren anstatt einfach zu ändern.
Da die Regel ja nicht nur für mich gilt wäre es doch eine schöne Monats-
aufgabe alle Firmen so umzutaggen das sie nicht mehr auf der Karte
erscheinen.

So jetzt noch persönliche Anmerkungen:

- Stellplätze: Ich empfinde es extrem ungemeinschaftlich bei 4 nicht
passenden name-Tags die geometrisch richtig eingetragenen Plätze
komplett zu löschen und falsch neu einzutragen. Das zurücksetzen
der entsprechenden Changesets oder das löschen der tags hätte
durchaus gereicht und wären in der Historie nachverfolgbar.

Bis dato habe ich OSM als Gemeinschaftsprojekt verstanden. Vielleicht
bin ich ja schon zu alt, zumindest achte ich die Arbeit der Anderen.
Ich schon einige mal Stellen gehabt die meiner Meinung nach falsch,
unrichtig oder sonst wie nicht meinen Vorstellungen entsprachen. Trotzdem
wurden die nicht einfach gelöscht sondern mit der entsprechenden Person
diskutiert. Und wenn es keinen gemeinsamen Nenner gab wurde auch nichts
geändert.

Aber [Zitat]aber das ist - für mich - totaler Quatsch mit Soße.[/Zitat]
sagt ja wohl alles.

Gruß

Jörg

--
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org

signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gebäude in Nodes umwandeln für Exportzwecke

2013-09-23 Per discussione Alberto Nogaro

-Original Message-
From: pmsg [mailto:pmsg2...@yahoo.com]
Sent: lunedì 23 settembre 2013 09:11
To: talk-de@openstreetmap.org
Subject: [Talk-de] Gebäude in Nodes umwandeln für Exportzwecke

Gibt es ein Tool,
mit dem ich automatisch die Mittelpunkte der Flächen berechnen kann, und
diesen Mittelpunkt-Nodes mit den Tags von der Fläche zu versehen?

Probier mal osmconvert, spezialfunktion --all-to-nodes.

Mit herzlichem Gruss,
Alberto

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

Re: [Talk-de] Eisenbahnen in Korea

2013-09-23 Per discussione Alexander Matheisen

Hallo,

 ich habe umfangreiche Daten zum Bahnnetz in Nord-Korea, Asien und Japan 
 bekommen, mit Stationen und Strecken-Kilometern.
 
 Wem kann ich das per PM schicken?
 Vielleicht ist ja Brauchbares dabei...

das klingt interessant, vor allem für die OpenRailwayMap.

Kannst mir die Daten gerne mal zuschicken. Ist denn geklärt, unter
welcher Lizenz die stehen und ob sie für OSM verwendet werden dürfen?


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Zensur in OSM?

2013-09-23 Per discussione Jörg Frings-Fürst

Am Montag, den 23.09.2013, 12:31 +0200 schrieb Jörg Frings-Fürst:
 Am Samstag, den 21.09.2013, 08:40 +0200 schrieb Jörg Frings-Fürst:
 
[...]
 - Stellplätze: Ich empfinde es extrem ungemeinschaftlich bei 4 nicht 
 passenden name-Tags die geometrisch richtig eingetragenen Plätze 
 komplett zu löschen und falsch neu einzutragen. Das zurücksetzen 
 der entsprechenden Changesets oder das löschen der tags hätte 
 durchaus gereicht und wären in der Historie nachverfolgbar.

Sorry, 

heute morgen wurde mir unter JOSM keine Historie angezeigt. Ich bin
daher davon ausgegangen das alles gelöscht und neu angelegt wurde.

[...]


Jörg

-- 
Jörg Frings-Fürst
OSM privat
D-54526 Landscheid
GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A
Full GPG key: hkp://pool.sks-keyservers.net
CAcert Serialnr.: 0D:9A:23
SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E
http://cacert.org



signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gebäude in Nodes umwandeln für Exportzwecke

2013-09-23 Per discussione pmsg

Hallo Alberto,

yes, das funktioniert! Vielen Dank!
So werden neue Nodes mit allen Tags der geschlossenen Wegen ausgegeben,
genau wie ich wollte. Die ursprünglichen Nodes der Gebäuden bleiben jedoch
nach osmconvert. Da diese i.d.R. keine Tags haben, konnte ich sie mit
osmfilter --keep-nodes=*
entfernen.
Viele Grüsse, pmsg


2013/9/23 Alberto Nogaro bartosom...@yahoo.it

 -Original Message-
 From: pmsg [mailto:pmsg2...@yahoo.com]
 Sent: lunedì 23 settembre 2013 09:11
 To: talk-de@openstreetmap.org
 Subject: [Talk-de] Gebäude in Nodes umwandeln für Exportzwecke
 
 Gibt es ein Tool,
 mit dem ich automatisch die Mittelpunkte der Flächen berechnen kann, und
 diesen Mittelpunkt-Nodes mit den Tags von der Fläche zu versehen?

 Probier mal osmconvert, spezialfunktion --all-to-nodes.

 Mit herzlichem Gruss,
 Alberto


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

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

Re: [Talk-de] User Donanob schliesst willkuerlich notes

On Mon, Sep 23, 2013 at 06:58:52PM +0200, Franz-Josef Rüther wrote:
 Also mein note ist nach Fehlerbereinigung durch andere von ihr/ihm
 (Donanob) richtigerweise geschlossen worden.
 Weitere Einzelheiten über den Hinweis findest du unter
 http://www.openstreetmap.org/browse/note/45048.

Ich habe nachdem hier der mailer angefangen hat rumzupingen
exemplarisch 3-5 Bugs angesehen und bei keinem war was passiert.

Und ohne Kommentar schliessen und das in den Massen finde ich
absolut daneben.

Jetzt muss ich die alle mit JOSM wieder auchmachen und reativaten? 

*grmpf*

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] User donanbo schliesst willkuerlich notes

2013-09-23 Per discussione chris66

Am 23.09.2013 18:43, schrieb Florian Lohoff:

 der user Donanbo schliesst gerade MASSENHAFT Notes ohne kommentar und
 das etwas gefixed worden ist.

Jepp, kann ich bestätigen. :-(



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

[Talk-de] Drohung an Mapper

2013-09-23 Per discussione Max

Interessante Entdeckung:
eine Drohung an Mapper (an einer Mauer des Camp George in Daegu, Südkorea).

Das Schild list sich so:

WARNING
RESTRICTED AREA

This installation has been declared a restricted area by authority of the 
Installation Commander in accordance with the provisions of the directive 
issued by the Secretary of Defense on 20th August 1954, pursuant to the 
provisions of Section 21, Internal Security Act of 1950. Unauthorized entry is 
prohibited. All persons and vehicles entering herin are liable to 
dearch.Photographing or making notes drawings, maps, or graphic representations 
of this area or its activities are prohibited unless specifically authorized by 
the commander. Any such material found in the posession of unauthorized persons 
will be confiscated.

(Darunter das gleiche noch mal auf Koreanisch   )


Auf Google Maps und Naver Maps sind die Basen der US Armee nicht eingezeichnet. 
Auf Bing sind sogar Straßen und ein nicht existenter Starbucks eingezeichnet, 
die Wohl die Zensur tarnen sollen. Dafür in OSM, (dessen Datenbestand in 
Südkorea ansonsten ausgesprochen dünn ist).
http://sautter.com/map/?zoom=15lat=35.84263lon=128.59865layers=B000TTTF







signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] User donanbo schliesst willkuerlich notes

2013-09-23 Per discussione Frank


Am 23.09.2013 19:09, schrieb chris66:

Am 23.09.2013 18:43, schrieb Florian Lohoff:


der user Donanbo schliesst gerade MASSENHAFT Notes ohne kommentar und
das etwas gefixed worden ist.


Jepp, kann ich bestätigen. :-(



Drei von meinen Einträgen hat er auch eben geschlossen, immer ohne 
Kommentar.


In einem Fall war es korrekt, da hatte jemand anders den Eintrag 
gemacht, ohne den Note zu schließen.


Ein Note war halb gelöst, es ging aber nicht recht weiter damit.

Der Dritte war noch unbearbeitet, aber nicht wirklich ein Fehler sondern 
eher ein Merker für ein noch fehlendes Gebäude.


http://www.openstreetmap.org/user/wwwFrank/notes

--

Frank

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

Re: [Talk-de] Drohung an Mapper

2013-09-23 Per discussione Florian Schäfer

Hier ein Beispiel gerademal 1km vom Europapark bei Freiburg weg:
http://www.panoramio.com/photo/43124880
http://osm.org/go/0DJuhrMG?m=

Am 23.09.2013 20:02, schrieb Alexander Matheisen:
 Am Dienstag, den 24.09.2013, 02:22 +0900 schrieb Max:
 Interessante Entdeckung:
 eine Drohung an Mapper (an einer Mauer des Camp George in Daegu, Südkorea).

 Das Schild list sich so:

 WARNING
 RESTRICTED AREA

 This installation has been declared a restricted area by authority of the 
 Installation Commander in accordance with the provisions of the directive 
 issued by the Secretary of Defense on 20th August 1954, pursuant to the 
 provisions of Section 21, Internal Security Act of 1950. Unauthorized entry 
 is prohibited. All persons and vehicles entering herin are liable to 
 dearch.Photographing or making notes drawings, maps, or graphic 
 representations of this area or its activities are prohibited unless 
 specifically authorized by the commander. Any such material found in the 
 posession of unauthorized persons will be confiscated.

 (Darunter das gleiche noch mal auf Koreanisch)
 Solche Schilder findet man aber auch an US-Einrichtungen in Deutschland.
 Finde aber gerade leider kein Beispielbild (kein Wunder bei einem
 Schild, das das Fotografieren verbietet...)


 Gruß
 Alex


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

Re: [Talk-de] User Donanob schliesst willkuerlich notes

2013-09-23 Per discussione Franz-Josef Rüther


Am 23.09.2013 18:50, schrieb Florian Lohoff:

On Mon, Sep 23, 2013 at 06:43:05PM +0200, Florian Lohoff wrote:

Hi,

der user Donanbo schliesst gerade MASSENHAFT Notes ohne kommentar und

Also mein note ist nach Fehlerbereinigung durch andere von ihr/ihm 
(Donanob) richtigerweise geschlossen worden.
Weitere Einzelheiten über den Hinweis findest du unter 
http://www.openstreetmap.org/browse/note/45048.


Gruß
 -Franz-


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

Re: [Talk-de] Drohung an Mapper

2013-09-23 Per discussione Alexander Matheisen

Am Dienstag, den 24.09.2013, 02:22 +0900 schrieb Max:
 Interessante Entdeckung:
 eine Drohung an Mapper (an einer Mauer des Camp George in Daegu, Südkorea).
 
 Das Schild list sich so:
 
 WARNING
 RESTRICTED AREA
 
 This installation has been declared a restricted area by authority of the 
 Installation Commander in accordance with the provisions of the directive 
 issued by the Secretary of Defense on 20th August 1954, pursuant to the 
 provisions of Section 21, Internal Security Act of 1950. Unauthorized entry 
 is prohibited. All persons and vehicles entering herin are liable to 
 dearch.Photographing or making notes drawings, maps, or graphic 
 representations of this area or its activities are prohibited unless 
 specifically authorized by the commander. Any such material found in the 
 posession of unauthorized persons will be confiscated.
 
 (Darunter das gleiche noch mal auf Koreanisch )

Solche Schilder findet man aber auch an US-Einrichtungen in Deutschland.
Finde aber gerade leider kein Beispielbild (kein Wunder bei einem
Schild, das das Fotografieren verbietet...)


Gruß
Alex


signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] User donanbo schliesst willkuerlich notes


Hi,

der user Donanbo schliesst gerade MASSENHAFT Notes ohne kommentar und
das etwas gefixed worden ist.

Ich habe alleine in den letzten 5 Minuten ~20 Messages bekommen ueber
geschlossene Notes.

Das ganze sieht nach wildgewordenem Bot aus.

Habe den User bereits angeschrieben.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Drohung an Mapper

2013-09-23 Per discussione Sven Geggus

Alexander Matheisen alexandermathei...@ish.de wrote:

 Finde aber gerade leider kein Beispielbild (kein Wunder bei einem
 Schild, das das Fotografieren verbietet...)

Fotografieren von öffentlichen Grund aus ohne zusätzliche Hilfsmittel ist in
Deutschland erlaubt.

Schilder, die dieses Recht einschränken wollen sind wirkungslos.

Es gibt da so nen Aktionskünstler aus Berlin, der das bei allen Möglichen
Botschaften usw. probiert hat. Er wurde mehrmals vond er Polizei befragt
musste aber immer wieder freigelassen werden, weil er gegen kein Gesetz
verstoßen hat.

Anders sieht das natürlich bei Privatgrund aus. Da hat man Hausrecht und
kann natürlich jeden rauswerfen, der fotografiert.

Gruss

Sven

-- 
Kernel panic: I have no root and I want to scream
(Linux Kernel Error Message)

/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: [Talk-de] Drohung an Mapper

Am 23. September 2013 21:42 schrieb Sven Geggus li...@fuchsschwanzdomain.de
:

 Schilder, die dieses Recht einschränken wollen sind wirkungslos.

 Es gibt da so nen Aktionskünstler aus Berlin, der das bei allen Möglichen
 Botschaften usw. probiert hat. Er wurde mehrmals vond er Polizei befragt
 musste aber immer wieder freigelassen werden, weil er gegen kein Gesetz
 verstoßen hat.




Militärische Einrichtungen sind da AFAIK allerdings ausgeschlossen,
Botschaften sind halt kein militärisches Gebiet, genausowenig übrigens wie
der BND (der ist eine Behörde des Kanzleramts) und von daher können die
sich da auch nicht (AFAIK, IANAL) auf das Verbot des Abbildens
militärischer Einrichtungen berufen.

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

Re: [Talk-de] Drohung an Mapper

2013-09-23 Per discussione Falk Zscheile

Am 23. September 2013 21:53 schrieb Martin Koppenhoefer 
dieterdre...@gmail.com:

 Am 23. September 2013 21:42 schrieb Sven Geggus 
 li...@fuchsschwanzdomain.de
 :

  Schilder, die dieses Recht einschränken wollen sind wirkungslos.
 
  Es gibt da so nen Aktionskünstler aus Berlin, der das bei allen Möglichen
  Botschaften usw. probiert hat. Er wurde mehrmals vond er Polizei befragt
  musste aber immer wieder freigelassen werden, weil er gegen kein Gesetz
  verstoßen hat.
 



 Militärische Einrichtungen sind da AFAIK allerdings ausgeschlossen,
 Botschaften sind halt kein militärisches Gebiet, genausowenig übrigens wie
 der BND (der ist eine Behörde des Kanzleramts) und von daher können die
 sich da auch nicht (AFAIK, IANAL) auf das Verbot des Abbildens
 militärischer Einrichtungen berufen.

 Zur Ergänzung die Normen für militärischen Anlagen:

Schutzbereichsgesetz: http://www.gesetze-im-internet.de/schberg/__27.html
Strafgesetzbuch: http://www.gesetze-im-internet.de/stgb/__109g.html

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

Re: [Talk-de] Drohung an Mapper

On Tue, Sep 24, 2013 at 02:22:07AM +0900, Max wrote:
 Interessante Entdeckung:
 eine Drohung an Mapper (an einer Mauer des Camp George in Daegu, Südkorea).

Immer mal fleissig mappen - Am besten non-locals :) Wenn wir das von
oeffentlich zugänglichen Luftbildern koennen sind solche Verbote
quasi Lächerlich.

Hier in Gütersloh gibt es auch eine Militäranlage der Briten -
Princess-Royal-Baracks - Grosser Militärflughafen. Soll an den Bund
2014 Zurückgegeben werden - trotzdem ist da Stand heute
Fotografieverbot, selbst auf Fahrten über das Gelände für Politisch
interessierte am Konversionsprozess.

Luftbilder sind natürlich exzellent und vorhanden d.h. es ist alles
gemapped. Das einzige was vielleicht fehlt sind Gebäudebezeichnungen.

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Drohung an Mapper

On Mon, Sep 23, 2013 at 10:05:34PM +0200, Falk Zscheile wrote:
  Zur Ergänzung die Normen für militärischen Anlagen:
 
 Schutzbereichsgesetz: http://www.gesetze-im-internet.de/schberg/__27.html
 Strafgesetzbuch: http://www.gesetze-im-internet.de/stgb/__109g.html

zu 2) bezieht sich ja nur auf Bundesdeutsche Militäranlagen - Wenn ich in
Korea mappe dann betrifft mich das nicht (Sollte nur nicht nach Korea
reisen).

Ausserdem muss ich wissentlich zur Gefährdung der Bundesrepublik
beitragen. Das wird schwierig zu Konstruieren wenn ich oeffentlich 
zugängliche Sat/Luftbilder benutze.

zu 1) Ich bin gespannt wie jemand GeoEye einzieht :)

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] User Donanob schliesst willkuerlich notes

On Mon, Sep 23, 2013 at 06:43:05PM +0200, Florian Lohoff wrote:
 
 Hi,
 
 der user Donanbo schliesst gerade MASSENHAFT Notes ohne kommentar und

Donanob

Entschuldigung...

 das etwas gefixed worden ist.
 
 Ich habe alleine in den letzten 5 Minuten ~20 Messages bekommen ueber
 geschlossene Notes.
 
 Das ganze sieht nach wildgewordenem Bot aus.
 
 Habe den User bereits angeschrieben.

0 Edits, 0 Traces, 0 Diary.

Aber wie ein weltmeister Notes schliessen.

http://www.openstreetmap.org/browse/note/36678
http://www.openstreetmap.org/browse/note/4830
http://www.openstreetmap.org/browse/note/12314
http://www.openstreetmap.org/browse/note/30406
http://www.openstreetmap.org/browse/note/32344
http://www.openstreetmap.org/browse/note/28278

Flo
-- 
Florian Lohoff f...@zz.de


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

Re: [Talk-de] Drohung an Mapper

Am 23. September 2013 22:18 schrieb Florian Lohoff f...@zz.de:

 zu 2) bezieht sich ja nur auf Bundesdeutsche Militäranlagen - Wenn ich in
 Korea mappe dann betrifft mich das nicht (Sollte nur nicht nach Korea
 reisen).



ja, wobei (1) interessanter ist, sieh mal hier z.B.: Bei Beseitigung oder
Räumung von Wohnungen ist den Bewohnern eine angemessene Räumungsfrist zu
gewähren. Die ausreichende anderweitige Unterbringung muß gesichert sein.
es könnten Deine Grundrechte (hier Eigentum) noch weit mehr eingeschränkt
werden, als dass Du nur nicht mappen darfst ;-)

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

Re: [Talk-it] Casere ruderi

 Cosi a pelle però direi che riguarda qualcosa di rilevanza storica, tipo le
 rovine di palazzi romani, ecc.

 Una casera abbandonata e perciò col tempo è crollata non la definirei una
 rovina storica... anche perchè altrimenti collapsed a che serve.


Quest'affermazione non mi sembra sempre corretta. In montagna tante malghe
e simili sono veramente stabilimenti antichi. Perciò historic può essere
una descrizione precisa  per una malga in rovine che è stato lì da tanto
tempo e serve come riferimento geografico locale.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Sentiero CAI dismesso

Parliamo di sentieri esistenti ma no più mantenuti. Diventa così un
sentiero normale senza segnaletica, ma con tutti gli attributi normali di
un sentiero. Quindi *non* è disused o abandonded. Solo la numerazione è
obsoleta.

Se era una volta un sentiero con un numero e in particolare se era
descritto in guide sarei inclinato a lasciare la relazione col vecchio
numero ma con un tag che lo dichiara declassato. Ma non saprei dire quale
tag viene usato.
Non utilizzerei old_ref perché questo per mi implica che c'è un nuovo
riferimento diverso, che non c'è.

Forse sarebbe caso di verificare che non c'è stato una discussione sulla
lista tedesca. Sono convinto che qualcuno ha già affrontato il problema.




2013/9/22 Martin Koppenhoefer dieterdre...@gmail.com



  Am 22/set/2013 um 19:51 schrieb bredy bredy...@yahoo.it:
 
  i sentieri di cui ti parlo però sono ancora conosciuti e segnalati in
 varie
  guide e la gente che li frequenta continua ad attribuirgli lo stesso
  riferimento


 appunto, abandoned

 ciao,
 Martin


 ___
 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] Colle montano

vedi: https://it.wikipedia.org/wiki/Colle

colle ha due significati diversi in italiano che richiedono due tags
diversi

colle come  collina  corrisponde all'inglese hill
colle come passo corrisponde a col in francese o mountain pas in inglese




2013/9/22 Alessandro Rubini rubini-l...@gnudd.com

  Ce dite di place=hill, oppure natural=hill?

 Non si parla di colline. Il termine colle in ceri casi indica un
 passo, come gia` detto esplicitamente in lista.

 Per esempio conosco il colle di san zeno, che e` il passo tra la val
 camonica (pisogne) e la val trompia (pezzaze) e il colle di san
 fermo, tra la val camonica (sarnico) e la val cavallina (borgo di
 terzo). In questi casi passa la strada, ma altri gia` hanno notato
 che a volte non c'e` strada o sentiero.


 ___
 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] Sentiero CAI dismesso



 Am 23/set/2013 um 09:02 schrieb Volker Schmidt vosc...@gmail.com:
 
 Quindi non è disused o abandonded. Solo la numerazione è obsoleta.


certo, se vedi la mia proposta era riferito alla relazione del tipo route. 
Highway=path/track rimane ovviamente, come anche surface, sac_scale ecc.

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

Re: [Talk-it] Sentiero CAI dismesso

Se c'è qualcuno che sa il tedesco ben venga se fa una ricerca.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Sentiero-CAI-dismesso-tp5778442p5778507.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] Santellone di grandi dimensioni

2013-09-23 Per discussione demon.box

Vi chiedo conferma: nel caso di Santella o Santello oppure ancora Santellone
(denominata proprio così), se come, a volte, dice il nome stesso é di
dimensioni importanti e si presenta quindi più come una cappelletta credo
sia più giusto non taggarla come historic=wayside_shrine ma invece mettere:

building=chapel
amenity=place_of_worship
denomination=catholic
religion=christian

Siete d'accordo?
Grazie, ciao
--enrico

Allego un esempio di Santella di Sant'Apollonio:
http://gis.19327.n5.nabble.com/file/n5778516/lumezzane_santello_mestolo.jpg 



--
View this message in context: 
http://gis.19327.n5.nabble.com/Santellone-di-grandi-dimensioni-tp5778516.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] Numeri romani sulle vie

Ieri sulla ML del FVG è sorto il problema dell'indicazione delle date sui
cartelli delle vie.
Nella pagina del wiki  http://wiki.openstreetmap.org/wiki/IT:Key:name
http://wiki.openstreetmap.org/wiki/IT:Key:name   si dice di usare i numeri
arabi.

Ma su tutti i cartelli che ho visto in giro ho sempre visto i numeri romani,
inoltre anche sull'archivio dei dati ISTAT vengono usati i numeri romani.
E anche verificando in comune, almeno da me sono riportati i numeri romani.

A questo punto o la pagina riporta un'indicazione errata o sono errati tutti
i cartelli stradali.

A mio avviso solo il dato ufficiale è quello che conta, non le convenzioni
stabilite dal forum.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Numeri-romani-sulle-vie-tp5778517.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] Velo OK

Immagino vadano taggati come speedcamera, ma vanno posizionati su un nodo
della way o sul lato della strada dove sono realmente posizionati?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Velo-OK-tp5778530.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] Aiuole separatorie in accesso alla toronda

Ho trovato questo nodo 2451710484 e anche quelli vicini taggati come
traffic_calming=island, ma a mio avviso non è proprio la loro funzione, o
per semplificare, invece di creare i due rami si fa così?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Aiuole-separatorie-in-accesso-alla-toronda-tp5778532.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] Colle montano

Guardando bene la cartina e soprattutto le curve di livello, mi sembra di
capire che il colle è una specie di sella fra due rilievi di altezza non
rilevante. E quindi non può essere una saddle, che invece si distingue per
essere un qualcosa di marcato di solito su una cresta.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Colle-montano-tp5778318p5778537.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] Velo OK

2013-09-23 Per discussione Guido Salemme

per rispettare meglio la realtà dovrebbe essere messo nel punto esatto 
dove è l'apparecchiatura


poi per dire su che tratto di strada agisce c'è una relazione

adesso non mi ricordo i particolari rifaccio una ricerca

Il 23/09/2013 11:22, bredy ha scritto:

Immagino vadano taggati come speedcamera, ma vanno posizionati su un nodo
della way o sul lato della strada dove sono realmente posizionati?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Velo-OK-tp5778530.html
Sent from the Italy General mailing list archive at Nabble.com.

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



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

Re: [Talk-it] Velo OK

2013-09-23 Per discussione Simone Saviolo

Eccoti la relazione:

http://wiki.openstreetmap.org/wiki/Enforcement

Ciao,

Simone


Il giorno 23 settembre 2013 11:59, Guido Salemme osm.l...@gmail.com ha
scritto:

 per rispettare meglio la realtà dovrebbe essere messo nel punto esatto
 dove è l'apparecchiatura

 poi per dire su che tratto di strada agisce c'è una relazione

 adesso non mi ricordo i particolari rifaccio una ricerca

 Il 23/09/2013 11:22, bredy ha scritto:

  Immagino vadano taggati come speedcamera, ma vanno posizionati su un nodo
 della way o sul lato della strada dove sono realmente posizionati?



 --
 View this message in context: http://gis.19327.n5.nabble.**
 com/Velo-OK-tp5778530.htmlhttp://gis.19327.n5.nabble.com/Velo-OK-tp5778530.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-ithttps://lists.openstreetmap.org/listinfo/talk-it



 __**_
 Talk-it mailing list
 Talk-it@openstreetmap.org
 https://lists.openstreetmap.**org/listinfo/talk-ithttps://lists.openstreetmap.org/listinfo/talk-it

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

Re: [Talk-it] Santellone di grandi dimensioni

2013-09-23 Per discussione demon.box

...nessuno? 
GRAZIE
--enrico



--
View this message in context: 
http://gis.19327.n5.nabble.com/Santellone-di-grandi-dimensioni-tp5778516p5778564.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] Santellone di grandi dimensioni

2013-09-23 Per discussione Andrea Musuruane

On Mon, Sep 23, 2013 at 1:44 PM, demon.box e.rossin...@alice.it wrote:

 ...nessuno?
 GRAZIE


Leggendo questa voce di wikipedia:
https://it.wikipedia.org/wiki/Santella

Direi di mappare come wayside_shrine:
https://wiki.openstreetmap.org/wiki/Tag:historic%3Dwayside_shrine

Ciao,

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

Re: [Talk-it] Superstrade a carreggiata unica

2013-09-23 Per discussione Tiziano D'Angelo

Ciao a tutti,

riesumo questo post perché sono stato contattato da un altro mappatore
riguardo al tagging di una bretella appena aperta tra Padova e Abano Terme
e della sua gemella per Selvazzano. La  strada in questione è questa:
http://osm.org/go/0IBoPqeV-?m ed ha carreggiata unica e una corsia per
senso di marcia, con piazzole d'emergenza e senza incroci a raso, con
divieto di transito alle biciclette.
La bretella rimpiazza la viabilità ordinaria da/per Padova/Abano/Selvazzano
(ora declassata a tertiary passando in zone residenziali) e si raccorda
alla tangenziale di Padova (a due carreggiate e due corsie per senso di
marcia) senza soluzione di continuità tramite un raccordo a quadrifoglio
(Curva Boston). Sull'estremità opposta termina con una rotonda (nemmeno
questa è una discriminante, ci sono anche autostrade che terminano su una
rotonda...

A mio modo di vedere, dato che è parte integrante del sistema delle
tangenziali (in futuro la bretella per Selvazzano potrebbe fare parte del
Grande Raccordo Anulare di Padova), potrebbe essere tranquillamente taggata
come highway=trunk, nonostante l'unica carreggiata. La gemella in passato è
stata taggata come secondary addirittura!

Ciao

Tiziano

PS: Questo il mio scambio di battute con l'altro mappatore (sua ultima
risposta in alto, mia risposta al centro e suo primo contatto in basso):

==
Grazie innanzitutto per la solerte risposta. Senza dubbio i nostri punti di
vista sono differenti. La classificazione amministrativa delle strade non è
rilevante: la tangenziale est è una strada comunale, la ovest in parte
comunale, in parte regionale, la tangenziale nord una regionale in
gestione, la tangenziale di Limena una provinciale e il primo tratto della
sud è una statale in concessione. La classificazione tecnica adeguata al
tipo Trunk è Categoria B: extraurbane principali o superstrade che dir si
voglia (due corsie per senso di marcia e carreggiate separate). Non ho
ricordi, in Italia di altre strade classificate Trunk che non siano almeno
a carreggiate separate o a due corsie per senso di marcia. Non è poi vero
che non hanno incroci a raso terminando entrambe in una rotatoria. Non
avendo mai avuto in precedenza divergenze di punti di vista, sono anch'io
d'accordo di allargare la discussione in uno spazio ove si possano
confrontare un maggior numero di persone in modo da arrivare ad una
soluzione condivisa. Su Wikipedia ho le pagine di discussione, qui non
saprei da dove cominciare. Lascio alla tua esperienza l'apertura della
controversia al mondo dei mapper veneti. A disposizione.

Daniele

On 2013-09-22 22:05:27 UTC Tizianos wrote:

Non sono d'accordo. La classificazione delle strade non va fatta in base
alla loro classificazione amministrativa (se così è scritto sul wiki è un
errore) quindi il fatto che sia C o di tipo secondario amministrativamente
non implica che sia secondary in OSM. Inoltre che sia a carreggiate
separate o meno non è una discriminante. Posso portare molti esempi di
Trunk a una carreggiata. Inoltre vedrei le due direttissime nel complesso
della viabilità: sono a tutti gli effetti parte del sistema delle
tangenziali e prive di incroci a raso. Invece concordo sul declassamento da
secondary a tertiary della vecchia SP2. Comunque per dirimere la questione
aprirei una discussione in mailing list. A presto Tiziano

On 2013-09-22 21:49:13 UTC dmezza wrote:

Ciao, non sono molto bravo nell'utilizzare la cronologia di OSM, ma credo
sia stato tu a modificare il tipo di strada delle bretelle. Secondo il wiki
di OSM la classificazione Trunk si può utilizzare solo per strade a
carreggiate separate che non rientrino nella definizione di autostrade
(Cat. A per il CdS italiano). Essendo entrambe strade di Cat. C, cioè delle
extraurbane secondarie, non possono che essere classificate che Secondary o
tuttalpiù Primary. Se vuoi sistemare tu la cosa, sennò appena ho dieci
minuti ci penso io. Nell'attesa di un tuo riscontro ti porgo i miei saluti.

Daniele Mezzalira



2013/8/1 Martin Koppenhoefer dieterdre...@gmail.com



 Il giorno 01/ago/2013, alle ore 15:02, Salemme Guido 
 salemme.gu...@email.it ha scritto:

 per indicare che su quella strada non possono passare pedoni ciclisti
 mezzi ciclomotori ecc si usa motoroad=yes

 il punto chiave  è che trunk può essere usato per tutte le strade
 extraurbane che non sono autostrade e che non hanno incroci , rotonde , ecc




 +1, per me va bene includendo anche carreggiate distinte per senso di
 marcia.

 motorroad è per restrizioni simili ad un autostrada
 http://wiki.openstreetmap.org/wiki/Key:motorroad

 Se ho capito bene siamo d'accordo su questi punti, ma non sul numero di
 corsie?


 Ciao,
 Martin

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


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

Re: [Talk-it] Santellone di grandi dimensioni

Se dentro ci stanno delle persone potrebbe essere taggata come chiesetta,
altrimenti come suggerito da Andrea.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Santellone-di-grandi-dimensioni-tp5778516p5778575.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] Superstrade a carreggiata unica

Ogni tot ritorna il problema di come classificare le strade, in quanto il tag
di osm non corrisponde alla classificazione italiana. A mio avviso come per
altre andrebbe data una corrispondenza univoca tra codice della strada e
tagging, altrimenti ci saranno sempre interpretazioni su una cosa che invece
è normata e definita.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Superstrade-a-carreggiata-unica-tp5772124p5778579.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] Santellone di grandi dimensioni

2013-09-23 Per discussione demon.box

In effetti leggendo qui:

http://wiki.openstreetmap.org/wiki/IT:Tag:historic%3Dwayside_shrine
http://wiki.openstreetmap.org/wiki/IT:Tag:historic%3Dwayside_shrine  

si può anche fare un poligono con tag building=wayside_shrine e questa
potrebbe essere il modo corretto quando la santella ha una certa dimensione.





--
View this message in context: 
http://gis.19327.n5.nabble.com/Santellone-di-grandi-dimensioni-tp5778516p5778592.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] OT: Concorso bitbumbam wiildos è in testa ma urge aiuto

2013-09-23 Per discussione matteo ruffoni

Scusate se vi ptopongo questo ot ma riteno che la condivisione del sapere
ed il sostegno ad una iniziativa di SL possa interessare anche qualcuno di
voi.

Qui in trentino abbaimo fatto una distribuzione per le scuole che si chiama
Wiildos (www.wiildos.it) e per racimolare qualche soldo per òpsviluppo
stiamo partecipando ad un concorso bitbumbam che si vince se si viene
votati .

Wiildos è in testa ma per favore aiutateci, potete votare tutti giorni
Un click al giorno

http://bitbumbam.it/project_122
ciao matteo
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Superstrade a carreggiata unica

2013-09-23 Per discussione Paolo Monegato


Il 23/09/2013 14:56, Tiziano D'Angelo ha scritto:

Ciao a tutti,

riesumo questo post perché sono stato contattato da un altro mappatore 
riguardo al tagging di una bretella appena aperta tra Padova e Abano 
Terme e della sua gemella per Selvazzano. La  strada in questione è 
questa: http://osm.org/go/0IBoPqeV-?m ed ha carreggiata unica e una 
corsia per senso di marcia, con piazzole d'emergenza e senza incroci a 
raso, con divieto di transito alle biciclette.
La bretella rimpiazza la viabilità ordinaria da/per 
Padova/Abano/Selvazzano (ora declassata a tertiary passando in zone 
residenziali) e si raccorda alla tangenziale di Padova (a due 
carreggiate e due corsie per senso di marcia) senza soluzione di 
continuità tramite un raccordo a quadrifoglio (Curva Boston). 
Sull'estremità opposta termina con una rotonda (nemmeno questa è una 
discriminante, ci sono anche autostrade che terminano su una rotonda...


Ricordo male o per quella verso Selvazzano s'era discusso in ML 
regionale per arrivare a taggarla in quel modo? Se si, direi che per 
analogia hai fatto bene a classificarla allo stesso modo.


ciao
Paolo M

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

Re: [Talk-it] Numeri romani sulle vie

2013-09-23 Per discussione Simone Saviolo

Il giorno 23 settembre 2013 19:50, emmexx emm...@tiscalinet.it ha scritto:

 Il 09/23/2013 07:40 PM, Paolo Monegato scrisse:
  La convenzione non è stabilita dal forum, ma dalla grammatica italiana.
  I numeri romani in italiano sono numeri ordinali.
  Dunque son sbagliati i cartelli e i dati ufficiali

 Non ho mai sentito questa regola.
 Gli ordinali possono essere indicati con numeri romani. Via XX
 Settembre, Giovanni XXIII non credo possano essere considerati errati da
 un grammatico.


Giovanni XXIII è corretto, perché è il ventitreesimo dei papi chiamati
Giovanni.

Via XX settembre si rifà ad un vecchio uso simile a quello della lingua
inglese, che in italiano corrente è sopravvissuto solo per il primo
di In passato si è anche usato indicare date come il 20 settembre 1870
con la grafia 20.IX.1970.

XXIII° è sicuramente sbagliato.

Ciao,

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

[Talk-it] R: Velo OK

X essere presi e visti dai vari programmi vanno taggati sul nodo della way io 
personalmente li metto sia sul nodo sia nella loro posizione un po come i 
segnali stradali di velocità... C è chi li mette esternamente e poi fa una 
relazione ma devo trovare ancora un navigatore che legge le relazioni cosi 
fatte 

Messaggio originale
Da: bredy...@yahoo.it
Data: 23/09/2013 11.22
A: talk-it@openstreetmap.org
Ogg: [Talk-it] Velo OK

Immagino vadano taggati come speedcamera, ma vanno posizionati su un nodo
della way o sul lato della strada dove sono realmente posizionati?



--
View this message in context: http://gis.19327.n5.nabble.com/Velo-OK-
tp5778530.html
Sent from the Italy General mailing list archive at Nabble.com.

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




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

Re: [Talk-it] Aiuole separatorie in accesso alla toronda

Rotonda http://www.openstreetmap.org/#map=19/45.81969/12.69866  

Questa è la rotonda con le isole sulle 4 diramazioni.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Aiuole-separatorie-in-accesso-alla-toronda-tp5778532p5778637.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-it] R: Re: Velo OK

Se vuoi che i navigatori lo prendano si mette sulla way e poi sul punto esatto 
dove si trova come i segnali di maxspeed

Messaggio originale
Da: osm.l...@gmail.com
Data: 23/09/2013 11.59
A: openstreetmap list - italianotalk-it@openstreetmap.org
Ogg: Re: [Talk-it] Velo OK

per rispettare meglio la realtà dovrebbe essere messo nel punto esatto 
dove è l'apparecchiatura

poi per dire su che tratto di strada agisce c'è una relazione

adesso non mi ricordo i particolari rifaccio una ricerca

Il 23/09/2013 11:22, bredy ha scritto:
 Immagino vadano taggati come speedcamera, ma vanno posizionati su un nodo
 della way o sul lato della strada dove sono realmente posizionati?



 --
 View this message in context: http://gis.19327.n5.nabble.com/Velo-OK-
tp5778530.html
 Sent from the Italy General mailing list archive at Nabble.com.

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


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




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

[Talk-it] R: Aiuole separatorie in accesso alla toronda

È un isola spartitraffico con funzione di rallentamento a cui bisogna far 
attenzione in Germania ne ho viste parecchie x cui perché no soprattutto se l 
isola è piccolina nelle grandi statali meglio la separazione delle carreggiate

Messaggio originale
Da: bredy...@yahoo.it
Data: 23/09/2013 11.35
A: talk-it@openstreetmap.org
Ogg: [Talk-it] Aiuole separatorie in accesso alla toronda

Ho trovato questo nodo 2451710484 e anche quelli vicini taggati come
traffic_calming=island, ma a mio avviso non è proprio la loro funzione, o
per semplificare, invece di creare i due rami si fa così?



--
View this message in context: http://gis.19327.n5.nabble.com/Aiuole-
separatorie-in-accesso-alla-toronda-tp5778532.html
Sent from the Italy General mailing list archive at Nabble.com.

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




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

Re: [Talk-it] M'appare con Josm? serata a Levico Terme venerdì 27 settembre!


Il 23/09/2013 20:56, Cristian Consonni ha scritto:

Il 23 settembre 2013 19:44, girarsi_liste liste.gira...@gmail.com ha scritto:

M'appare con Josm, approfittiamo del prossimo evento OSMit (OpenStreetMap
Italia), che si terrà a Rovereto il 4-5-6 ottobre, per spiegare come si
mappa con l'editor Josm, impariamo a capire cosa aspettarci da un'eventuale
mappatura, perchè sono importanti i tag e le relazioni al fine del dettaglio
più vicino possibile alla realtà.

Ovviamente a chi interessa in zona, ed ogni aiuto è bene accettato, pure il
pubblico.. :), grazie.

http://www.linuxtrent.it/mappare-con-josm-serata-levico-terme-venerd%C3%AC-27-settembre


Ma poi vieni a replicarlo anche OSMit, vero?
La domenica è fatta apposta per i workshop!

Ciao,


Ma te sì tut scem??

Comunque avevo detto che non vengo, non ricordo se qui o nella lista del 
linuxtrent.




--
Simone Girardelli

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

Re: [Talk-it] R: Re: R: Re: Aiuole separatorie in accesso alla toronda


Il 23/09/2013 20:58, beppebo...@libero.it ha scritto:

Mettendo l informazione nella way si ha il vantaggio vengano letti soprattutto
se sono piccole isole spartitraffico messe dove c è l'accesso pedonale è un
messaggio di attenzione...per le grosse con erba eccetera e way evidentemente
staccate da metri la way va separata in due e van messi gli oneway e in mezzo
quello che hai messo tu e magari un crossing e givevway in uscita



No, io ho proprio separato le way e messo i sensi unici, anche se non 
sono rotatorie, il senso del discorso è lo stesso, quelle isole separano 
le way in sensi unici, quindi, con relazioni restrictions che obbligano 
all'entrata e uscita dalla rotonda nelle way predeterminata, ed 
all'inizio dell'isola nella way che esce dalla rotonda ho messo un 
divieto di svolta.



--
Simone Girardelli

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

Re: [Talk-it] M'appare con Josm? serata a Levico Terme venerdì 27 settembre!

2013-09-23 Per discussione Cristian Consonni

Il 23 settembre 2013 20:59, girarsi_liste liste.gira...@gmail.com ha scritto:
 Ma te sì tut scem??

(Era una proposta seria)

C

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

Re: [Talk-it] Aiuole separatorie in accesso alla toronda

Ciao,

sono stato io a cominciare di mappare in questo modo delle biforcazioni in
due strade a senso unico opposto prima del raccordo con la rotonda in due
casi:

1) l'isola risultante era cosi piccola che mi sembrava uno sprecco di tempo
inserire due strade a senso unico e poi anche la necessaria relazione

2) come mappatura provvisoria anche di isole grandi in casi dove volevo
evidenziare che c'era questo tipo di spartitraffico, ma non avevo la
pazienza di rifare tutte le strade, relazioni di turn restrictions e anche
metter apposto route relations che dovevano messere apposto.  In questi
casi una mappatura più realistica la rimandavo al futuro.

Sono stato in contatto con peppe10 e gli ho suggerito di applicare lo
stesso approccio

Volker




2013/9/23 bredy bredy...@yahoo.it

 Ho trovato questo nodo 2451710484 e anche quelli vicini taggati come
 traffic_calming=island, ma a mio avviso non è proprio la loro funzione, o
 per semplificare, invece di creare i due rami si fa così?



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Aiuole-separatorie-in-accesso-alla-toronda-tp5778532.html
 Sent from the Italy General mailing list archive at Nabble.com.

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

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

Re: [Talk-it] M'appare con Josm? serata a Levico Terme venerdì 27 settembre!


Il 23/09/2013 21:03, Cristian Consonni ha scritto:

Il 23 settembre 2013 20:59, girarsi_liste liste.gira...@gmail.com ha scritto:

Ma te sì tut scem??


(Era una proposta seria)

C

Lo so, mi rendo conto di essere vergognosaamente vigliacco in casa, però 
non me la sento di partecipare, anche perchè ho un'evento, probabile, 
agricolo di una certa importanza (vendemmia per uso personale, a scanso 
di equivoci).






--
Simone Girardelli

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

[Talk-it] R: Re: R: Re: Aiuole separatorie in accesso alla toronda

Mettendo l informazione nella way si ha il vantaggio vengano letti soprattutto 
se sono piccole isole spartitraffico messe dove c è l'accesso pedonale è un 
messaggio di attenzione...per le grosse con erba eccetera e way evidentemente 
staccate da metri la way va separata in due e van messi gli oneway e in mezzo 
quello che hai messo tu e magari un crossing e givevway in uscita

Messaggio originale
Da: liste.gira...@gmail.com
Data: 23/09/2013 20.45
A: talk-it@openstreetmap.org
Ogg: Re: [Talk-it] R: Re:  Aiuole separatorie in accesso alla toronda

Il 23/09/2013 20:30, beppebo...@libero.it ha scritto:
 Li ho messi io proprio l altra settimana:) c era un errore nella rotonda e 
per
 non separarla li ho inseriti cosi anche se in quella secondary erano 
abbastanza
 grandi per cui penso tu possa tranquillamente separarli se hai tempo 
ciao... Se
 sei in zona mi controlleresti le living street non ho visto segnali che le
 rendessero tali...ciao


Adesso ho capito, io li ho mappati come aree, con tag:

area=yes
landuse=grass
access=no (sul poligono dell'area sempre)
barrier=kerb

-- 
Simone Girardelli

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




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

[Talk-it] R: Re: Aiuole separatorie in accesso alla toronda

Li ho messi io proprio l altra settimana:) c era un errore nella rotonda e per 
non separarla li ho inseriti cosi anche se in quella secondary erano abbastanza 
grandi per cui penso tu possa tranquillamente separarli se hai tempo ciao... Se 
sei in zona mi controlleresti le living street non ho visto segnali che le 
rendessero tali...ciao

Messaggio originale
Da: bredy...@yahoo.it
Data: 23/09/2013 20.24
A: talk-it@openstreetmap.org
Ogg: Re: [Talk-it] Aiuole separatorie in accesso alla toronda

Rotonda http://www.openstreetmap.org/#map=19/45.81969/12.69866  

Questa è la rotonda con le isole sulle 4 diramazioni.



--
View this message in context: http://gis.19327.n5.nabble.com/Aiuole-
separatorie-in-accesso-alla-toronda-tp5778532p5778637.html
Sent from the Italy General mailing list archive at Nabble.com.

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




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

Re: [Talk-it] Numeri romani sulle vie

2013-09-23 Per discussione emmexx

Il 09/23/2013 07:40 PM, Paolo Monegato scrisse:
 La convenzione non è stabilita dal forum, ma dalla grammatica italiana.
 I numeri romani in italiano sono numeri ordinali.
 Dunque son sbagliati i cartelli e i dati ufficiali

Non ho mai sentito questa regola.
Gli ordinali possono essere indicati con numeri romani. Via XX
Settembre, Giovanni XXIII non credo possano essere considerati errati da
un grammatico.

ciao
maxx

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

Re: [Talk-it] Aiuole separatorie in accesso alla toronda


Il 23/09/2013 11:35, bredy ha scritto:

Ho trovato questo nodo 2451710484 e anche quelli vicini taggati come
traffic_calming=island, ma a mio avviso non è proprio la loro funzione, o
per semplificare, invece di creare i due rami si fa così?



Puoi mettere il link alla mappa?

Perchè dal nodo non riesco a ritrovare il posto, per farmi un'idea con josm.


--
Simone Girardelli

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

Re: [Talk-it] Numeri romani sulle vie

2013-09-23 Per discussione Paolo Monegato


Il 23/09/2013 10:41, bredy ha scritto:

Ieri sulla ML del FVG è sorto il problema dell'indicazione delle date sui
cartelli delle vie.
Nella pagina del wiki  http://wiki.openstreetmap.org/wiki/IT:Key:name
http://wiki.openstreetmap.org/wiki/IT:Key:name   si dice di usare i numeri
arabi.

Ma su tutti i cartelli che ho visto in giro ho sempre visto i numeri romani,
inoltre anche sull'archivio dei dati ISTAT vengono usati i numeri romani.
E anche verificando in comune, almeno da me sono riportati i numeri romani.

A questo punto o la pagina riporta un'indicazione errata o sono errati tutti
i cartelli stradali.

A mio avviso solo il dato ufficiale è quello che conta, non le convenzioni
stabilite dal forum.


La convenzione non è stabilita dal forum, ma dalla grammatica italiana. 
I numeri romani in italiano sono numeri ordinali.
Dunque son sbagliati i cartelli e i dati ufficiali (a volte sui cartelli 
si trova pure il numero romano seguito da °, il che è ancora peggio).


ciao
Paolo M

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

[Talk-it] M'appare con Josm? serata a Levico Terme venerdì 27 settembre!

M'appare con Josm, approfittiamo del prossimo evento OSMit 
(OpenStreetMap Italia), che si terrà a Rovereto il 4-5-6 ottobre, per 
spiegare come si mappa con l'editor Josm, impariamo a capire cosa 
aspettarci da un'eventuale mappatura, perchè sono importanti i tag e le 
relazioni al fine del dettaglio più vicino possibile alla realtà.


Ovviamente a chi interessa in zona, ed ogni aiuto è bene accettato, pure 
il pubblico.. :), grazie.


http://www.linuxtrent.it/mappare-con-josm-serata-levico-terme-venerd%C3%AC-27-settembre


--
Simone Girardelli

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

Re: [Talk-it] M'appare con Josm? serata a Levico Terme venerdì 27 settembre!

2013-09-23 Per discussione Cristian Consonni

Il 23 settembre 2013 19:44, girarsi_liste liste.gira...@gmail.com ha scritto:
 M'appare con Josm, approfittiamo del prossimo evento OSMit (OpenStreetMap
 Italia), che si terrà a Rovereto il 4-5-6 ottobre, per spiegare come si
 mappa con l'editor Josm, impariamo a capire cosa aspettarci da un'eventuale
 mappatura, perchè sono importanti i tag e le relazioni al fine del dettaglio
 più vicino possibile alla realtà.

 Ovviamente a chi interessa in zona, ed ogni aiuto è bene accettato, pure il
 pubblico.. :), grazie.

 http://www.linuxtrent.it/mappare-con-josm-serata-levico-terme-venerd%C3%AC-27-settembre

Ma poi vieni a replicarlo anche OSMit, vero?
La domenica è fatta apposta per i workshop!

Ciao,

C

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

Re: [Talk-it] Relazioni tra multipolygon

2013-09-23 Per discussione Mario Pichetti


Il 19/09/2013 15:58, Martin Koppenhoefer ha scritto:


2013/9/19 Giovanni Caudullo giovanni.caudu...@gmail.com 
mailto:giovanni.caudu...@gmail.com


Forse è più facile facendo un esempio: io ho una scuola la
mappare, creo il rettangolo dei confini attorno ai quali si
trovano l'edificio, palestra, campi, prati, parcheggi, anche un
boschetto, ecc.



+1, o in altre parole: tutta l'area della scuola


Avendo diversi tipi di uso del suolo, decido di usare i
multipolygon. Il confine sarà un poligono con type=multipolygon,
amenity=school, name=Scuola X. Ora campizzo un prato, siccome è
completamente interno gli darò la relazione inner per la scuola e
outer per il prato.



no, non devi escluderlo dalla scuola. Se il prato fa parte dell'area 
della scuola lo puoi disegnare come un'area (o multipoligono) ma senza 
escluderlo dall'oggetto scuola


Ora invece ho un boschetto che si trova proprio su un confine
dell'area della scuola.
La mia domanda è: i lati in comune tra la scuola e il bosco non
posso essere contemporaneamente inner e outer per la stessa
relazione, come li tratto?



per il boschetto crei un'altra relazione multipoligono che non ha che 
fare con la scuola. La relazione ti serve soltanto per non sovraporre 
due ways ma invece puoi riutilizzare l'unico way, una volta per la 
scuola, una volta per il boschetto. Non devi escludere niente.



Ho individuato due soluzioni:
1- il boschetto viene escluso dal poligono scuola che gira attorno
al boschetto, ma non mi piace perchè il bosco è dentro i confini
della scuola;



-1

2- al tutto boschetto non viene data la relazione inner, quindi i
lati in comune sono sia bosco che scuola, ma così risultano
poligoni sovrapposti.



+1, non c'è problema, sono due cose distinte (scuola, bosco) che si 
possono benissimo sovraporre.


ciao,
Martin



Quando hai mappato per favore mandami il link, lo aggiungo agli esempi, 
grazie, Mario.


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

Re: [Talk-it] R: Re: Aiuole separatorie in accesso alla toronda


Il 23/09/2013 20:30, beppebo...@libero.it ha scritto:

Li ho messi io proprio l altra settimana:) c era un errore nella rotonda e per
non separarla li ho inseriti cosi anche se in quella secondary erano abbastanza
grandi per cui penso tu possa tranquillamente separarli se hai tempo ciao... Se
sei in zona mi controlleresti le living street non ho visto segnali che le
rendessero tali...ciao



Adesso ho capito, io li ho mappati come aree, con tag:

area=yes
landuse=grass
access=no (sul poligono dell'area sempre)
barrier=kerb

--
Simone Girardelli

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

Re: [Talk-it] R: Re: R: Re: Aiuole separatorie in accesso alla toronda

2013/9/23 girarsi_liste liste.gira...@gmail.com

 No, io ho proprio separato le way e messo i sensi unici, anche se non sono
 rotatorie, il senso del discorso è lo stesso, quelle isole separano le way
 in sensi unici,



+1

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

Re: [Talk-it] Colle montano