Re: [talk-au] Local Government Areas without Councils

[Andrew Davidson]

On 28/12/16 17:51, cleary wrote:
Perhaps I might

have suggested different wording such as  "local administrative
districts including but not limited to shires, cities and municipalities".



Fine, so long as you understand that none of those terms covers 
unincorporated areas.


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

Re: [talk-au] Local Government Areas without Councils

[cleary]

In suggesting the term "Local Government Area", I was thinking of areas
as shown in the Local Government Areas (LGA) datasets issued by state
and territory governments (although, at the moment, I understand we have
permissions only to use datasets from LPI NSW and SA Government Data).
These datasets include areas covered by various pieces of legislation
including but not limited to "local government" acts.  Perhaps I might
have suggested different wording such as  "local administrative
districts including but not limited to shires, cities and
municipalities".






On Sat, Dec 24, 2016, at 05:38 PM, Warin wrote:

> On 24-Dec-16 04:40 PM, Andrew Davidson wrote:

>> On 23/12/16 09:50, cleary wrote: 

>> 

>>> 

>>> 

>>> 

>>> I suggest a simple one-word change in the wiki so that Level 6

>>>  administrative boundaries in Australia would read "Local
>>>  Government Area
>>>  Border (e.g Shire/Council)" replacing "Local Government Authority
>>>  Border
>>>  (e.g Shire/Council)" clarifying that we map the area rather
>>>  than the
>>>  form of administration in the area. 

>>> 

>> 

>> I completely agree with this proposed change. It will clarify exactly
>> what is supposed to be represented by an admin_level 6 boundary.
>> 

>>  In NSW the term "local government area" is used in a number of
>>  pieces of legislation because different rules apply if you are in a
>>  local government area than if you are not. As a result there is a
>>  clear and unambiguous definition of what is and what is not a local
>>  government area.
>> 

> 

> Err does this mean there are areas in NSW that have no 'local
> government area'?
>  Or did you mean '*"local government area" is used in a number of
>  pieces of legislation because different rules apply if you are in a
>  local government area or another local government area*' ?
> 

>> 

>> SA doesn't use the term in their legislation but there is a LGA areas
>> dataset available from data.sa.gov.au that defines for each part of
>> SA whether or not it is a local government area.
>> 

>>  Hopefully this will stop the rather tedious debate about what
>>  exactly constitutes a local government authority.
> 

> Personally I would want to get away from the hair splitting and get
> back to mapping.
> 

> _

> Talk-au mailing list

> Talk-au@openstreetmap.org

> https://lists.openstreetmap.org/listinfo/talk-au


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

Re: [OSM-talk] Beware Pokemon users

[Nicolás Alvarez]

> El 28 dic 2016, a las 02:34, Nick Hocking  escribió:
> 
> How about we ask the game maker to code in (and let slip in social media) 
> that lots of new pokemon stuff may appear on every OSM residential road, 
> outside a residence that has a street number (in OSM) equal to todays day 
> number (e.g 28 - for today). Of course all the other OSM address tags must 
> also be correct for this stuff to appear.
> 

How could the game possibly know if newly-added tags are correct?

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

Re: [OSM-talk] Beware Pokemon users

[Nick Hocking]

How about we ask the game maker to code in (and let slip in social media)
that lots of new pokemon stuff may appear on every OSM residential road,
outside a residence that has a street number (in OSM) equal to todays day
number (e.g 28 - for today). Of course all the other OSM address tags must
also be correct for this stuff to appear.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Beware Pokemon users

[Warin]

Targeting Pokemon contributors falls into a trap... the assumption that a 
particular activity/group are all inclined to vandalism.

These new contributors could be very usefull ... if 'we' don't tar them all 
with abusive thoughts.


On 28-Dec-16 10:50 AM, Rod Bera wrote:

Hi Andy,

just to make myself understood:

improving the db by adding relevant features and tags is a good thing
for everyone, even though those doing so (literally everyone) do it in
places they chose with tags they're interested in.
To me this is working for the community. This does not degrade the
overall quality and accuracy of the OSM base. Rather the opposite. This
is exactly what OSM is about. The fact that the improvement is local and
thematic is unavoidable.


And here 'we' degrade the nonlocal contributors.



But this is a different story if my edits don't conform to ground truth.
It also has a name when done on purpose: vandalism.

Users who deliberately put incorrect or fictional stuff into OSM are
working for their benefits (catching more Pokemons), and their edits are
detrimental to the community.


Not all vandals work for their 'benefits', some  make changes far from their 
locations - I can see no 'benefit' other than their own amusement.



regards,

Rod


The usual view is - what I do is 'good', and if your not doing the same kind of 
thing it is of lesser value.

Takes while for most to accept that most people do 'good' by what ever means 
they enter data (say 90%) -

a few of the remainder have made a mistake in tagging (say 90% of the 
remainder) -

a few of the remainder have made a mistake in recognition of a feature (say 90% 
of the remainder) -

a few of the remainder have made a mistake in copyright (say 90% of the 
remainder) -

and then you have the deliberate vandals ... less than 99.99% of contributors.



On 27/12/16 11:31, Andy Townsend wrote:

Just to pick up one point from this...


On 26/12/16 11:36, Rod Bera wrote:

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

Sounds like I'm bang to rights there!  Most of what I add to OSM
(footpaths, trees, whether a local pub has a stone floor and a real fire
etc.) could be exactly described as "maximising benefits for a minority
of users".  Worse, the local OSMers all seem to be doing the same thing
- shops, house numbers, a borderline obsession with tunnels, but
everyone has different ideas of what to do, so that somehow a wide range
of things are covered.

Cheers,

Andy


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





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

Re: [OSM-talk] Applying different restrictions in different directions on a road

[Janko Mihelić]

If buses are oneway in the other direction then you need

oneway:PSV=-1

I didn't understand if busses were two-way or oneway in the reverse.

On Tue, 20 Dec 2016, 13:20 Volker Schmidt,  wrote:

> "
> oneway=yes
> oneway:bicycle=no
> oneway:PSV=no
> "
> should do the trick
>
> Volker
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Beware Pokemon users

[Rod Bera]

Hi Andy,

just to make myself understood:

improving the db by adding relevant features and tags is a good thing
for everyone, even though those doing so (literally everyone) do it in
places they chose with tags they're interested in.
To me this is working for the community. This does not degrade the
overall quality and accuracy of the OSM base. Rather the opposite. This
is exactly what OSM is about. The fact that the improvement is local and
thematic is unavoidable.

But this is a different story if my edits don't conform to ground truth.
It also has a name when done on purpose: vandalism.

Users who deliberately put incorrect or fictional stuff into OSM are
working for their benefits (catching more Pokemons), and their edits are
detrimental to the community.

regards,

Rod

On 27/12/16 11:31, Andy Townsend wrote:
> Just to pick up one point from this...
> 
> 
> On 26/12/16 11:36, Rod Bera wrote:
>> Systematic bias put into the OSM base towards maximising benefits for a
>> minority of users is a threat.
>> Especially when the primary interest of these users is not OSM in itself.
> 
> Sounds like I'm bang to rights there!  Most of what I add to OSM
> (footpaths, trees, whether a local pub has a stone floor and a real fire
> etc.) could be exactly described as "maximising benefits for a minority
> of users".  Worse, the local OSMers all seem to be doing the same thing
> - shops, house numbers, a borderline obsession with tunnels, but
> everyone has different ideas of what to do, so that somehow a wide range
> of things are covered.
> 
> Cheers,
> 
> Andy
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

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

Re: [Talk-at] Peter Paul

[Kevin Kofler]

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

Wenn das der einzige Name dieses Gipfels ist, warum nicht? Sicher besser 
als, daß ihn jemand einfach nach sich selbst benennt.

Kevin Kofler


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Vincent de Château-Thierry]

Bonsoir,

Le 22/12/2016 à 12:09, Nicolas Moyroud a écrit :


Le petit papa Vincent sera donc un peu en retard par rapport à son
homologue vêtu de rouge. Alors ce sera un cadeau de nouvelle année ! ;-)


Avec un coup de main de Laurent (merci à lui) la liste est désormais 5 
fois plus longue.


C'est toujours par ici : 
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html


Joyeux Noël Nicolas :)

vincent

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

[Talk-de] Wochennotiz Nr. 336 20.12.2016-26.12.2016

[Peter Barth]

Hallo zusammen,

die Wochennotiz Nr. 336 mit vielen wichtigen Neuigkeiten aus der
OpenStreetMap Welt ist da:

http://blog.openstreetmap.de/blog/2016/12/wochennotiz-nr-336/

Dies wird die letzte Ausgabe der Wochennotiz sein...



... für dieses Jahr. In diesem Sinne einen guten Rutsch und bis zum
nächsten Jahr ;-)

i.A.
Peda


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

[Talk-at] Wochennotiz Nr. 336 20.12.2016-26.12.2016

[Peter Barth]

Hallo zusammen,

die Wochennotiz Nr. 336 mit vielen wichtigen Neuigkeiten aus der
OpenStreetMap Welt ist da:

http://blog.openstreetmap.de/blog/2016/12/wochennotiz-nr-336/

Dies wird die letzte Ausgabe der Wochennotiz sein...



... für dieses Jahr. In diesem Sinne einen guten Rutsch und bis zum
nächsten Jahr ;-)

i.A.
Peda


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

[Talk-de] Neues vom deutschen Kartenstil

[Sven Geggus]

Anscheinend ist diese Mail nie bei talk-de angekommen, dehalb noch mal...

Hallo zusammen,

pünktlich zu Weihnachten habe ich endlich mal die Änderungen vom Hackweekend
im Oktober eingearbeitet und Online gestellt.

Konkret ging es darum die Klammern bei den Orts- und Straßennamen
loszuwerden.

Der Entschluß das so zu machen ist gefallen, weil die Klammern insbesondere
bei bidirektionalem Text (z.B.  deutsch arabisch oder deutsch - hebräisch)
merkwürdige Effekte (z.B.  schließende Klammer links vom Text) produziert
haben.

Derzeit habe ich jetzt eine Version, die bei Straßen einen Bindestrich " - "
und bei Orten Zeilenumbrüche verwendet.

Beispiele:

Orte:

 Lisboa
Lissabon

Красная площадь
  Roter Platz

Straße:
Никольская ул. - Nikolausstr.

Über Ideen wie man das besser machen kann freue ich mich natürlich!

Wird ein paar Tage brauchen bis man die Änderungen auf tile.openstreetmap.de
durchgängig sieht.

Des weiteren habe ich auch alle upstream Änderungen bis Version 3.0.0 in den
deutschen Stil integriert.

Helfer (insbesondere zum synchron halten mit dem upstream osm carto) werden
auch weiterhin gesucht!

Ein Vorteil beim deutschen Stil ist der "kurze Dienstweg". Wer ein cooles
neues Kartenfeature integrieren kann einfach einen Pull-Request auf github
machen.  Die Chancen, dass ich das dann direkt merge sind deutlich höher als
upstream.

Guten Rutsch

Sven

-- 
"If you don't make lower-resolution mapping data publicly
available, there will be people with their cars and GPS
devices, driving around with their laptops" (Tim Berners-Lee)
/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-co] Mapeo de árboles en Cartagena

[hyan...@gmail.com]

Por supuesto Mario! Gracias.  Ese día estaremos levantando los datos, luego
haremos un taller para subir los datos a OSM, es allí donde necesitamos los
expertos botánicos para identificar las especies y generar el inventario de
cada árbol codificado con su número.

Humberto



El 27 de diciembre de 2016, 13:58, Mario Frasca  escribió:

> Hola Humberto y que bien que se llegue a tanto!
>
> en las finalidades tienes:
>
> - identificar especies
>
> - construir inventario
>
> - levantar datos geográficos
>
> quieres ayuda para elaborar o revisar las modalidades de trabajo?
>
> cordial saludo y felices fiestas navideñas.
>
> ciaociao, Mario
>
> On 2016-12-27 13:32, hyan...@gmail.com wrote:
>
> Hola comunidad,
>
> si alguno de ustedes va a estar en Cartagena de Indias para los primeros
> días de enero, les tengo super plan de mapeo!
>
> http://blog.openstreetmap.co/2016/12/27/mapeo-arboles-cartagena/
>
> Super que nos acompañen!
>
> Felices fiestas!
>
> Humberto Yances
>
>
> ___
> Talk-co mailing 
> listTalk-co@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-co
>
>
>
> ___
> 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: [OSM-co] Mapeo de árboles en Cartagena

[Mario Frasca]

Hola Humberto y que bien que se llegue a tanto!

en las finalidades tienes:

- identificar especies

- construir inventario

- levantar datos geográficos

quieres ayuda para elaborar o revisar las modalidades de trabajo?

cordial saludo y felices fiestas navideñas.

ciaociao, Mario


On 2016-12-27 13:32, hyan...@gmail.com wrote:
> Hola comunidad,
>
> si alguno de ustedes va a estar en Cartagena de Indias para los
> primeros días de enero, les tengo super plan de mapeo!
>
> http://blog.openstreetmap.co/2016/12/27/mapeo-arboles-cartagena/
>
> Super que nos acompañen!
>
> Felices fiestas!
>
> Humberto Yances
>
>
> ___
> 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] [OSM-talk] Fwd: Re: Beware Pokemon users

[Rihards]

On 2016.12.27. 10:15, David Kewley wrote:
> I thought this might be a big problem at first, but now I think it's
> probably a net good thing.
> 
> In Southern California, I saw about 40 users join in the first 24-48
> hours after the video was posted (Dec 22), who immediately started
> mapping footways and similar. A few were bad, most improved the map
> incrementally, if not with great skill, completeness, or accuracy. The
> rate of new people joining and adding footways and similar has gone way
> down since the first 24 hours.
> 
> I just now used Overpass-Turbo to check for new footways in the past ~2
> days in all the western U.S. (to just west of San Antonio, not including
> Alaska and Hawaii), zoomed in briefly on each locality in turn, and
> found with this quick ad hoc eyeball survey only two users who were
> obviously gaming OSM for Pokemon Go in an unhelpful way. I'll address
> them or send them to DWG. All the others looked reasonable upon a first
> pass, although I might have missed a few. Some I didn't see may already
> have been cleaned up, of course.
> 
> So the potential problem is big, but I think the actual problem is not
> too big, and can probably be contained with our current level of effort.
> Meanwhile there are tons of incremental additions that are probably net
> improvements to the map, and a few of these folks will continue to
> improve the map over time. I've already seen a few of these new users
> branch out into non-Pokemon-related improvements. Plus it gives OSM
> wider awareness.
> 
> One other thing to look out for, which most people are doing well, but a
> few are doing inappropriately, is changing school grounds from
> amenity=school to =college or =university.
> See 
> https://www.reddit.com/r/TheSilphRoad/comments/5jv1c4/i_think_i_figured_out_why_pokemon_never_spawned/.
> I had to change one secondary school back to =school after an apparent
> Pokemon user changed it to =college. I also changed one community
> college from =school to =college when I noticed it was mistagged while
> looking at new footways drawn there. Hope it helps them have fun with
> their game. :)
> 
> I've also seen fake parks, piers, lakes, and similar area objects get
> added in an apparent attempt to help Pokemon. Footways may be the most
> common manifestation of this wave of activity, but not the only one.

could you please share the overpass query you used ? i'd like to review
such additions around here as well.
i am following the edits of new users, and so far contributions of 2 or
3 have been worthy a revert.

it would be also useful to have a list of tags/changes the pokemon go
players make. footways are the most obvious, but i've also seen
(incorrect_ recreational_grounds added. several users have also changed
existing residentials, pedestrian streets and tracks to footways -
incorrectly in all the cases.

> Fun fact: On 12/22 I actually stumbled across a deletion of the footway
> added in the video, before I was aware of the existence of the video and
> the Pokemon-related editing. That issue is since resolved. The
> videographer is pretty local to me, and in the video he hikes in hills I
> know. A brush with a weird kind of notoriety, I guess.
> 
> David
...
-- 
 Rihards

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

[OSM-co] Mapeo de árboles en Cartagena

[hyan...@gmail.com]

Hola comunidad,

si alguno de ustedes va a estar en Cartagena de Indias para los primeros
días de enero, les tengo super plan de mapeo!

http://blog.openstreetmap.co/2016/12/27/mapeo-arboles-cartagena/

Super que nos acompañen!

Felices fiestas!

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Allez, pour peaufiner :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#16/47.7536/-3.4387

La trame pour le dessin de la forêt soit ne commence pas en (0,0) de la 
tuile soit ne fait pas un sous-multiple de 256 au moins dans le sens 
vertical car on a des rangées de confères allongés :


Apparentement terrible :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#16/47.7480/-3.3661

Jean-Yvon

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

Re: [Talk-lt] Segmentuotas upelis

[Saulius Kaukenas]

Sveikas,

Čia bitmap'as turbūt neatsinaujinęs (viena jo plytelė nauja, kita - dar
neatnaujinta). Patikrink kaip rodo per redaktorių, ten tiksliausiai matysi
kaip yra.

S.

2016 m. gruodžio 27 d. 10:54, Rimas Kudelis  rašė:

> Tomai, ačiū ir tau už atsakymą.
>
> Dar vieną dalyką pastebėjau: maksimaliai pritraukus vaizdą, upelio vaga
> ties pietiniu tvenkinio galu kažkodėl nutrūksta:
>
>
>
> Kaip taip gali būti? :)
>
> Rimas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

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

[Marián Kyral]

Dne 27.12.2016 v 11:40 Petr Morávek [Xificurk] napsal(a):
> Dne 27.12.2016 v 08:44 Marián Kyral napsal(a):
>> Dne 27.12.2016 v 08:29 Marián Kyral napsal(a):
>>> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a):
 @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
 (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
 pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
 projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.

>>> Snažím se to napasovat na KM. Konkrétně na tuhle definici:
>>> 
>>>   
>>>   
>>>   >> value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>>>   
>>>   
>>>   
>>> 
>>>
>>> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí.
>>>
>>> Marián
>> Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného:
>>
>>
>> To je OK, nebo to mám nějak změnit?
>>
>> Marián
>
> Ahoj,
>
> pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v
> JOSM podívat na Jablunkov s vrstvami:
> - WMS přesně podle tvé definice
> - Český RUIAN budovy (TMS z poloha.net)
>
> A přišlo mi, že to na sebe pěkně pasuje.

Abych pravdu řekl, dle všech dostupných indícií vlastně nemám žádný
problém. Pro ČÚZK je to metr a půl sem, metr a půl tam :-D

A abych pravdu řekl, vůbec jsem nezaregistroval, že je dostupný nějaký
nový grid, který se zřejmě už normálně používá. Já žil v domnění, že
ještě stále potřebujeme ten algoritmus od ČÚZK, abychom jej mohli
přepočítat.

Já jen reagoval na email "[Talk-cz] Trasovani RUIAN - prosim poradne" od
Martina Jandy, který mi připomněl, že jsou zase vánoce a možná by to
chtělo dořešit ten grid. No a asi se to už mezitím nějak dořešilo :-D

Marián

>
> S pozdravem,
> Petr
>
> ___
> 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-br] Alturas, mapas3D do OSM

[yoshichika ando]

so complementando, ele pega o tipo de telhado do OSM

https://wiki.openstreetmap.org/wiki/Simple_3D_buildings#Roof

http://demo.f4map.com/#lat=-26.3219920=-48.8464775;
zoom=19=49.92=-165.194

tem um posto de 2014 do John Packer falando disso


2016-12-26 23:09 GMT-02:00 Pedro vida torta :

> Os dados vem do site geosampa , são o resultado das plantas dos imoveis
> fotos aéreas e fotos em 3 D recolhidas pela prefeitura no final da década
> de noventa , por veículos equipados com  varias câmeras tipo SV.  No site
> tem de tudo canos, fiação, esgotos, pontos de ônibus, numeração de porta
> etc , são exportados para o OSM por um mapeador de são Paulo
>
> Em 26/12/2016 20:13, "Lucas Ferreira Mation" 
> escreveu:
>
>> Pessoal,
>>
>> em primeiro lugar um feliz natal.
>>
>> Alguém sabe de onde vem os dados de planta dos prédios e altura que são
>> usados para renderizar o mapa em 3D? Esta empresa (f4map) os calcula
>> automaticamente de alguma forma (análise de sombras de imagens aérias) ou
>> estes dados já estão no OSM?
>>
>> Fiquei muito surpreso de ver o quão completo isso está para São Paulo
>> São Paulo
>> http://demo.f4map.com/#lat=-23.5522503=-46.6761298=16
>>
>> Já para Brasília, os prédios das superquadras parecem mais baixos do que
>> realmetne são
>>
>> http://demo.f4map.com/#lat=-15.8045536=-47.8923768=17
>>
>> Enfim, apenas queria saber se de fato estes dados estão no OSM, e como
>> são inseridos
>>
>> feliz 2017
>> Lucas
>>
>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] PROJETO "MAPEANDO COM ESCOLAS"

[Sérgio V .]

Só trocando o link para o PROJETO, para docx (sem problemas de caracteres):

https://www.dropbox.com/s/mpy765pbsgteyps/PROJETO%20DE%20MAPEAMENTO%20COM%20ESCOLAS%20-%20ROTEIRO.docx?dl=0


- - - - -

Compartilho aqui ideias sobre projeto de mapeamento com escolas, também após 
conversa com o Gilmar Ferreira que trouxe ótima ideia de projeto neste sentido:

Bom dia Gilmar,

Penso que ideias sobre como conduzir experiências junto a escolas podem ser 
implementadas sem problemas, a depender de cada região se necessitar ajustes em 
projeto.

A primeira questão penso que é iniciar um contato diretamente com professores e 
diretores de escolas, para mostrar um projeto, o que é o OSM, etc. Depois, se 
aceita a proposta, apresentar e preparar com os alunos.
Ter um projeto básico e material visual a apresentar é importante.

Tenho estado preparando algum material de projeto para isto. Mas poderia também 
ser útil adaptar conforme a necessidade em cada local/colégio, ou conforme 
preferir.

Fiquem à vontade para copiar, adaptar, etc. Podendo, toquem adiante, ótima 
iniciativa. E compartilhem os resultados.


LINKS:

PROJETO PRELIMINAR - SUGESTÃO:
https://www.dropbox.com/s/k5p8ox20wvxuqpc/PROJETO%20DE%20MAPEAMENTO%20COM%20ESCOLAS%20-%20ROTEIRO.txt?dl=0

APRESENTAÇÃO INFORMATIVA "O QUE É O OSM" (A RESUMIR E SIMPLIFICAR PARA 
COLÉGIOS):
https://www.dropbox.com/s/cot3xd2vq6dnu4h/PALESTRA%20OSM%202016.docx?dl=0

Neste último tem roteiros de práticas de mapeamento no final (oficina 1), e 
explicações breves sobre as tags mais usadas, etc.


Saudações, Sérgio.

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

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

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

[Ha Noj]

> Uff, musím říct, že tvoje zmínka o ETRS89 (a rozdílnosti oproti WGS84)
> pro mne otevřela nová dvířka, která si nejsem jistý, že jsem chtěl
> otevřít :-))
*** Chystám na to téma článek na wiki, ale musím to konzultovat, taky to
není pro mne zcela na první pochopitelné. Bude to možná až po vánocích.

> Zajímalo by mne odkud pochází tvoje transformační parametry towgs84?
> Vůbec se mi je nepodařilo nikde vygooglit a obecně jsem ve spoustě
> zdrojů narážel na doporučení považovat oba systémy za "shodné".
*** V obecné rovině jsou si dnes ETRS a WGS84 podobné na úrovni metrů. Jak
jsem psal, v ČR jsou odlišnosti v řádech 30 cm.

> A když
> se podívám na definici v /usr/share/proj/epsg tak tam je:
>
> > # ETRS89
> > <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs  <>
*** To může také říkat, že takový vztah není vůbec definován.

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

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

[Petr Morávek [Xificurk]]

Dne 27.12.2016 v 11:40 Petr Morávek [Xificurk] napsal(a):
> Dne 27.12.2016 v 08:44 Marián Kyral napsal(a):
>> Dne 27.12.2016 v 08:29 Marián Kyral napsal(a):
>>> Dne 26.12.2016 v 23:55 Petr Morávek [Xificurk] napsal(a):
 @Marián: Ty se snažíš vyřešit zarovnání dat, co posílá Petr z poloha.net
 (hádám, že vznikají transformací ze zdrojového EPSG:5514 do latlon
 pomocí gridu) s čím konkrétně? S WMS podklady? A ty teď taháš v jaké
 projekci? EPSG:4326? Jestli jo, tak to zkus vyměnit za EPSG:4258.

>>> Snažím se to napasovat na KM. Konkrétně na tuhle definici:
>>> 
>>>   
>>>   
>>>   >> value='http://services.cuzk.cz/wms/wms.asp?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=DEF_PARCELY,DEF_BUDOVY,RST_PK_I,RST_KMD_I,dalsi_p_mapy_i,obrazy_parcel_i,parcelni_cisla_i,hranice_parcel_barevne,omp_iSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true'/>
>>>   
>>>   
>>>   
>>> 
>>>
>>> Žádnou projekci tam nemám, předpokládám, že se použije nějaká výchozí.
>>>
>>> Marián
>>
>> Tak jsem hledal v nastavení a tam mám ještě něco úplně jiného:
>>
>>
>> To je OK, nebo to mám nějak změnit?
>>
>> Marián
> 
> 
> Ahoj,
> 
> pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v
> JOSM podívat na Jablunkov s vrstvami:
> - WMS přesně podle tvé definice
> - Český RUIAN budovy (TMS z poloha.net)
> 
> A přišlo mi, že to na sebe pěkně pasuje.
> 
> S pozdravem,
> Petr

Ale jak na to koukám, tak JOSM asi stejně neumí udělat reprojekci
lokálně :/ Takže je nereálné stahovat EPSG:4258 dlaždice a do mercatora
(EPSG:3857) to převádět až u sebe.

Petr

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

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

[girarsi_liste]

Il 27/12/2016 11:32, Marco Ciampa ha scritto:
> Onestamente non ho capito niente.
> Che vuoi dire? Stai parlando della qualità dei dati?
> Dicci dicci che se ci sono problemi è meglio saperlo per risolverli!
> 

Sulla discussione con la quale avevo aperto la mia segnalazione, ci sono
il link alle due pagine dove ho visto che per me alcune zone sono "OSM",
Michele dice che quei riferimenti c'erano già da prima, e che in osm
sono stati copiati/importati in seguito alla messa a disposizione dei
dati da parte del Comune di Trento per cui in realtà la mappa presente
sul sito è antecedente ad OSM.

Scaricati un paio di mappe/pdf da quei link, confrontale e prova a
fartene un'idea.




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



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

[talk-ph] Proposing mapping of areas affected by Typhoon Nina

[Jherome Miguel]

Last Christmas day, Typhoon Nina made landfall and have caused damage to
buildings and infrastructure, especially power lines, in Bicol Region and
CALABARZON, yet, buildings in affected areas are still not mapped in many
parts of the areas affected. While building mapping is continuing in
Batangas, as part of DOST's Project NOAH (ISAIAH), other areas affected,
like most of Quezon, Camarines Norte, Camarines Sur, and Catanduanaes have
a few buildings mapped, as a result of lack of quality aerial imagery.
Mapping important infrastructure, like buildings (especially houses), roads
(especially roads leading to barangays), power lines, and important POI's
may help in humanitarian response, especially if done before disaster
strikes, like mapping done before Typhoon Ruby (Hagupit) in 2014, where
Northern Samar, which was soon hit by the typhoon.

Are there any possibility of mapping areas affected by this recent typhoon?
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

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

[Petr Morávek [Xificurk]]

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


Ahoj,

pošli mi prosím bližší info, kde je problém... teď jsem se zkoušel v
JOSM podívat na Jablunkov s vrstvami:
- WMS přesně podle tvé definice
- Český RUIAN budovy (TMS z poloha.net)

A přišlo mi, že to na sebe pěkně pasuje.

S pozdravem,
Petr

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

Re: [OSM-talk] Beware Pokemon users

[Andy Townsend]

Just to pick up one point from this...


On 26/12/16 11:36, Rod Bera wrote:

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


Sounds like I'm bang to rights there!  Most of what I add to OSM 
(footpaths, trees, whether a local pub has a stone floor and a real fire 
etc.) could be exactly described as "maximising benefits for a minority 
of users".  Worse, the local OSMers all seem to be doing the same thing 
- shops, house numbers, a borderline obsession with tunnels, but 
everyone has different ideas of what to do, so that somehow a wide range 
of things are covered.


Cheers,

Andy


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

Re: [Talk-lt] OSM WMS URL

[Tomas Straupis]

> Norėjau paklausti, gal žinote laisvą OSM WMS url?

  Naudoti neteko, bet googlas randa šį tą:
  http://wiki.openstreetmap.org/wiki/WMS#OSM_WMS_Servers
  http://wiki.openstreetmap.org/wiki/WORLD_OSM_WMS

-- 
Tomas

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

Re: [Talk-lt] Segmentuotas upelis

[Tomas Straupis]

> Dar vieną dalyką pastebėjau: maksimaliai pritraukus vaizdą, upelio
> vaga ties pietiniu tvenkinio galu kažkodėl nutrūksta:

  Matosi, kad ir miško riba trūktelta į šoną. Tai spėju keičiant
segmento pavadinimus buvo pakeista ir upelio (bei miško) geometrija. O
tada vieną kaladėlę OSM jau spėjo pergeneruoti, o kitos - dar ne.
Žodžiu reikia truputį palaukti, paspausti F5 (refresh) ir viskas bus
gerai :-)

> Man kas segmentavime nepatinka – tai kad 1) atsiranda galimybė
> tuos segmentus įvardinti skirtingais vardais (kaip buvo iki šio ryto
> – Dalis upelio segmentų vadinosi „Kedrono upelis“, kita dalis
> – „Kedronas“, o kai kurie buvo išvis neįvardinti; dabar visus
> pervadinau į „Cedronas“)

  Čia du punktai:
  1. Kai kurios upės vienoje vietoje (tarkim aukštupyje) turi vieną
pavadinimą, o kitoje (žemupyje) - kitą. Nors tai neskaitoma „dvejomis
skirtingomis upėmis“.
  2. Pakankamai nesunkiai galima būtų padaryti taisyklę, kuri
patikrintų, kad upės ryšio nariai visi turėtų tą patį pavadinimą. Arba
pavadinimą iš name arba alt_name kelių pavadinimų atveju. (Apie
taisykles daugiau parašysiu žemiau).

> 2) kad „sugriūna“ tų pavadinimų rodymo optimizavimas, nes jis imamas
> optimizuoti kiekvienam segmentui atskirai. Gaila, jei OSM neturi kokio
> gudresnio būdo jiems susieti, nei „suvedant galus“, nors tikriausiai tai
> būdinga visiems žemėlapiams?

  Pavadinimus reikėtų generuoti naudojant iš ryšio sugeneruotą
vientisą kelią (beje, tas pats galioja ir keliams). Bet čia teoriškai.
O praktiškai, vieni žemėlapiai braižomi vienaip, kiti - kitaip...
Žodžiu čia jau žemėlapio, o ne duomenų problema.

  O dabar dėl tikrinimo taisyklių. Bendras pastebėjimas, kad daugėjant
žymėtojų, daugėjant duomenų ir jiems sudėtingėjant, darosi vis sunkiau
palaikyti žemėlapio kokybę. Peržiūrėti naujokų pakeitimus užima vis
daugiau laiko. Taigi, mano galva, vienintelis sprendimas - kurti kiek
galima daugiau automatinių duomenų tikrinimo taisyklių. Kai kurios
tokios taisyklės jau yra keepright.at, osmose ar geofabriko
inspektoriuje, bet kiek papildomų taisyklių mes galime susikurti patys
Lietuvos duomenų tikrinimui. Šiuo metu jau yra sukurtos 39 grynai
Lietuvos taisyklės. Vat jas galima pildyti ir tada užsiimti aptiktų
klaidų taisymu (jei taisyti kasdien ar kas kelias dienas, tai klaidų
labai retai prisikaupia daug iš karto, todėl užima ne tiek ir daug
laiko).
  Šiuo metu yra tokios vandens vektorių taisyklės (tiek vietines, tiek
„užsienio“ taisykles)
  1. Vandens vektorius negali kirstis su kitu vandens vektoriumi be
bendro taško.
  2. Vandens vektorius negali kirstis su keliu tame pačiame lygmenyje (layer).
  3. Jei vandens vektoriaus sluoksnis -1, tai turi būti ir tunnel žyma.
  4. Jei yra pavadinimas - tai upė arba upeliukas, o ne ditch.
  5. Upės ir upeliuko pabaigoje (pagal kryptį) turi būti kito upės ar
upeliuko vektorius.
  gal dar ką praleidau.

  Tai jei turite minčių, kokias kitas topologijos, žymų ar pan.
taisykles galima būtų pridėti - idėjos visada laukiamos! Taisyklė
realizuojama užklausa (select'u) iš lentų, kuriose yra taškai, keliai,
plotai. Galima naudoti įvairias postgis geografines funkcijas. Šiuo
metu ryšio informacijos neturiu, bet ji tikrai turės atsirasti ir dėl
kitų poreikių. Tai nereiškia, kad jums reikia siūlant parašyti pačią
užklausą, čia tik kad būtų aišku, kokio pobūdžio taisykles galvoti.

-- 
Tomas

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

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

[lenny.libre]

Oui, je pense avoir bien compris ce que tente de faire cette analyse, 
(j'ai eu d'autres cas avec cette analyse que j'ai pu résoudre) mais cela 
ne répond pas à ma question initiale qui se trouve en bas du mail, dans 
quel cas suis-je ?



Le 26/12/2016 à 19:31, Frédéric Rodrigo a écrit :


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


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



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

Bonjour

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

T. Ruchin


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

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

léni


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

Bonjour :

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

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

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

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

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

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

A votre avis, dans quel cas suis-je ?

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

[Talk-lt] OSM WMS URL

[Giedrius Vaivilavičius]

Sveiki!

Norėjau paklausti, gal žinote laisvą OSM WMS url? Noriu užsimesti mobiliame 
įrenginyje ant QFIELD programėlės. Deja kol kas QFIELD nepalaiko QuwickMap  ir 
OpenLayers QGIS papildinių, dėl to reikia dėti tiesiogiai kaip WMS sluoksnį.

-- 
Giedrius Vaivilavičius 

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

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

[girarsi_liste]

Il 27/12/2016 08:50, michele zanolli ha scritto:
> Quello che scrivi non mi meraviglia, anzi! Ma per il motivo
> esattamente opposto a quello che pensi.
> Può voler dire che gli utenti OSM hanno preso i dati dal Comune di
> Trento per arricchire la mappa della città, cosa assolutamente
> consentita dalla (non) licenza attribuita ai dati geografici del
> Comune (public domain, CC0). E questo mi farebbe davvero piacere,
> quale promotore/sostenitore di OSM.
> 
> I dati del Comune risalgono ad una prima edizione della carta tecnica
> numerica realizzata nel 2.000 e non mi risulta che a quei tempi OSM
> avesse questo livello di dettaglio e, soprattutto, copertura uniforme
> su Trento. Questo dovrebbe fugare ogni dubbio sul "chi ha copiato
> chi".
> 
> Spero di aver chiarito.
> ciao :)
> michele
> 

Non lo so, a questo punto mi arrendo visto a quei tempi non c'ero (in
OSM), ed il tuo concetto del "chi copia chi" ribalta la questione su una
riflessione che alle volte mi fa dire a cosa serve mappare se poi i
risultati son questi, e non intendo insistere sul fatto che la mappa ha
parte di dati OSM, per cui mi rimetto ad eventuali altri interventi nel
caso ce ne sia interesse, diversamente terrò conto del tuo intervento e
me ne farò una ragione..



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



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

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

[Peter Dobratz]

There's a bit of confusion around this and it took me quite a while playing
around with the relation editor in JOSM ("Select Next Gap") to understand
how the "forward" and "backward" roles work.

https://i.imgur.com/RGV2XOX.png

First, consider how you would create a road route relation for your example
if the red segment didn't exist.  Also, for the moment ignore the signed
cardinal directions of the route.  In that case, you would arbitrarily
chose to start from the left-most or right-most segment in the picture.  If
you chose to start with the right-most segment:

right-most (role: "")
blue (role: "")
green (role: "")
left-most (role: "")

All of the roles would be empty and you would not need to use the roles
"forward" or "backward".

Now consider that the red segment exists and you need to indicate that the
road route splits in two and then reconverges.  In this case, you would do
the following, again starting at the right side of the picture:

right-most (role: "")
blue (role: "backward")
green (role: "backward")
red (role: "forward")
left-most (role: "")

You traverse the segments where the road splits first following the
direction of the route and then backtracking to the point where the road
splits and then start adding segments with empty roles.  If either blue,
green, or red is reversed in direction, then they would need to have the
role "backward" instead of "forward", but would still retain the same
position in the list (by convention red should not be reversed since it has
oneway=yes).


So now consider that you want to change the route to indicate "east" and
"west" signed cardinal directions.

One idea is to leave the roles as "forward" and "backward" and just add a
direction=west tag on the relation object.

One idea is that "east" and "west" become synonyms for "forward".  First,
reverse the direction of blue and green and change their roles to
"forward".  Then change the roles to "east" and "west":

right-most (role: "")
blue (role: "west")
green (role: "west")
red (role: "east")
left-most (role: "")

In this case, it is critical that blue and green are not reversed again.


Another approach is to create separate route relations for each direction
of the route.  In that case, you would have one relation with
direction=east:
left-most (role: "")
red (role: "")
right-most (role: "")

And a separate relation with direction=west
right-most (role: "")
blue (role: "")
green (role: "")
left-most (role: "")

In this case, it will also help to update the name tag of the relation to
include "(East)" or "(West)" to more easily tell the route relations apart
in the editor.  Also, the relations can be added to a route_master relation
(type=route_master  route_master=road).


Overall, I think it is cleanest to create 2 route relations, 1 for each
signed cardinal direction of the route.  You don't have to arbitrarily
decide whether to start the route at the eastern or western terminus as
each route relation has a natural starting point based on the signed
cardinal direction.  You don't have to deal with roles on member Ways,
which are very confusing.  You don't have to worry about the direction of
each member way either (again in practice many of them will be marked
oneway=yes and have the direction following the flow of traffic).


Note that whatever approach you chose, the route relations will often break
when the member Ways are split or combined.  Not all OSM editors do the
right thing to preserve the contiguousness of the route relations when
performing these operations.  When people decide to add lane or speed limit
information to the roads that make up the route, they may inadvertently
break the route relation.  In the rare case where multiple users are
concurrently splitting Ways that belong to the same route relation, the
relation usually breaks.

Peter

On Mon, Dec 26, 2016 at 9:29 AM, Albert Pundt  wrote:

> So I understand that one-way ways carrying a route (e.g. a one-way pair or
> divided highway) should have relation roles of north/south/east/west, but
> say you have a situation like this . Say
> you have an east-west route that follows the primary roads in that picture.
> The eastbound direction follows the channelized right turn slip ramp,
> marked with a red arrow. The westbound direction follows the blue-arrow
> way, before turning left onto the green-arrow way.
>
> How should relation memberships and roles be assigned here? I would think
> that the slip ramp would be part of the relation, since right-turning
> traffic must follow it. Ideally, that would be given the role "east", but
> what about the green and blue ways? It might seem right to give them the
> role "west", but how then is it differentiated which direction is westbound
> for it? Since all the ways in this picture are arranged "pointing" north or
> east, the green and blue ways would need to be given the role "backward",
> which is the older way of doing things that 

Re: [Talk-lt] Segmentuotas upelis

[Rimas Kudelis]

Tomai, ačiū ir tau už atsakymą.

Dar vieną dalyką pastebėjau: maksimaliai pritraukus vaizdą, upelio vaga
ties pietiniu tvenkinio galu kažkodėl nutrūksta:



Kaip taip gali būti? :)

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

Re: [Talk-lt] Segmentuotas upelis

[Rimas Kudelis]

Labas,

ačiū už atsakymą.

2016-12-27 10:21, Aidas Kasparas rašė:
> On 2016.12.27 09:10, Rimas Kudelis wrote:
>> Šiuo metu tas upelis OSM žemėlapyje yra suskaidytas į devynis atskirus
>> fragmentus (nepriklausomus objektus), plius kaip atskiras objektas
>> pažymėtas tvenkinys. Noriu paklausti, ar tikrai taip ir turi būti? Ar
>> neturėtų pats upelis būti vientisas? Jei turėtų, gal kas nors galėtų
>> situaciją pataisyti? Aš pats turiu per mažai patirties OSM redagavime, o
>> iD redaktorius taip paprastai objektų sujungti neleidžia, tad nenoriu
>> beeksperimentuodamas ko nors pridirbti.
>
> Dėl segmentavimo. Jei upelis turi skirtingas charakteristikas
> skirtingose vietose (pvz., vienur pažymėta, kad jo plotis 2m., o kitur
> jau 3m.), tai OSM'e nėra kito būdo kaip tokius dalykus parodyti, kaip
> tik skaidyti objektą į atskirus segmentus. Žinoma, segmentai turėtų
> būti sujungti (turėti bent po vieną bendrą mazgą).

Kaip ir minėjau, keliose vietose upeliukas paleistas tekėti vamzdžiu
(culvert) ir kiekvienas toks perėjimas iš atviros srovės į vamzdį tampa
atskiro segmento pradžia. Atrodo, tai ir yra pagrindinė segmentavimo
priežastis, nors kai kur to vamzdžio ilgis nesiekia nė 10 metrų.

> Taigi, pats savaime segmentavimas nėra blogai, jei einant nuo segmento
> prie segmento keičiasi atributai arba to reikia dėl kitų priežasčių
> (be segmentavimo objektas gaunasi „baisiai“ didelis; gatvėse
> nesegmentavus nebūtų aišku į kurią pusę draudžiama sukti ir t.t. ir pan.)

Man kas segmentavime nepatinka – tai kad 1) atsiranda galimybė tuos
segmentus įvardinti skirtingais vardais (kaip buvo iki šio ryto – Dalis
upelio segmentų vadinosi „Kedrono upelis“, kita dalis – „Kedronas“, o
kai kurie buvo išvis neįvardinti; dabar visus pervadinau į „Cedronas“)
ir 2) kad „sugriūna“ tų pavadinimų rodymo optimizavimas, nes jis imamas
optimizuoti kiekvienam segmentui atskirai. Gaila, jei OSM neturi kokio
gudresnio būdo jiems susieti, nei „suvedant galus“, nors tikriausiai tai
būdinga visiems žemėlapiams?

>> Beje, tvenkinys žemėlapyje yra įvardintas kaip „Cedrono tv.“. Ar tikrai
>> pačiuose pirminiuose duomenyse reikia rašyti santrumpą?
>>
> Čia kol kas yra pilka zona. Globalus OSM susitarimas yra objektų
> pavadinimų netrumpinti. Lietuviškas OSM susitarimas yra gatvių
> pavadinimuose trumpinti tipą:
> http://wiki.openstreetmap.org/wiki/WikiProject_Lithuania#Street_names
> Matyt čia buvo pritaikytas gatvių principas. O kaip turėtų būti,
> reikia susitarti.
>
Supratau,

Rimas




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

Re: [Talk-lt] Segmentuotas upelis

[Tomas Straupis]

Laba diena

> Šiuo metu tas upelis OSM žemėlapyje yra suskaidytas į devynis atskirus
> fragmentus (nepriklausomus objektus), plius kaip atskiras objektas
> pažymėtas tvenkinys. Noriu paklausti, ar tikrai taip ir turi būti? Ar
> neturėtų pats upelis būti vientisas?

  Upelis pažymėtas teisingai, nes kaip ir Aidas minėjo, jis
skirtingose vietose turi skirtingas savybes (vienur jis teka
paviršiumi, kitur - vamzdžiu (culvert)). Kitais atvejais skaidymas dar
gali būti dėl to, kad segmentas per ilgas (segmentus, kurie turi
daugiau nei 2000 taškų reikia skaidyti), arba kokia nors upė ištakose
yra stream, o vėliau jau pasidaro river. Kai kuriuose segmentuose
plaukti baidarėmis galima, kitose - negalima/neįmanoma. Taipogi upėmis
kartais eina administracinės ribos, tai tada upės segmentas, kuriuo
eina admin. riba irgi atskirai sukarpomas.

  Jei yra poreikis turėti vieną objektą, kuriame būtų sugrupuoti visi
upės segmentai, tai kuriamas ryšys. Dabar tokie ryšiai yra tik
didžiosioms upėms sukurti ir po truputį pildomi kuriant/pildant
maršrutizuojamą upių žemėlapį.
  Cedronui (Baltupiui) ryšį sukūriau:
  http://www.openstreetmap.org/relation/6824648
  Bet šiaip užtruks, kol tokie mažiukai upeliukai gaus savo ryšius,
nes pradedame žinoma nuo didžiųjų upių. Na nebent kas nors nori tuo
užsiimti.

  Tvenkinys yra atskiras objektas, tai jis niekaip neįtakoja paties
upelio žymėjimo. Čia reikia pastebėti, kad Cedrono vektorius „teka“ ir
per tvenkinį. T.y. Cedronas tvenkinio plote „nenutrūksta“. Toks
žymėjimas įprastas GIS'e na ir be tokio žymėjimo būtų labai
komplikuota padaryti maršrutizavimą upėmis.

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

  Aidas teisingai paminėjo, kad pasaulinis OSM susitarimas yra
netrumpinti. Lietuvoje susitarimas trumpinti, nes mes taip pripratę
matyti žemėlapiuose. Teoriškai galima būtų viską automatu pakeisti
g.->gatvė tv.->tvenkinys plk.->pelkė ir pan., bet pradžiai reikia
išsiaiškinti kam to reikia, t.y. ar kam trukdo trumpinimas ir kam
reikia pilnų pavadinimų. Jei pilnų pavadinimų reikia tik šen bei ten,
tai jau dabar yra kai kurioms gatvėms sudėtos žymos full_name, kur
pvz. „V. Kudirkos g.“ tampa „Vinco Kudirkos gatvė“. Žodžiu
išsiaiškinkime realius poreikius ir pagal juos galima bus pasitaisyti
žymėjimo susitarimus.

-- 
Tomas

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

Re: [Talk-se] Baskarta öppen data helsingborg 2017

[Ture Pålsson]

> 25 dec. 2016 kl. 15:09 skrev Henrik Lundqvist :
> 
> Ogr gdal-biblioteket är ju grymt för att massändra format. Stödjer inte det i 
> OSM?
> 

Det verkar bara ha read-only-stöd för OSM, men det finns ett ogr2osm-verktyg: 
http://wiki.openstreetmap.org/wiki/Ogr2osm 
 . Jag har inte testat det med 
GeoJSON, men det funkade i alla fall för att konvertera höjdkurvor från min 
PostGIS-databas. :)


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

[Talk-it] Footway aggiunte/modificate per colpa di PokermonGO

[Edoardo Yossef Marascalchi]

Ciao a tutti,
sulla ML internazionale [0] segnalano che cominciano ad apparire edit ad
dataset di OSM a mano di utenti di PokemonGo che cercando di forzare il
gioco ad aggiungere nidi.
A quanto pare un paio di settimane fa è stato "svelato" che per decidere
dove collocare i nidi, PokemonGO si basi sui dati di OSM e nello specifico
concentri queste feature vicino a footway e parchi.

Utenti stano aggiungendo percorsi/parchi inesistenti o rendendo footway
percorsi che non lo sono.

Purtroppo non c'è modo di intercettare a priori questi edit e diventa
necessario monitorare attentamente i changeset. Nel caso, è consigliabile
contattare l'utente e cercare di istruirlo sul fatto che gli edit devono
rispettare la realtà e non il gioco. Eventualmente avvisare il DWG rigurado
edit malevoli ed utenti non collaborativi

Edo

[0] https://lists.openstreetmap.org/pipermail/talk/2016-December/077243.html

-- 
Edoardo Yossef Marascalchi
skype: asca_edom
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-lt] Segmentuotas upelis

[Aidas Kasparas]

On 2016.12.27 09:10, Rimas Kudelis wrote:

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


Rimai,

Dėl segmentavimo. Jei upelis turi skirtingas charakteristikas 
skirtingose vietose (pvz., vienur pažymėta, kad jo plotis 2m., o kitur 
jau 3m.), tai OSM'e nėra kito būdo kaip tokius dalykus parodyti, kaip 
tik skaidyti objektą į atskirus segmentus. Žinoma, segmentai turėtų būti 
sujungti (turėti bent po vieną bendrą mazgą).


Taigi, pats savaime segmentavimas nėra blogai, jei einant nuo segmento 
prie segmento keičiasi atributai arba to reikia dėl kitų priežasčių (be 
segmentavimo objektas gaunasi „baisiai“ didelis; gatvėse nesegmentavus 
nebūtų aišku į kurią pusę draudžiama sukti ir t.t. ir pan.)



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

Čia kol kas yra pilka zona. Globalus OSM susitarimas yra objektų 
pavadinimų netrumpinti. Lietuviškas OSM susitarimas yra gatvių 
pavadinimuose trumpinti tipą: 
http://wiki.openstreetmap.org/wiki/WikiProject_Lithuania#Street_names
Matyt čia buvo pritaikytas gatvių principas. O kaip turėtų būti, reikia 
susitarti.


--
Aidas Kasparas


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