date:20140113

Jonathan,

On 13.01.2014 13:17, Jonathan Harley wrote:
 What would happen if every data source started mandating
 that our attribution must be in the corner?

The thing is that for us, for OpenStreetMap, the attribution is our main
remuneration. We give our data away for free but in return, we expect to
get at least a little bit of exposure, a little help in building our
brand to borrow some marketing speak.

Much has been said about how happy we should be if people use our data,
because in the end it's all good for us becasue it increases our
mindshare and therefor our contributor numbers etc.; this reasoning
falls over if we allow users to bury us as an also-ran in a list of
building blocks for their map.

This would be different if we were a paid-for data source, in which case
our major remuneration would be the money people pay us for our data -
in that case, we could afford to be less demanding with regards to the
attribution.

But we aren't, and don't want to be. If OSM plays an important part in
your map, then credit us properly. There are many maps out there which
would be useless if you took away the OSM part, and nonetheless they are
adorned (on-map) with the names of those who made the tiles and those
who bought them for embedding in their web site, with OSM being
relegated to one click away - in order not to dilute the brand
building of those who rely on our data to make a map in the first place.
I don't think that's acceptable.

Bye
Frederik

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

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

[OSM-legal-talk] Corine Land Cover?

2014-01-13 Diskussionsfäden pmsg

Dear all,

The Wiki currently states that import of Corine Land Cover data into OSM is ok:
http://wiki.openstreetmap.org/wiki/Corine_Land_Cover

The source says Unless otherwise indicated, re-use of content on the
EEA website for commercial or non-commercial purposes is permitted
free of charge, provided that the source is acknowledged.

Doesn't the last part (acknowledment) make the data incompatible with OSM?
Users of Produced Works from OSM do not acknowledge EEA.

Thank you for your opinions,
pmsg

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

Re: [OSM-legal-talk] Corine Land Cover?

2014/1/13 pmsg pmsg2...@yahoo.com

 Thank you for your opinions,
 pmsg



legal issues aside my concern is that Corine Data is not suitable
technically for OSM: the resolution is too low and not compatible with the
rest of our data.

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

Re: [OSM-legal-talk] Attribution Requirements


On 13.01.2014 18:06, Frederik Ramm wrote:

Jonathan,

On 13.01.2014 13:17, Jonathan Harley wrote:

What would happen if every data source started mandating
that our attribution must be in the corner?


The thing is that for us, for OpenStreetMap, the attribution is our main
remuneration. We give our data away for free but in return, we expect to
get at least a little bit of exposure, a little help in building our
brand to borrow some marketing speak.


Our own legal FAQ published at 
http://wiki.osmfoundation.org/wiki/License says:


In other words, you should expect to credit OpenStreetMap in the same 
way and with the same prominence as would be expected by any other map 
supplier.


I'm reading it as it's fine to put OSM credits on a credits page if 
all credits are there. As long as other map suppliers like Google and 
Bing are happy by being only credited on a separate page, we're happy as 
well to be on the same page. What's not OK would be showing the Google 
credits in the corner and hide OSM somewhere behind a link.


If this is not what this paragraph intended to state, please write it in 
a way which is easier to understand by non native speakers.



As there is a similar looking page in out wiki which is linked from the 
very prominently placed copyright link on the main page it might be a 
good idea to revise that page or replace it completely by the (at least 
I assume) more authoritative page of the OSMF.


http://wiki.openstreetmap.org/wiki/Legal_FAQ

I have placed a warning on that page and refer to the OSMF.

Stephan


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

Re: [OSM-legal-talk] Attribution Requirements

Hi,

On 13.01.2014 22:52, Stephan Knauss wrote:
 As long as other map suppliers like Google and
 Bing are happy by being only credited on a separate page, 

Are they?

Bye
Frederik

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

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

Re: [OSM-legal-talk] Attribution Requirements


On 13.01.2014 23:41, Frederik Ramm wrote:

On 13.01.2014 22:52, Stephan Knauss wrote:

As long as other map suppliers like Google and
Bing are happy by being only credited on a separate page,


Are they?
No idea. Do their terms allow to use the tiles directly without using 
their own JS-API which enforces the attribution in the corner?


BTW: Someone mentioned Mapbox:
Mapbox does not display attribution but Terms  Feedback. At least if 
you follow their introduction on how to show a simple map. No word about 
attribution.

https://www.mapbox.com/mapbox.js/example/v1.0.0/

a click leads to a copyright page mentioning OSM, no link to us but to ODbL.
https://www.mapbox.com/about/maps/


Showcase of Mapbox shows some of their customers.
Foursquare: No attribution. A click away they mention OSM but not ODbL
Pinterest: can't say without sign up, but based on screenshot 
attribution is About this map

Hipmunk: no attribution. Clearly uses OSM data


So having a correct attribution seems to be a quite hard task, even for 
a company so closely related to OSM as mapbox is. Probably they also did 
not read the legal page which recommends:


If you are producing library code that offers OpenStreetMap data or 
tiles, you should make sure library users are aware of these terms. We 
strongly recommend that you display this credit by default when your 
library is used. 


;)

Stephan



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

Re: [OSM-talk] Proposed automated edit: remove railway=* or highway=* tag on relations tagged type=route

2014-01-13 Diskussionsfäden Martin Raifer

Actual numbers would be about 1830 highway=* and about 490 railway=*  
objects with type=route if you count only relations:  
http://overpass-turbo.eu/s/22q


Martin

Taginfo finds type=route combined with 1374 instances of railway=*  
(0.48%) and 6426 instances of highway=* (2.23%).


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

Re: [OSM-talk] Proposed automated edit: remove railway=* or highway=* tag on relations tagged type=route

2014/1/13 Guillaume Rischard openstreet...@stereo.lu

 Hello,

 Several relations have both type=route and highway=* or railway=* tags; I
 would like to remove the highway or railway tags from the relations, and
 leave them on the members. The relation highway tags are redundant with the
 member ways, make no semantic sense, and can cause rendering issues:

 - Redundancy: A route typically contains highways or railways that
 each have a highway=* or railway=* tag. Because the information is already
 included in the members of the relation, it is redundant to tag the
 relation with that tag as well — you're tagging in two places when you only
 need one.

 - Semantic meaning: These relations are not highways or railways, they
 are a *group* of them that make up a route. The tag belongs on the members,
 not on the relation. It causes semantic problems when the value of the tag
 differs on the relation and on the member: is the street a motorway like
 the relation's highway tag says, or residential like the way's tag says?


tags on relations can be seen as default values for the relation members,
so in such a case, the default tag is replaced by the member one.
I'm not saying it's right to do it that way, just a way to deal with data
in such cases.



 - Rendering: if both a way and its relation are tagged as highway=* or
 railway=*, the line will get drawn twice on the map — once for the way, and
 once on top of that for the line formed by all the ways in the relation.
 While this is invisible in most cases, it will cause unexpected results if
 the tags disagree, e.g. a trunk that's part of a highway=motorway relation,
 or a railway tunnel that's part of a railway=rail relation.



This can also be managed at rendering level in several ways:
- do not render route=* (that's the option I choose)
- render route=* first in case there is one (may not render right in your
motorway/residential example, but fine with the railway tunnel)


I think it's better to deal with such cases at data consumption level as
the case may show up again and again in the future.

If this kind of tagging is indeed considered wrong, no problem to fix the
data with a mechanical edit but we should at least agree on what's
right/wrong first.


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

[OSM-talk] Level of detail, Zoom 19. Has it decreased?

2014-01-13 Diskussionsfäden Bryce Nesbitt

Has the detail level of the default mapnik stylesheet (zoom 19) changed
recently?

Increasingly I've found that when using the map I can't get the level of
detail I want
when zoomed to level 19 (I end up firing up josm, or turning on Map Data
when all I really wanted was view a map).

Here's an example area:
http://www.openstreetmap.org/#map=19/37.88117/-122.27424
Where there are at least two stores not shown at maximum zoom, despite what
seems like plenty of space.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Level of detail, Zoom 19. Has it decreased?

2014-01-13 Diskussionsfäden Paul Norman

There's nothing that I see that would be rendered given more space -
shop=toys and shop=beauty have never been rendered by osm.xml or
openstreetmap-carto. See
https://github.com/gravitystorm/openstreetmap-carto/issues/116 for the
current discussion about this.

 

From: Bryce Nesbitt [mailto:bry...@obviously.com] 
Sent: Monday, January 13, 2014 10:43 AM
To: talk@openstreetmap.org
Subject: [OSM-talk] Level of detail, Zoom 19. Has it decreased?

 

Has the detail level of the default mapnik stylesheet (zoom 19) changed
recently?

 

Increasingly I've found that when using the map I can't get the level of
detail I want

when zoomed to level 19 (I end up firing up josm, or turning on Map Data
when all I really wanted was view a map).

 

Here's an example area:

http://www.openstreetmap.org/#map=19/37.88117/-122.27424

Where there are at least two stores not shown at maximum zoom, despite what
seems like plenty of space.

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

[OSM-talk-nl] StateOfTheMap-eu in Karlsruhe: in het Engels én Call for Presentations

2014-01-13 Diskussionsfäden geejee



hallo Mappers,

Voor diegenenen die na de geslaagde OSGeoNL+OSM Nieuwjaarsborrel  
enthousiast zijn geworden voor de State-Of-The-Map die op 13-15 juni  
in Karlsruhe (4,5 uur treinen vanaf Utrecht Centraal) wordt gehouden,  
maar op school niet zo goed hebben opgelet bij de Schwere Wörter: ik  
lees op http://sotm-eu.org/en dat the conference language is English.


(grappig: de Duitstalige pagina rept over Die Konferenzsprache ist  
hauptsächlich Englisch, de Franstalige pagina zegt niets over een  
voertaal)


De call for presentations staat tot 28 feb. open. Misschien iets voor  
de BAG-importers? (met wellicht een paar weken later op de OSGeonl dag  
een reprise...)




groet,

Gert-Jan


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

[Talk-br] desincreissão

2014-01-13 Diskussionsfäden cardoso veras

Gentileza retirar o meu email deste circulo.
Grato.
Cardoso Veras

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

[Talk-de] OSM-Straßenlistenauswertung: landesweite Updates zentrale Listen Baden-Württemberg und Thüringen

2014-01-13 Diskussionsfäden Dietmar

Hallo,

in der OSM-Straßenlistenauswertung [1] habe ich gestern zwei große
Datenaktualisierungen vorgenommen und seit heute früh stehen für diese
auch neue Auswertungen bereit.

Für die Bundesländer

Baden-Württemberg und
Thüringen

stehen zentale Straßenlistendateien zur Auswertung zur Verfügung. Diese
habe ich gestern im Straßenlisten-Wiki [2] aktualisiert, wenn die
vorherigen Listen nicht zwischenzeitlich durch Wiki-User verändert wurden.

Die Listen für Baden-Württemberg sind zum Teil noch von schlechter
Qualität, daher bitte die Auswertung für Eure Gemeinden prüfen und ggfs.
im Wiki die vorherige reaktivieren, wenn diese offensichtlich besser die
Straßen in der jeweiligen Gemeinde abbilden.

Für die Bundesländer Mecklenburg-Vorpommern und Rheinland-Pfalz stehen
auch zentrale Listen zur Verfügung. Diese werde ich in den nächsten
Tagen im Wiki aktualisieren.

Zu den beiden Datenupdates hier noch Details:

Baden-Württemberg

Die Liste wird vom Landesamt für Geoinformation und Landentwicklung LGL
[3] bereitgestellt, in diesem Fall ist der Datenstand 2.1.2014.

* 1017 Straßenlisten wurden aktualisiert. Darin gab es in 417
Straßenlisten inhaltlich Änderungen, 700 Listen sind also inhaltlich
unverändert. Trotzdem wurden auch die 700 aktualisiert, damit der Stand
der Listen erkennbar ist.

Davon habe ich 9 Listen im nachhinein zurückgesetzt, weil die Listen
offenbar qualitativ schlechter waren als die vorhandenen. Dazu habe ich
bei den neuen Auswertungen die Listen mit den größten Verlusten [4],
nämlich mind. 10 Straßen weniger als vorher, händisch überprüft.

* 71 Straßenlisten wurden nicht aktualisiert, weil sie von einem
Wiki-User zwischenzeitlich geändert worden waren. Für diese stelle ich
in den nächsten Tagen weitere Infos bereit, damit Interessierte den
aktuellen Stand im Wiki mit der neuen offiziellen Version abgleichen können

* von 19 Gemeinden gab es keine zentale Listen.

Thüringen
==

Die Liste wird vom Landesamt für Vermessung und Geoinformation [5]
bereitgestellt, der Datenstand ist 14.10.2013.

* 836 Straßenlisten wurden aktualisiert. Darin gab es in 257 Listen
inhaltiche Änderungen, 579 Listen waren also unverändert. Alle wurden
aktualisiert.

* 42 Straßenlisten wurden nicht aktualisiert wg. Änderungen durch
Wiki-User. Zum Abgleich durch Interessierte stelle ich weitere Daten in
einigen Tagen zur Verfügung.

* Die zentrale Liste umfasste alle Gemeinden des Landes.

viele Grüße

Dietmar aka okilimu

[1] http://regio-osm.de/listofstreets/
[2] http://regio-osm.de/listofstreets/wiki/index.php/Hauptseite
[3]
https://www.lgl-bw.de/lgl-internet/opencms/de/07_Produkte_und_Dienstleistungen/Open_Data_Initiative/index.html
[4]
http://regio-osm.de:/listofstreets/ticker?eval_old=12.01.2014eval_new=13.01.2014area=*Baden-W%C3%BCrttemberg*
[5] http://www.geoportal-th.de/de-de/downloadbereiche/downloadkataloge.aspx

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

Re: [Talk-de] Grundriss vs Dachfläche

2014-01-13 Diskussionsfäden Florian Lohoff

On Sat, Jan 11, 2014 at 08:33:06PM +0100, Norbert Kück wrote:
 
 Blindes Übernehmen von Daten lehne ich ab - auch bei ALK. Wenn ich
 Unstimmigkeiten sehe sage ich nicht alles Sch..., sondern spreche
 die Quelle an. Das geht hier gut, weil es um Einzelobjekte geht und
 nicht um flächendeckendes Abmalen.
 
 ALK und Luftbilder haben einen gravierenden Unterschied:
 Vermessungsdaten sind hinreichend genau und richtig, wenn nach dem
 Stand der Technik gearbeitet wird.

Nope - Sorry - Ich habe vor 3 jahren ein altes Haus gekauft. Das war
komplett anders im ALK drin. Nach der Einmessung sind jetzt auch
(genehmigte) Gebaeudeteile aus den 70er und 90er Jahren mal eingetragen
worden, die fehlten bis dahin komplett.

 Luftbilder haben systematische Nachteile, die durch die
 Nachbearbeitung nicht oder nur unvollkommen ausgeglichen werden
 können.

Siehe oben. Ich bin ja eher im Aussenbereich unterwegs und da wird
so viel um und aus und drangebaut und teilweise auch mal gerne
ohne Baugenehmigung oder Bauabnahme - Da steht dann nach 100 Jahren
ein komplett andere Bausubstanz.

ALK uebernehmen wäre dort einfach nur Müll importieren.

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] Grundriss vs Dachfläche

Kurz vorweg: Sorry für mögliche doppelte Antwort.

Am 12.01.2014 20:29, schrieb Martin Koppenhoefer:
ja, da stand ja auch zum Beispiel, mit dem building-key sollte man (m.E.)
ausser der Überdachung nichts taggen, sondern ggf. die Dachfläche (bzw. das
Dach mit Neigung und Überständen etc.) im 3D-Mapping, und definiert als
Teil des Gebäudes (über den key). Grundriss bezeichnet normalerweise den
Plan einer Etage und hat hier m.E. nichts in der Diskussion zu suchen.

Sorry für die Frage. Ich sehe gerade, dass das im deutschen Wiki auch
teilweise beantwortet ist.

http://wiki.openstreetmap.org/wiki/DE:Buildings#Umriss

Trotzdem bleiben meinerseits Fragen offen: So wie ich das nun verstehe
gibt es da in OSM eine Coexistenz zweier Umrisserfassungsmöglichkeiten.
Einmal die Erfassung der Außenwand am Boden und dann die Grundrisslinie.

Ich würde es für sinnvoll halten zu Gebäuden nach Möglichkeit beide
Flächen in der OSM zu haben. Der einfachste Weg wäre wahrscheinlich eine
neue Rolle in der building-Relation. Aber welche soll schließlich den
Building-Tag tragen? Ich finde, dass das wiki dazu eine Aussage treffen
sollte.

Zum 3D-Mapping: Es gibt dort derzeit die Rolle outline. Allerdings weiß
ich nun nicht, ob damit nicht vielleicht die Gebäudewand am Boden
gemeint ist.

Beispiele: Die Portale des Bremer Doms schneiden zum Beispiel in den
Grundriss, den das LfD bereitstellt, eine Aussparung, die nur am Boden
existiert. Das heißt über dieser Fläche, die dort ausgespart ist
befindet sich zum Beispiel Mauer oder übrige Gebäudeteile wie teilweise
die Türme.

Hier die Aussparung, die bei der Erfassung der Mauer am Boden nicht zum
Umriss gehören würde.
http://www.openstreetmap.org/way/211749964

Hier ein Link zu der Karte beim LfD.
http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%200314

Es gibt auch Beispiele bei denen nahezu das gesamte Gebäude
verschwindet, wenn man die Mauer am Boden als Gebäudeweg erfasst:

http://194.95.254.61/denkmalpflege/jpg1/1009a05.jpg

Hier der Link zur Seite beim LfD.
http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%201009

Die freistehenden Gebäudeteile wie Dächer etc sind hier mit einem X
durchgestrichen. BTW: Wer sich die Bilder ansieht, wird vielleicht
bemerken, dass das so nicht ganz richtig sein kann - abgesehen davon ein
valides Beispiel für mein Problem.

So wie ich nun die Grundrisslinie verstanden habe, ist in OSM alles
soweit nach Grundrisslinie getagt. Nun wäre es aber auch sinnvoll das
Gebäude nach Mauer am Boden zu taggen und mappen.

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

Re: [Talk-de] Grundriss vs Dachfläche

2014-01-13 Diskussionsfäden chris66

Am 13.01.2014 11:43, schrieb cracklinrain:

 Zum 3D-Mapping: Es gibt dort derzeit die Rolle outline. Allerdings weiß
 ich nun nicht, ob damit nicht vielleicht die Gebäudewand am Boden
 gemeint ist.

Unser Simple-3D-Modell ist mit dem Konzept building=Grundfläche leider
nicht ganz kompatibel.

Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter
geworden sind, aber bei einem Turm mit Kopf muss die
Umrisslinie des Kopfes als building eingetragen werden
(also die breiteste Stelle), und nicht die Aufstandsfläche
des Turmfußes.

Chris





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

Re: [Talk-de] Grundriss vs Dachfläche

2014-01-13 Diskussionsfäden Ronnie Soak

Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter
 geworden sind, aber bei einem Turm mit Kopf muss die
 Umrisslinie des Kopfes als building eingetragen werden
 (also die breiteste Stelle), und nicht die Aufstandsfläche
 des Turmfußes.


Auslegungssache.
Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und
ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer
das vernünftig unterstützt.

Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer
plötzlich ausschlaggebend für
die Auslegung bestehender Taggingpraxis?

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

[Talk-de] Fwd: [talk-ch] [OKFN-CH] First Meeting of the OpenGLAM CH Working Group

2014-01-13 Diskussionsfäden Simon Poole


Weitergeleitet von talk-ch


 Original-Nachricht 

Dear *

Stumbled upon this email once again. Might be interesting for OSM as
well. - Keywords: KGS-Nummer (Kulturgüterschutz Nummer, Schweiz. PCP
reference number in wikidata) wikidata, wikipedia

https://lists.okfn.org/pipermail/okfn-ch/2013-December/15.html

But maybe it's to late to participate, no idea.


cheeers,
hugi


PS To give you some feeling:

Schweizerische Nationalbibliothek - www.openstreetmap.org/way/40859920
Swiss National Library - https://www.wikidata.org/wiki/Q201787
Klick and look for buildings:
http://de.wikipedia.org/wiki/Liste_der_Kulturg%C3%BCter_in_Bern


-- 

Andreas Bürki

abue...@anidor.com
S/MIME certificate - SHA1 fingerprint:
ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11
GnuPG - GPG fingerprint:
5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227



___
talk-ch mailing list
talk...@openstreetmap.ch
http://lists.openstreetmap.ch/mailman/listinfo/talk-ch

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

[Talk-de] Erinnerung OSM-Hackweekend Berlin

2014-01-13 Diskussionsfäden Lars Lingner

Hallo,

am 25./26.01. findet in Berlin wieder ein OSM-Hackweekend statt. Details
(Ort, Zeit, ...) findet ihr im OSM-Wiki [1].

Dort sieht man auch wer sich bereits angemeldet hat und woran gearbeitet
werden soll. Es ist auch noch Platz in der Liste.

Am Vorabend (Freitag, 24.01) wird es ein Kennenlerntreffen geben. Das
Lokal wird auf der Wikiseite ergänzt, sobald es feststeht.

Viele Grüße

Lars


[1] http://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_Januar_2014

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

Re: [Talk-de] Grundriss vs Dachfläche

Am 13.01.2014 12:29, schrieb Ronnie Soak:
 Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter
 geworden sind, aber bei einem Turm mit Kopf muss die
 Umrisslinie des Kopfes als building eingetragen werden
 (also die breiteste Stelle), und nicht die Aufstandsfläche
 des Turmfußes.

 
 Auslegungssache.
 Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und
 ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer
 das vernünftig unterstützt.

Wenn ich an Dächer Denke, ist das derzeit aber nicht Praxis. Man müsste
dann die Dachstützen statt der Dachfläche mappen.

 
 Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer
 plötzlich ausschlaggebend für
 die Auslegung bestehender Taggingpraxis?

Das hat mit dem Renderer nichts zu tun. Wenn die Frage für mich klar
wäre, was erfasst wird, würde ich den Anwender/Renderer darauf hinweisen.

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

Re: [Talk-de] Grundriss vs Dachfläche

2014-01-13 Diskussionsfäden Tobias Knerr

Am 13.01.2014 12:29, schrieb Ronnie Soak:
 Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und
 ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer
 das vernünftig unterstützt.
 
 Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer
 plötzlich ausschlaggebend für
 die Auslegung bestehender Taggingpraxis?

Wir reden nicht von einem einzelnen Renderer, sondern von einer
software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach
dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller
Stockwerke, um es mal so auszudrücken.

Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch
in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern
u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig
verzerrtes Bild vom Gebäude.

Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine
wichtige Rolle bei der Etablierung solcher Definitionen spielt.
Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die
vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird.

Gruß,
Tobias

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

Re: [Talk-de] Grundriss vs Dachfläche



Am 13.01.2014 14:52, schrieb Tobias Knerr:
 Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch
 in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern
 u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig
 verzerrtes Bild vom Gebäude.

Wobei man beim 3D-Mapping tendenziell ohnehin alle Infos braucht.

 Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine
 wichtige Rolle bei der Etablierung solcher Definitionen spielt.
 Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die
 vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird.

+1

Aber beim 3D-Modellieren könnte man zur Not doch auch das Modell so
ändern, dass neben der Mauer am Boden auch die größte Fläche, die das
Gebäude beschreibt gemapt wird (nicht unbedingt mit dem building-Tag) -
das würde ich dort zumindest als wünschenswertes Ziel sehen. Das heißt:
Eigentlich motiviert das 3D-Modellieren erstmalig das Mappen der Mauer
am Boden. Bisher sehe ich da nur Tags wie tunnel=building_passage oder
covered=yes, die suggerieren, dass es nicht um die Mauer am Boden geht.

Trotzdem: Aus meiner Sicht gibt es derzeit keine Saubere Definition der
building-Fläche im Wiki.

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

[Talk-de] Singen (Hohentwiel): Straßennamen und Busliniennummer

2014-01-13 Diskussionsfäden Andreas Schmidt

hallo,

eigentlich wollte ich nur offensichtlich falsche Straßennamen
berichtigen, aber nun artet es in mehr als das aus.

Hier http://osm.org/go/0C10td1eE-
sind Namen zusammengeschrieben, die bestimmt in zwei Worten geschrieben
werden müssen:
Pommerschestraße
Schlesischestraße
Danzigerstraße
Breslauerstraße
Stettinerstraße

Wenn ich nach einer Quelle für die richtige Schreibweise suche, finde
ich den Buslinienplan.

http://www.stadtwerke-singen.de/pdfs/buslinien_2013.pdf

Darin stehen die Straßen
Danziger Str. und Breslauer Str. so geschrieben, wie ich es erwartete.
Würde das als Quelle reichen oder welche andere Quelle wäre nötig?

Und außerdem sehe ich, dass die angebliche Linie 4
http://www.öpnvkarte.de/?lat=47.74785lon=8.85827zoom=16layers=TBTTT
wohl Linie 6 ist:
http://www.stadtwerke-singen.de/pdfs/linie6_2014.pdf

So, mit meinen guten Absichten, hier Fehler zu berichtigen, bin ich nun
unsicher: Kann ich einfach die Haltestellen-Einträge mit ändern
(Danzigerstraße - Danziger Straße) oder bringe ich damit ungewollt
Fahrpläne u.ä. durcheinander?

Ist vielleicht jemand näher dran als ich, der sich dort auskennt?

Grüße
Andreas


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

Re: [Talk-de] Singen (Hohentwiel): Straßennamen und Busliniennummer

Am 13. Januar 2014 18:41 schrieb Andreas Schmidt 
schmidt-postf...@freenet.de:


 Wenn ich nach einer Quelle für die richtige Schreibweise suche, finde
 ich den Buslinienplan.

 http://www.stadtwerke-singen.de/pdfs/buslinien_2013.pdf

 Darin stehen die Straßen
 Danziger Str. und Breslauer Str. so geschrieben, wie ich es erwartete.
 Würde das als Quelle reichen oder welche andere Quelle wäre nötig?



am besten ist immer hinfahren und nachsehen. Von anderen Quellen darf man
Daten nur dann übernehmen, wenn das ausdrücklich gestattet ist, und selbst
dann bleibt immer das Problem, dass alle Quellen Fehler haben. Ob man das
auch so streng sehen will, wenn es nur um Rechtschreibfehler geht, muss
man sehen ;-) wobei Namen eben Namen sind, und sich nicht unbedingt an die
Rechtschreibung halten müssen.

Die richtige Quelle für Straßennamen ist normalerweise das kommunale
Archiv (Rathaus o.ä.), wo man die entsprechende Widmung aus den Protokollen
der Gemeinderatssitzungen in mühseliger Kleinarbeit zu finden versuchen
kann.
Im konkreten Fall von Singen sind die Protokolle (zumindest die letzten)
zwar im Internet, aber schön hinter einem login gesichert, damit nicht Hinz
und Kunz einfach anonym nachsieht, was die so treiben ;-)
https://singen.allris-online.de/ri/logon.asp

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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

2014-01-13 Diskussionsfäden Werner Hoch

Am Montag, den 13.01.2014, 00:38 +0100 schrieb Wolfgang Hinsch:
 Am Sonntag, den 12.01.2014, 18:56 +0100 schrieb Werner Hoch:
  Du nennst es voreilig. Konstruktive Vorschläge für die schrittweise
  Abschaltung sind willkommen. Welcher Zeitraum wäre für dich sinnvoll
  gewesen, in welchen Schritten?
 
 Worin bestand eigentlich das Problem, die bisherigen OSB-Einträge in die
 Notes zu übernehmen und dann OSB abzuschalten? Der Aufwand, die OSBs
 manuell zu überprüfen und ggf. zu übertragen dürfte in jedem Fall
 wesentlich größer sein.

OSBs sind zu 80% entweder leicht zu beheben oder aber wurden schon
behoben. Hätte man alle nach Notes übernommen, dann müsste man die
Fehler ja immer noch bearbeiten -- sehr viel unnütze Fehlereinträge in
Notes.

Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in
Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick
erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht.
s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools

Grüße
Werner


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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

Am 13. Januar 2014 20:08 schrieb Werner Hoch werner...@gmx.de:


 Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in
 Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick
 erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht.
 s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools



Der Mehraufwand besteht darin, dass ich die OSB erstmal suchen muss (deren
Webseite etc.), während die Notes mir über osm.org auf einem Silbertablett
daherkommen.

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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

2014-01-13 Diskussionsfäden Peter Czaja


On 12.01.2014 12:31, Florian Lohoff wrote:

ich sehe hier seit 3 Tagen das irgendjemand einfach ohne irgendwas zu
machen OSB Bugs schliesst. Die Bugs gehen ohne Username und Ohne
Kommentar einfach zu. Mittlerweile sind 30 Bugs von mir im Umkreis
Guetersloh/Rheda-Wiedenbrück geschlossen worde.

ICH MUSS KOTZEN !


Geht mir genau so. Das Vorgehen, die Bugs kommentarlos anonym
zu löschen bedeutet planlosen Datenverlust und geht gar nicht.

Hier um Paderborn versuche ich gerade, die gerade geschlossenen,
mir für wichtig erscheinenden Bugs nach OSM Notes 'rüberzuretten'.
Bei der Gelegenheit sind als netter Nebeneffekt ein paar Probleme
nach den NRW Atlas Daten auch schon zu klären.

Nach dem Motto Not-Tugend oder so ähnlich. Aber rund um Rheda
ist/war die Bugdichte auch um ein Vielfaches grösser.

  Peter

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

Re: [Talk-de] Grundriss vs Dachfläche

Am 13. Januar 2014 14:52 schrieb Tobias Knerr o...@tobias-knerr.de:

 Wir reden nicht von einem einzelnen Renderer, sondern von einer
 software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach
 dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller
 Stockwerke, um es mal so auszudrücken.



was allerdings gravierende Nachteile für alle die hätte, die sich die Welt
nur in 2D ansehen, weil für die in manchen Fällen ein völlig verzerrtes
Bild der Freiräume auf der Ebene entsteht, die für sie ggf. zugänglich ist
(aussen drum herum).



 Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch
 in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern
 u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig
 verzerrtes Bild vom Gebäude.



wobei dafür die (Aussen-)Räume gut wiedergegeben sind.




 Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine
 wichtige Rolle bei der Etablierung solcher Definitionen spielt.
 Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die
 vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird.



wobei die Leute, die 3D betreiben, da ein ziemlich isoliertes Süppchen
kochen, und (zumindest noch vor einiger Zeit, vielleicht ist das ja jetzt
besser geworden) auch verschiedene Konzepte parallel umgesetzt werden. Wer
tag-Definitionen etablieren will, sollte sich auch auf [tagging] mit der
Kommunity auseinandersetzen und sehen, ob seine Vorstellungen in
Teilbereichen evtl. mit anderen Erfordernissen bzw. Setzungen kollidieren,
und wie man das am besten unter einen Hut bekommen kann.
Ich erinnere mich z.B. an die building:levels (Stockwerksanzahl), wo
einfach mal jemand ein Schaubild ins Wiki gestellt hat, dass es sich dabei
nur um überirdische Stockwerke handele, dafür aber nichtexistierende
Stockwerke mitgezählt werden bei kragenden Bauteilen. Nach einiger Zeit
hiess es dann, das sei etabliert und so ist der Stand AFAIK noch heute,
wobei ich das für extrem fehlerträchtig und unintuitiv halte.

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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

2014-01-13 Diskussionsfäden fly

On 13.01.2014 19:20, Martin Koppenhoefer wrote:
 Am 13. Januar 2014 20:08 schrieb Werner Hoch werner...@gmx.de:
 

 Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in
 Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick
 erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht.
 s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools


 
 Der Mehraufwand besteht darin, dass ich die OSB erstmal suchen muss (deren
 Webseite etc.), während die Notes mir über osm.org auf einem Silbertablett
 daherkommen.

Zugegeben, das JOSM-Plugin würde vielleicht ein bischen früh
abgeschaltet, allerdings besteht immernoch die Möglichkeit es manuell
vom SVN herunterzuladen und zu installieren.

Optimal wäre wohl an Version ohne Möglichkeit neue Bugs zu erstellen.

cu fly

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

[Talk-de] Highway Shields (Strassennummern)

Hallo,

   in Nordamerika sind sie ganz wild darauf, richtige highway shields
zu zeichnen. Bei denen hat ein- und dieselbe Strasse manchmal 8
verschiedene Nummern, die noch dazu jeweils in unterschiedlichen Arten
von Kaestchen zu zeichnen sind.

http://elrond.aperiodic.net/shields/?zoom=14lat=39.76391lon=-86.02913layers=B0

ist ein schoenes Beispiel, und hier

http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68097487

ein Talk von Phil Gold, in dem er erklaert, wie er mit Hilfe von Python
und fiesen Hacks mit planet_osm_rels solche komplizierten Shields bastelt.

Bei uns hingegen scheint diese Thematik niemand hinter dem Ofen
hervorzulocken. Ich bin da jetzt kein Experte, aber dieses Stueck
Autobahn in der Bildmitte hier

http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT

ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht
benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach
ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist
offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige
Nummern, und daher kommt hier gar nix ;)

Hat sich jemand schonmal Gedanken gemacht, wie man das loesen sollte -
sollen wir einfach auch auf den amerikanischen Zug mit aufspringen, oder
waere das fuer D-A-CH-Verhaeltnisse mit Kanonen auf Spatzen geschossen?

(Ich poste das hier auch mal ins Forum, weil ich weiss, dass da ein paar
Routenspezialisten unterwegs sind.)

Bye
Frederik

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

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

Re: [Talk-de] Highway Shields (Strassennummern)

2014-01-13 Diskussionsfäden Martin Vonwald

Hi!

Am 13. Januar 2014 20:05 schrieb Frederik Ramm frede...@remote.org:

 Ich bin da jetzt kein Experte, aber dieses Stueck
 Autobahn in der Bildmitte hier


 http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT

 ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht
 benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach
 ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist
 offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige
 Nummern, und daher kommt hier gar nix ;)


Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich
Gedanken darüber machen den verschiedensten Tools und Anwendungen den
Umgang mit Strichpunkt-separierten Werten beizubringen.

Beste Grüße,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Grundriss vs Dachfläche



Am 13.01.2014 19:35, schrieb Martin Koppenhoefer:
 Am 13. Januar 2014 14:52 schrieb Tobias Knerr o...@tobias-knerr.de:
 
 Wir reden nicht von einem einzelnen Renderer, sondern von einer
 software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach
 dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller
 Stockwerke, um es mal so auszudrücken.

 
 
 was allerdings gravierende Nachteile für alle die hätte, die sich die Welt
 nur in 2D ansehen, weil für die in manchen Fällen ein völlig verzerrtes
 Bild der Freiräume auf der Ebene entsteht, die für sie ggf. zugänglich ist
 (aussen drum herum).

Ich finde, dass an beiden Positionen etwas dran ist. Aber letztendlich
sollte das doch der Renderer entscheiden können. Vor allem sollten die
Positionen aber nicht als Gegenposition verstanden werden, weil wie
gesagt für die 3D-Modelle alle Daten wichtig sind.

Zuletzt liegt es aber auch nicht an den 3D-Tags, dass ein Gebäude, durch
das eine Einfahrt verläuft, in OSM als eine durchgehende Fläche gemapt
wird.

 wobei die Leute, die 3D betreiben, da ein ziemlich isoliertes Süppchen
 kochen, und (zumindest noch vor einiger Zeit, vielleicht ist das ja jetzt
 besser geworden) auch verschiedene Konzepte parallel umgesetzt werden. Wer
 tag-Definitionen etablieren will, sollte sich auch auf [tagging] mit der
 Kommunity auseinandersetzen und sehen, ob seine Vorstellungen in
 Teilbereichen evtl. mit anderen Erfordernissen bzw. Setzungen kollidieren,
 und wie man das am besten unter einen Hut bekommen kann.
 Ich erinnere mich z.B. an die building:levels (Stockwerksanzahl), wo
 einfach mal jemand ein Schaubild ins Wiki gestellt hat, dass es sich dabei
 nur um überirdische Stockwerke handele, dafür aber nichtexistierende
 Stockwerke mitgezählt werden bei kragenden Bauteilen. Nach einiger Zeit
 hiess es dann, das sei etabliert und so ist der Stand AFAIK noch heute,
 wobei ich das für extrem fehlerträchtig und unintuitiv halte.

+1. Ich benutze das zwar häufig, aber vom intuitiven Verständnis würde
jeder vermuten, dass dieser Key die Gesamtstockwerkezahl des Gebäudes
beschreibt.

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

Re: [Talk-de] Highway Shields (Strassennummern)

Hi,

On 13.01.2014 20:13, Martin Vonwald wrote:
 Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich
 Gedanken darüber machen den verschiedensten Tools und Anwendungen den
 Umgang mit Strichpunkt-separierten Werten beizubringen.

Oder man geht komplett vom ref weg, zumindest bei Autobahnen und
Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer
Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht
an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;)

Bye
Frederik

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

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

Re: [Talk-de] Grundriss vs Dachfläche

Am 13. Januar 2014 20:22 schrieb cracklinrain cra_klinr...@gmx.de:

 Ich finde, dass an beiden Positionen etwas dran ist. Aber letztendlich
 sollte das doch der Renderer entscheiden können. Vor allem sollten die
 Positionen aber nicht als Gegenposition verstanden werden, weil wie
 gesagt für die 3D-Modelle alle Daten wichtig sind.



ja, sicherlich sind alle Daten wichtig. Wobei eine Einigung schon sinnvoll
wäre, ob man mit building nun den Teil mappt, der auf dem Boden steht,
oder ob es der Umriss aller Bauteile und Stockwerke ist, also auch der
schwebenden --- wobei die 3D-Leute wahrscheinlich gern den unterirdischen
Teil unterschlagen wollen, zumindest bis jemand eine Anwendung
herausbringt, mit der man Geländeschnitte generieren kann ;-)
Prinzipiell denke ich, dass die 2. Variante ohne Zusatzinformationen
niemandem was bringt (auch wer ein 3D-Modell bauen will, braucht ja die
einzelnen Teile und der Gesamtumriss bringt nichts ausser dass man damit
abschätzen kann, welche Teile vermutlich zu einem Gebäude gehören, wobei
das auch nicht in allen Fällen gut geht).

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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

2014-01-13 Diskussionsfäden Florian Lohoff

On Mon, Jan 13, 2014 at 07:26:38PM +0100, Peter Czaja wrote:
 Geht mir genau so. Das Vorgehen, die Bugs kommentarlos anonym
 zu löschen bedeutet planlosen Datenverlust und geht gar nicht.
 
 Hier um Paderborn versuche ich gerade, die gerade geschlossenen,
 mir für wichtig erscheinenden Bugs nach OSM Notes 'rüberzuretten'.
 Bei der Gelegenheit sind als netter Nebeneffekt ein paar Probleme
 nach den NRW Atlas Daten auch schon zu klären.
 
 Nach dem Motto Not-Tugend oder so ähnlich. Aber rund um Rheda
 ist/war die Bugdichte auch um ein Vielfaches grösser.

Ich habe da selber meine Arbeit mit koordiniert. 
Alles was ich als unstimmig im Augenwinkel wahrgenommen habe 
oder wo dinge nicht so offentlich nach meiner erinnerung fehlte.

RhWd ist auch Adresstechnisch im Begriff komplettiert zu werden
und auch da habe ich bugs gesetzt wo es unstimmigkeiten in den 
Hausnummern gab. 

Quasi alles hops gegangen ...

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

[Talk-de] Bamberg = hsb:Babin?

2014-01-13 Diskussionsfäden Richard Z.

Hi,

das hier ist mir neulich aufgefallen - 
  http://www.openstreetmap.org/node/1646638496/history

als Obersorbischer name für Bamberg ist hier Babin eingetragen
was laut meinem Sprachgefühl und einem Online-Wörterbuch falsch
wäre. Babin hat laut Wörterbuch irgendwas mit Hebammen oder
alten Weibern zu tun. Bin trotzdem vorsichtig es so einfach
ohne Rückfrage zu löschen.

Die History ist leider wenig hilfreich weil der hsb:Babin anscheinend
vor der Lizenzänderung eingetragen wurde und damit nicht sichtbar ist 
wie es hingekommen ist:(

Kann sich jemand zufällig erinnern oder hat eine Idee?

Richard

---
Name and OpenPGP keys available from pgp key servers


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

Re: [Talk-de] Highway Shields (Strassennummern)

2014-01-13 Diskussionsfäden Peter Wendorff

Hi,
jetzt fängst du aber mit Ausweichtaktiken an.
Es fehlt doch offensichtlich ganz generell an der Softwareunterstützung
für mehrwertige Tags, da ist ref doch bei weitem kein Einzelfall, oder
hat sich das mittlerweile so stark gewandelt?

Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten:

amenity=parking;fuel (4523, wobei viele davon vom AND-Import kommen)
amenity=restaurant;cafe (44)
amenity=restaurant; pension
amenity=pub;restaurant;bar
amenity=hospital; univeristy
amenity=fast_food;cafe
cuisine=italian;ice_cream
amenity=fuel; garage
amenity=fuel;compressed_air
amenity=pharmacy;post_office;vending_machine
amenity=bank;atm
amenity=restaurant;bistro
amenity=bench;shelter
amenity=drinking_water; waste_disposal
amenity=bank;post_office
amenity=post_office;bank
amenity=parcel_box;post_box
amenity=cafe;pub;restaurant
amenity=post_box; telphone
amenity=restaurant;biergarten
amenity=vending_machine;waste_basket
amenity=hospital; pharmacy
amenity=fitness_center;sauna
amenity=restaurant;pub
amenity=pub;restaurant
amenity=restaurant; hotel
tourism=guest_house; hotel
amenity=nightclub;pub
amenity=cafe;post_office
amenity=theatre;cinema
amenity=theatre; school
amenity=cafe;arts_centre
shop=kiosk;car_repair
amenity=doctors; dentist
amenity=recycling;waste_container
amenity=language_school;something else (!!! ;) )
amenity=doctors; pharmacy
amenity=fuel;compressed_air;car_wash
amenity=bar;restaurant (71)
amenity=public_building; toilets
amenity=waste_basket;bench
amenity=waste_basket;recycling (170)
amenity=place_of_worship;graveyard
amenity=cafe;pub;nightclub
amenity=restaurant;guest_house
amenity=bench;fountain
amenity=public_building; social_facility
amenity=college;education_centre
cuisine=pizza;kebab
amenity=bar;community_centre
amenity=restaurant;ice_cream
amenity=bar;nightclub
amenity=kindergarten;school
amenity=bar;casino
amenity=charging_station;bicycle_parking
amenity=toilets;shower
amenity=swimming_pool;sauna;gym
amenity=school;place_of_worship (88)
amenity=parking;restaurant;fuel (50)

highway=residential;unclassified (134x laut taginfo)
highway=path;track (68x laut taginfo)
highway=traffic_signals;crossing (62x)
highway=unclassified;residential (44)
highway=residential;track (43)

Das sind offensichtlich gar nicht so viele, aber ich will nicht wissen,
wie oft eins von beidem weggelassen wird, weil es eben keine
Unterstützung für die Kombitags gibt, oder wie oft eine Einrichtung aus
demselben Grund doppelt in OSM auftaucht.

Hotel/Restaurant ist häufig kombiniert, und oft lässt es sich eigentlich
nicht sinnvoll räumlich trennen.
Cafe/Restaurant dürfte noch ähnlich oft vorkommen.

weitere Kombinationen, die bestimmt häufig sind:
Sauna und Schwimmbad
Sauna und Fitness-Studio
Mülleimer und Straßenlaterne (auch wenn beides oft nicht eingetragen wird)

Und ich finde die Situation eigentlich unbefriedigend, dass ich einen
Laden, der mittags warme Küche hat, abends als Kneipe läuft und spät
abends bzw. am Wochenende zur Disco mutiert, nicht gleichzeitig als
alles taggen kann.

Sollen wir jetzt zusätzliche Tags für gängige Kombinationen finden?
Ich bin mir nicht sicher, ob das wirklich die bessere Lösung wäre

Gruß
Peter



Am 13.01.2014 20:30, schrieb Frederik Ramm:
 Hi,
 
 On 13.01.2014 20:13, Martin Vonwald wrote:
 Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich
 Gedanken darüber machen den verschiedensten Tools und Anwendungen den
 Umgang mit Strichpunkt-separierten Werten beizubringen.
 
 Oder man geht komplett vom ref weg, zumindest bei Autobahnen und
 Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer
 Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht
 an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;)
 
 Bye
 Frederik
 


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

[Talk-de] Softwareunterstützung für Semikolon getrennte Tags


On 13.01.2014 22:12, Peter Wendorff wrote:

jetzt fängst du aber mit Ausweichtaktiken an.
Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff 
dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf 
Highway Shields ausgerichtet.



Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten:
highway=residential;unclassified (134x laut taginfo)
highway=path;track (68x laut taginfo)
highway=traffic_signals;crossing (62x)
highway=unclassified;residential (44)
highway=residential;track (43)


Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist 
(oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit 
einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind 
solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat.


Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung 
gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die 
Lösung des Problems nicht.


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

Stephan



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

Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags

2014-01-13 Diskussionsfäden Peter Wendorff

Dass das Problem nicht trivial ist, ist mir klar.
Die automatisch erzeugten Werte von JOSM beim verbinden von Wegen sind
da ein Problem, ja.
Aber die von mir angesprochenen Kombinationen sind eben durchaus auch
üblich und tatsächlich ein Grenzfall.
Was Jochen unter But of course in this case it only means that somebody
couldn’t make up their mind whether to use lake or pond and chose the
worst: both. beschreibt.
Nur ist das nur das Schlechteste, solange es nicht genutzt und
interpretiert wird.

Was mache ich denn mit dem erwähnten Restaurant/Cafe oder
Hotel/Restaurant, Begriffen, die ja sogar fast in die allgemeine Sprache
aufgenommen ist so als Doppelworte?
Was mache ich mit einem Autohaus mit Werkstatt (shop=car,
shop=car_repair), bei dem beides nicht sinnvoll voneinander trennbar ist?

Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an
jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel
machen deutlich dass das Semikolon auch anderes meinen kann. Aber es
gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist
meines Erachtens auch ein gutes Beispiel.

Immer wieder beschweren sich gerade neue Mapper, das Mappen sei so
komplex, man könne eigentlich keinen Weg mehr unterteilen, ohne zig
Relationen kaputtzumachen bzw. reparieren zu müssen; und das zum Teil zu
Recht, wie ich finde.

Bisher sind es nur Buslinien und große Rad/Wanderrouten, die
großflächig als Relationen eingetragen sind; bei Autobahnen,
Bundesstraßen etc. ist das meines Erachtens viel zu häufig, aber das
hält sich in Grenzen. Wenn wir jetzt bei Kreisstraßen, Landstraßen etc.
weitermachen, alles in Relationen zu verpacken, nur weil es eine
zusammenfassende Nummer hat, wächst sich das wieder zu einem Ungetüm aus.
Dann können wir demnächst auch nur noch ungetaggte Ways nutzen, und alle
Tags auf Relationen übertragen, wie das tendentiell schon bei
Multipolygonen passiert. Aber wer sich hinterher über untagged-ways
beschwert, ist dann selbst Schuld, wenn jetzt das Gegenteil gefordert wird.
Ob ich die A30 als Relation zusammenfasse oder die E27, die Buslinie 7
oder die Goethestraße, das ist im Prinzip alles das gleiche, und wenn
wir ref=7;10, ref=B55;E27 etc. nicht haben wollen, wird uns nichts
anderes übrigbleiben, als eben wirklich alles in die Relationen zu
verschieben.

Ob das die bessere Lösung ist, bezweifle ich aber erstmal.

Gruß
Peter


Am 13.01.2014 22:35, schrieb Stephan Knauss:
 On 13.01.2014 22:12, Peter Wendorff wrote:
 jetzt fängst du aber mit Ausweichtaktiken an.
 Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff
 dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf
 Highway Shields ausgerichtet.
 
 Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten:
 highway=residential;unclassified (134x laut taginfo)
 highway=path;track (68x laut taginfo)
 highway=traffic_signals;crossing (62x)
 highway=unclassified;residential (44)
 highway=residential;track (43)
 
 Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist
 (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit
 einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind
 solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat.
 
 Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung
 gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die
 Lösung des Problems nicht.
 
 http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html
 
 Stephan
 
 
 
 ___
 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] Softwareunterstützung für Semikolon getrennte Tags

Hi,

On 13.01.2014 23:10, Peter Wendorff wrote:
 Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an
 jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel
 machen deutlich dass das Semikolon auch anderes meinen kann. Aber es
 gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist
 meines Erachtens auch ein gutes Beispiel.

Allerdings eins, bei dem Relationen eine ganz gute oder zumindest
funktionierende Loesung sind; bei Hotel-Restaurants hingegen wird man
damit nicht weit kommen.

Bis zu API 0.3 uebrigens (oder wars sogar 0.4) konnte ein Objekt in OSM
uebrigens tatsaechlich mehrere Tags desselben Keys haben. Wir haben das
dann abgeschafft, weil fast keine damals gaengige Software das auch
unterstuetzt hat - einmal ein Objekt mit so einem Doppeltag mit JOSM
bearbeitet, schon wurde zufaellig einer der beiden Tags gewaehlt...

Du hast schon recht, es waere wuenschenswert, wenn Software das
automatisch richtig machen wuerde, aber puh, das wird ein langer und
steiniger Weg. Am Anfang stuende die Frage: Sollen wir

* alle Tags ausser die in einer bestimmten Negativliste (note, comment,
...) am Semikolon aufsplitten?

* nur Tags aus einer bestimmten Positivliste (amenity, ref, ...) am
Semikolon aufsplitten?

Wenn ja - wie verteilen wir diese Listen zwischen allen Programmen?

* Tags nur dann aufsplitten, wenn sie einer bestimmten Form genuegen
(z.B.: wenn der Value mit einem Semikolon *beginnt*)?

Bye
Frederik

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

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

Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags


On 13.01.2014 23:40, Frederik Ramm wrote:

Du hast schon recht, es waere wuenschenswert, wenn Software das
automatisch richtig machen wuerde, aber puh, das wird ein langer und
steiniger Weg. Am Anfang stuende die Frage: Sollen wir


eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur 
key=value Paare, sondern noch etwas mehr.


Eine Idee für Api 0.7

Geordnete Listen:
Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge 
nacheinander kommen. Doppelte Values sind erlaubt.


Sets:
Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, 
doppelte Values sind verboten.


Wäre eine größere Änderung, dürfte aber viele der bisherigen 
Verwendungen vom Semikolon abdecken.


Bisherige Werte in der Datenbank blieben als value erhalten bis es 
jemand von Hand (oder script) konvertiert.


ABER: Das ist eine recht große Änderung die eine Modifikation an jeder 
Software erfordern würde die die Daten verarbeiten will. Um kompatibel 
zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 
output wieder zusammenmergen kann in einen einzelnen value mit Semikolon 
für nicht angepasste alte Software.


Stephan



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

Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags

2014-01-13 Diskussionsfäden Peter Wendorff

Am 14.01.2014 00:40, schrieb Stephan Knauss:
 On 13.01.2014 23:40, Frederik Ramm wrote:
 Du hast schon recht, es waere wuenschenswert, wenn Software das
 automatisch richtig machen wuerde, aber puh, das wird ein langer und
 steiniger Weg. Am Anfang stuende die Frage: Sollen wir
 
 eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur
 key=value Paare, sondern noch etwas mehr.
 
 Eine Idee für Api 0.7
 
 Geordnete Listen:
 Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge
 nacheinander kommen. Doppelte Values sind erlaubt.
 
 Sets:
 Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle,
 doppelte Values sind verboten.
 
 Wäre eine größere Änderung, dürfte aber viele der bisherigen
 Verwendungen vom Semikolon abdecken.
 
 Bisherige Werte in der Datenbank blieben als value erhalten bis es
 jemand von Hand (oder script) konvertiert.
 
 ABER: Das ist eine recht große Änderung die eine Modifikation an jeder
 Software erfordern würde die die Daten verarbeiten will. Um kompatibel
 zu bleiben müsste es eventuell einen Konverter geben der den API 0.7
 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon
 für nicht angepasste alte Software.
Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und
dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die
Bojen-Farben:
value-type: List

Bei Lanes: List
Bei amenity: Set
Bei name: String
etc.

Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation
entsprechend behandelt werden (als eine ungeordnete Menge), beim name
als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte.

Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe
sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software,
die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen -
Renderer, Router, ...

Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele
Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft
dafür, dass Mapper großflächig Daten beisteuern und vor allem
korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann
wieder funktioniert.

Gruß
Peter

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

Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags

2014-01-13 Diskussionsfäden André Riedel

Eine Set würde ich in API 0.7 bevorzugen, denn so könnte man bspw. die
Unterschiedlichen Öffnungszeiten kenntlich machen.

key=name value=Zum Goldenen Löwen /
set
 key=amenity value=restaurant /
 key=opening_hours value=Mo-Su 11:00-21:00
/set
set
 key=tourism value=hotel /
 key=opening_hours value=24/7
/set
set
 key=amenity value=cafe /
 key=opening_hours value=Sa,Su 14:00-17:00
/set

Am 14. Januar 2014 08:33 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Am 14.01.2014 00:40, schrieb Stephan Knauss:
 On 13.01.2014 23:40, Frederik Ramm wrote:
 Du hast schon recht, es waere wuenschenswert, wenn Software das
 automatisch richtig machen wuerde, aber puh, das wird ein langer und
 steiniger Weg. Am Anfang stuende die Frage: Sollen wir

 eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur
 key=value Paare, sondern noch etwas mehr.

 Eine Idee für Api 0.7

 Geordnete Listen:
 Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge
 nacheinander kommen. Doppelte Values sind erlaubt.

 Sets:
 Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle,
 doppelte Values sind verboten.

 Wäre eine größere Änderung, dürfte aber viele der bisherigen
 Verwendungen vom Semikolon abdecken.

 Bisherige Werte in der Datenbank blieben als value erhalten bis es
 jemand von Hand (oder script) konvertiert.

 ABER: Das ist eine recht große Änderung die eine Modifikation an jeder
 Software erfordern würde die die Daten verarbeiten will. Um kompatibel
 zu bleiben müsste es eventuell einen Konverter geben der den API 0.7
 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon
 für nicht angepasste alte Software.
 Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und
 dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die
 Bojen-Farben:
 value-type: List

 Bei Lanes: List
 Bei amenity: Set
 Bei name: String
 etc.

 Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation
 entsprechend behandelt werden (als eine ungeordnete Menge), beim name
 als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte.

 Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe
 sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software,
 die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen -
 Renderer, Router, ...

 Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele
 Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft
 dafür, dass Mapper großflächig Daten beisteuern und vor allem
 korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann
 wieder funktioniert.

 Gruß
 Peter

 ___
 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-it] Spam nei nomi?

2014-01-13 Diskussionsfäden Andrea Musuruane

On Sun, Jan 12, 2014 at 10:38 PM, Daniele Forsi dfo...@gmail.com wrote:

 Nelle pagine di Groppo sono saltati fuori questi nomi:

 Marche

 Valore Link
 Sentiero*Frontignano-Visso*(in*parte*303)*-**WWW.CAMOSCIOSIBILLINI.IT
 WWW.CAMOSCIOSIBILLINI.IT*-**AQUILA*REALE
 WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI
 WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI
 WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI
 WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI
 WWW.CAMOSCIOSIBILLINI.IT*-**CAMOSCI*INVERNO
 WWW.CAMOSCIOSIBILLINI.IT*-**CASCATE*DELLE*CALLARELLE
 WWW.CAMOSCIOSIBILLINI.IT*-**CERVI
 WWW.CAMOSCIOSIBILLINI.IT*-**CERVO

 il primo di questi nomi è sulla way 128180628 e potrebbe anche essere
 passabile se fosse su una proprietà privata (ma non lo so), ma gli
 altri...


Ho fatto questa query con http://overpass-turbo.eu/ per ottenere tutti i
nomi che contengono CAMOSCIOSIBILLINI:

osm-script
union
  query type=node
area-query ref=3600053060/
has-kv k=name regv=.*CAMOSCIOSIBILLINI.*/
  /query
  query type=way
area-query ref=3600053060 /
has-kv k=name regv=.*CAMOSCIOSIBILLINI.*/
  /query
  item/
  recurse type=down/
/union
print mode=meta /
/osm-script

Da qui ho visto che le modifiche sono tutte state fatte da questo utente
che si è registrato 6 giorni fa:
http://www.openstreetmap.org/user/Il%20Camoscio%20dei%20Sibillini

Anche il tagging che usa è allucinante. Alcuni esempi:
Place=hamlet; name=WWW.CAMOSCIOSIBILLINI.IT
highway=path; name=WWW.CAMOSCIOSIBILLINI.IT; ref=WWW.CAMOSCIOSIBILLINI.IT

C'è qualcuno in zona che lo può contattare?

Ciao,

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

Re: [Talk-it] R: Nomi in sardo reloaded

2014-01-13 Diskussionsfäden Paolo Monegato


Il 10/01/2014 20:48, Francesco Pelullo ha scritto:


Allora per quale motivo insistere ad usare name=? Eliminiamolo del tutto.



Sarei favorevole, ma per ora non si può (sempre per colpa del rendering).


Il 11/01/2014 01:01, Luca Meloni ha scritto:
Comunque per le statistiche cito wikipedia che cita uno studio della 
regione:

https://it.wikipedia.org/wiki/Lingua_sarda#Distribuzione_geografica
http://www.sardegnacultura.it/documenti/7_88_20070514130939.pdf


Molto interessante, grazie per il link.


Il 12/01/2014 16:25, THC ha scritto:
La versione base rispecchia qual'è il toponimo d'uso comune, il 
toponimo ufficiale, il toponimo impiegato nel territorio dalla 
popolazione, il toponimo col quale la comunità si fa conoscere 
altrove: non lo nasconde, non lo mette per secondo, non lo fonde 
creandone di nuovi.


Non mi pare che il toponimo italiano sia nascosto. E nemmeno che sia 
stato fuso all'altro per crearne uno nuovo. La sbarra è semplicemente un 
artificio per far visualizzare entrambi i nomi ufficiali.


In tutta Italia la gente allora dovrebbe parlare napoletano e lombardo 
come prima lingua, ma non vedo nessun Napule/Napoli e Milan/Milano, 
Turin/Torino: ma cos'è questo trionfo della non-neutralità e 
dell'arbitrio?


La questione è molto semplice, il sardo, a differenza di molti altri 
idiomi locali, è tutelato e riconosciuto da una legge dello stato. E 
questo, in combinazione con le leggi della regione autonoma, rende 
possibile questa disparità di trattamento.
Per quanto riguarda gli idiomi non riconosciuti dalla legge statale ma 
tutelati da quella regionale (gallurese, tabarchino etc) la cosa 
andrebbe discussa. Perché anche altre regioni tutelano i loro idiomi 
locali non tutelati dallo stato e allora si che si potrebbe lamentare 
una differenza di trattamento tra la Gallura e la tal zona del 
continente (fermo restando la questione che una tutela in una regione a 
statuto autonomo ha un valore legale diverso da quella in una regione 
ordinaria)...


Peccato che sia meno rilevante del toponimo in italiano, quindi non 
può venire prima. Peccato che in certi casi è talmente irrelevante da 
non essere nemmeno usato e nemmeno adottato ufficialmente. Quindi cosa 
si sta ripentendo all'infinito: che è meno rilevante del toponimo 
ufficiale in italiano ma l'abbiamo messo prima perché sì


La convenzione adottata nel Sud Tirolo è quella di mettere per primo il 
toponimo nell'idioma parlato dalla maggioranza dei residenti del comune. 
E mi sembra di capire che nel caso sardo si sia seguito questa 
convenzione per uniformità... Nel caso tirolese però siamo in presenza 
di tre comunità linguistiche distinte, mentre nel caso sardo la comunità 
sardofona e quella italofona più o meno coincidono. Dunque a mio avviso 
ci dovrebbe essere un trattamento diverso, ovvero andrebbe messo per 
primo il toponimo più conosciuto.


Sì, visto che molti non hanno deliberato. Sì, visto che province e 
frazioni manco hanno deliberato dei toponimi inventati che sono stati 
inseriti ugualmente. Sì, visto che tutti usano il toponimo italiano 
come toponimo principale.


Anche se le amministrazioni non han deliberato si tratta comunque di 
toponimi in uso, e vanno comunque riportati (almeno sul tag 
name:lang=*). Certo si potrebbe discutere sull'opportunità di metterli 
sul tag name... Ecco, magari si potrebbe dire che può essere messo sul 
tag name solo quando è ufficiale.


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

Re: [Talk-it] Pedestrian routing, oneway, turnstile

2014-01-13 Diskussionsfäden Fabri

Siamo sicuri che il routing fa accedere macchine in way pedestrian?

On lun 13 gen 2014 08:35:27 CET, Fabri erfab...@gmail.com wrote:

 On lun 13 gen 2014 01:22:39 CET, Martin Koppenhoefer
 dieterdre...@gmail.com wrote:
 
  2014/1/10 Fabri erfab...@gmail.com
  
   Per un footway dovrebbe essere palese che se c'è un oneway=yes si può
   accedere solo in un senso.
   
  
  
  forse per un footway si (al meno che non abbia altri tags e quindi il
  tag non era pensato per i pedoni). Purtroppo per le pedestrian è una
  cosa abbastanza comune di avere un oneway=yes (per le macchine) che
  deve essere ignorato per pedoni per avere un routing sensato.
  
  ciao,
  Martin
 caso particolare in cui macchine autorizzate ad accedere in area
 pedonale? oneway:motor_vehicle=yes oneway:foot=no ?
 
 


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

[Talk-it] WMS Piemonte

2014-01-13 Diskussionsfäden Tiziano Gedda

Ciao a tutti..ho trovato questi WMS forniti dalla Regione Piemonte con licenza 
CC-BY 2.5 che potrebbero essere molto utili.Posso utilizzarli come base per un 
ricalco?
Tiziano

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

[Talk-it] relazione ss27

2014-01-13 Diskussionsfäden Volker Schmidt

Ho ricevuto in un contesto diverso una segnaletica sulla relazione della
ss27 che passo alla lista perché non conosco la zona:

the main SS27 relation (Aosta-Great St Bernard Pass) contains many ways
from multiple sections of old_ref=SS27, but does NOT include ways on the
recently built SS27 Gignod village bypass variante di Gignod.  Instead
the old route through the village is maintained in the main SS27 relation.
 Meanwhile the new SS 27 Gignod bypass (just 2.8 km in length) has its own
relation, even though it looks and feels like an integral part of SS27 when
you drive it.

In effect the main SS 27 relation is an historical document (which is fine,
but this probably means it couldn't be used by the mapping and info systems
that we have been discussing here)

Grazie a Peter Davies per la segnalazione

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

Re: [Talk-it] R: Nomi in sardo reloaded

2014-01-13 Diskussionsfäden Francesca Valentina

Quote//
Certo si potrebbe discutere sull'opportunità di metterli sul tag name...
Ecco, magari si potrebbe dire che può essere messo sul tag name solo quando
è ufficiale.

+1

Francesca
Il 13/gen/2014 10:41 Paolo Monegato gato.selvad...@gmail.com ha scritto:

  Il 10/01/2014 20:48, Francesco Pelullo ha scritto:

 Allora per quale motivo insistere ad usare name=? Eliminiamolo del tutto.


 Sarei favorevole, ma per ora non si può (sempre per colpa del rendering).


 Il 11/01/2014 01:01, Luca Meloni ha scritto:

 Comunque per le statistiche cito wikipedia che cita uno studio della
 regione:
 https://it.wikipedia.org/wiki/Lingua_sarda#Distribuzione_geografica
 http://www.sardegnacultura.it/documenti/7_88_20070514130939.pdf


 Molto interessante, grazie per il link.


 Il 12/01/2014 16:25, THC ha scritto:

 La versione base rispecchia qual'è il toponimo d'uso comune, il toponimo
 ufficiale, il toponimo impiegato nel territorio dalla popolazione, il
 toponimo col quale la comunità si fa conoscere altrove: non lo nasconde,
 non lo mette per secondo, non lo fonde creandone di nuovi.


 Non mi pare che il toponimo italiano sia nascosto. E nemmeno che sia stato
 fuso all'altro per crearne uno nuovo. La sbarra è semplicemente un
 artificio per far visualizzare entrambi i nomi ufficiali.

 In tutta Italia la gente allora dovrebbe parlare napoletano e lombardo
 come prima lingua, ma non vedo nessun Napule/Napoli e Milan/Milano,
 Turin/Torino: ma cos'è questo trionfo della non-neutralità e dell'arbitrio?


 La questione è molto semplice, il sardo, a differenza di molti altri
 idiomi locali, è tutelato e riconosciuto da una legge dello stato. E
 questo, in combinazione con le leggi della regione autonoma, rende
 possibile questa disparità di trattamento.
 Per quanto riguarda gli idiomi non riconosciuti dalla legge statale ma
 tutelati da quella regionale (gallurese, tabarchino etc) la cosa andrebbe
 discussa. Perché anche altre regioni tutelano i loro idiomi locali non
 tutelati dallo stato e allora si che si potrebbe lamentare una differenza
 di trattamento tra la Gallura e la tal zona del continente (fermo restando
 la questione che una tutela in una regione a statuto autonomo ha un valore
 legale diverso da quella in una regione ordinaria)...

 Peccato che sia meno rilevante del toponimo in italiano, quindi non può
 venire prima. Peccato che in certi casi è talmente irrelevante da non
 essere nemmeno usato e nemmeno adottato ufficialmente. Quindi cosa si sta
 ripentendo all'infinito: che è meno rilevante del toponimo ufficiale in
 italiano ma l'abbiamo messo prima perché sì


 La convenzione adottata nel Sud Tirolo è quella di mettere per primo il
 toponimo nell'idioma parlato dalla maggioranza dei residenti del comune. E
 mi sembra di capire che nel caso sardo si sia seguito questa convenzione
 per uniformità... Nel caso tirolese però siamo in presenza di tre comunità
 linguistiche distinte, mentre nel caso sardo la comunità sardofona e quella
 italofona più o meno coincidono. Dunque a mio avviso ci dovrebbe essere un
 trattamento diverso, ovvero andrebbe messo per primo il toponimo più
 conosciuto.

  Sì, visto che molti non hanno deliberato. Sì, visto che province e
 frazioni manco hanno deliberato dei toponimi inventati che sono stati
 inseriti ugualmente. Sì, visto che tutti usano il toponimo italiano come
 toponimo principale.


 Anche se le amministrazioni non han deliberato si tratta comunque di
 toponimi in uso, e vanno comunque riportati (almeno sul tag name:lang=*).
 Certo si potrebbe discutere sull'opportunità di metterli sul tag name...
 Ecco, magari si potrebbe dire che può essere messo sul tag name solo quando
 è ufficiale.

 ciao
 Paolo M

 ___
 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] WMS Piemonte

2014-01-13 Diskussionsfäden solitone

Tiziano Gedda ha scritto:

 ho trovato questi
 http://www.geoportale.piemonte.it/cms/index.php?option=com_contentview=articleid=55Itemid=73lang=it
 WMS forniti dalla Regione Piemonte con licenza CC-BY 2.5 che
 potrebbero essere molto utili.

 Posso utilizzarli come base per un ricalco?


Sono molto molto interessanti (grazie!) e piacerebbe poterli usare anche
a me, ma purtroppo continuo a non capirci nulla di licenze...

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

[Talk-it] R: Re: WMS Piemonte

2014-01-13 Diskussionsfäden Gianluca Boero

questa pagina è in italiano
http://creativecommons.org/licenses/by/2.5/it/




Messaggio originale
Da: solit...@mail.com
Data: 13-gen-2014 15.31
A: talk-it@openstreetmap.org
Ogg: Re: [Talk-it] WMS Piemonte

Tiziano Gedda ha scritto:

 ho trovato questi
 http://www.geoportale.piemonte.it/cms/index.php?option=com_contentamp;view=articleamp;id=55amp;Itemid=73amp;lang=it
 WMS forniti dalla Regione Piemonte con licenza CC-BY 2.5 che
 potrebbero essere molto utili.

 Posso utilizzarli come base per un ricalco?


Sono molto molto interessanti (grazie!) e piacerebbe poterli usare anche
a me, ma purtroppo continuo a non capirci nulla di licenze...

___
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] R: Re: WMS Piemonte

2014-01-13 Diskussionsfäden solitone

Gianluca Boero ha scritto:
 questa pagina è in italiano
 http://creativecommons.org/licenses/by/2.5/it/

Come si fa a attribuire la paternità del materiale dopo aver ricalcato
un'ortofoto per creare, per esempio, un edificio? Dobbiamo concludere
che *non* è possibile utilizzare questi servizi?

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

Re: [Talk-it] Pedestrian routing, oneway, turnstile

2014-01-13 Diskussionsfäden Davio

Dipende come è stato programma il software di routing.

In teoria se la way ha solo il tag highway=pedestrian dovrebbe permettere
solo il routing pedonale. Mentre se è presente il tag motor_vehicle=yes
dovrebbe consentire anche il transito delle autovetture, ma ripeto, dipende
dal software se sa interpretare il tag motor_vehicle

Davide



-
Davide
--
View this message in context: 
http://gis.19327.n5.nabble.com/Pedestrian-routing-oneway-turnstile-tp5792290p5792867.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] WMS Piemonte

2014-01-13 Diskussionsfäden Maurizio Napolitano

Puoi usarli.


2014/1/13 Tiziano Gedda dufou...@libero.it:
 Ciao a tutti..

 ho trovato questi WMS forniti dalla Regione Piemonte con licenza CC-BY 2.5
 che potrebbero essere molto utili.

 Posso utilizzarli come base per un ricalco?


 Tiziano




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




-- 
Maurizio Napo Napolitano
http://de.straba.us

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

Re: [Talk-it] Spam nei nomi?

2014/1/13 Andrea Musuruane musur...@gmail.com

 Anche il tagging che usa è allucinante. Alcuni esempi:
 Place=hamlet; name=WWW.CAMOSCIOSIBILLINI.IT
 highway=path; name=WWW.CAMOSCIOSIBILLINI.IT; ref=WWW.CAMOSCIOSIBILLINI.IT

 C'è qualcuno in zona che lo può contattare?




ho rivertato le sue edits (tolto a mano lo spam). Pare che l'utente
mcheckimport aveva già corretto qualche way e scritto all'utente. Qualcuno
ha risposto?

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

Re: [Talk-it] WMS Piemonte

2014-01-13 Diskussionsfäden Tiziano Gedda

Grazie della risposta ”Napo”..sono contento di poterli usare..ci saranno 
sicuramente utili..

Una domanda: come, cosa e dove metto per indicare la source dei dati?

Tiziano


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

Re: [Talk-it] WMS Piemonte

2014/1/13 Tiziano Gedda dufou...@libero.it

 Grazie della risposta ”Napo”..sono contento di poterli usare..ci saranno
 sicuramente utili..

 Una domanda: come, cosa e dove metto per indicare la source dei dati?



in realtà non è così chiaro come dice Napo, al solito cerchiamo di chiarire
con il proprietario come citare la fonte (cerchiamo di autorizzarci di
avere la fonte soltanto nel changeset e/o nel wiki). La cc-by non è chiara
nel merito, quindi non è sufficiente. Ad ogni modo qualsiasi dato importato
con una licenza con vincoli ci lega di più rispetto ad un possibile cambio
di licenza in futuro come previsto dai Contributor Terms.

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

Re: [Talk-it] Pedestrian routing, oneway, turnstile

2014/1/13 Fabri erfab...@gmail.com

 Siamo sicuri che il routing fa accedere macchine in way pedestrian?



dipende dal programma di routing e dalla situazione (eccezioni mappati,
ecc.). Un programma ottimale con una mappatura ottimale dovrebbe farti
accedere in certi casi (per esempio delivery, emergency, ecc.)

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

Re: [Talk-it] Pedestrian routing, oneway, turnstile

2014-01-13 Diskussionsfäden Fabri

Sono d'accordo. Credo infatti che per migliorare il routing in osm ci sia 
bisogno di interpretare le diverse combinazioni di tag per avere un risultato 
diverso in base al tipo di veicolo. Sia per accesso veicolo=yes/no ; che per 
sensi di marcia. Magari farei richiesta di implementare oneway:veicolo=no
ps:in futuro anche tener conto degli orari in cui è consentito accedere...del 
tag conditional...insomma la strada è ancora lunga...
 
On lun 13 gen 2014 16:01:44 CET, Davio davide@gmail.com wrote:

 Dipende come è stato programma il software di routing.
 
 In teoria se la way ha solo il tag highway=pedestrian dovrebbe
 permettere solo il routing pedonale. Mentre se è presente il tag
 motor_vehicle=yes dovrebbe consentire anche il transito delle
 autovetture, ma ripeto, dipende dal software se sa interpretare il tag
 motor_vehicle
 
 Davide
 
 
 
 -
 Davide
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Pedestrian-routing-oneway-turnstile-tp5792290p5792867.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] Priorità numeri civici

2014-01-13 Diskussionsfäden Cascafico Giovanni

Oramai abbiamo mappato una buona parte dei civici del paesiello, ma mi sono
imbattuto in una interessante meta-informazione (e come tale non credo
possa essere soggetta a vincoli proprietari) da
tuttocittà.ithttp://xn--tuttocitt-y1a.it:
una ricerca qualsiasi produce anche un footer con le strade più cercate;
vista la popolarità del sito, credo che possa esser utile per darsi una
priorità nell'attività di mappatura dei numeri civici.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-dk] Til orientering - ny JOSM version 6502 og Geodatastyrelsens luftfotos

2014-01-13 Diskussionsfäden Soren Johannessen

Hej alle sammen

Hvis du installerer den nye nye JOSM version 6502
http://josm.openstreetmap.de/ Så når du redigerer i Danmark, vil du i
JOSM under Billedlag  nu have muligheden for at vælge
Geodatastyrelsen (Denmark) luftfotos direkte. Det er den mapproxy
service som Gregers Petersen for et par uger siden satte op som nu
optræder som et standardvalg til den nye JOSM version.

NB - Hvis du bruger iD
Læs guide her til Geodatastyrelsens luftfotos
http://www.microformats.dk/2014/01/02/mapproxy-tjenesten-af-geodatastyrelsens-luftfotos-virker-ogsa-til-id-editoren/

eller Potlatch 2 så læs  her
http://www.microformats.dk/2013/12/24/openstreetmap-potlatch-2-editor-kan-nu-ogsa-kalde-geodatastyrelsens-luftfotos/


vh
Søren Johannessen

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

Re: [Talk-dk] Til orientering - ny JOSM version 6502 og Geodatastyrelsens luftfotos

2014-01-13 Diskussionsfäden Michael Andersen

Hejsa

Jeg kører altid den nyeste udviklingsversion (som nu er 6673) og synes ikke 
jeg kan se det. Hvordan kommer jeg til det uden at ødelægge min nuværende 
konfiguration?

Mvh
Michael Andersen


Mandag den 13. januar 2014 20:51:41 skrev Soren Johannessen:
 Hej alle sammen
 
 Hvis du installerer den nye nye JOSM version 6502
 http://josm.openstreetmap.de/ Så når du redigerer i Danmark, vil du i
 JOSM under Billedlag  nu have muligheden for at vælge
 Geodatastyrelsen (Denmark) luftfotos direkte. Det er den mapproxy
 service som Gregers Petersen for et par uger siden satte op som nu
 optræder som et standardvalg til den nye JOSM version.
 
 NB - Hvis du bruger iD
 Læs guide her til Geodatastyrelsens luftfotos
 http://www.microformats.dk/2014/01/02/mapproxy-tjenesten-af-geodatastyrelsen
 s-luftfotos-virker-ogsa-til-id-editoren/
 
 eller Potlatch 2 så læs  her
 http://www.microformats.dk/2013/12/24/openstreetmap-potlatch-2-editor-kan-nu
 -ogsa-kalde-geodatastyrelsens-luftfotos/
 
 
 vh
 Søren Johannessen
 
 ___
 Talk-dk mailing list
 Talk-dk@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-dk

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

Re: [Talk-dk] Til orientering - ny JOSM version 6502 og Geodatastyrelsens luftfotos

2014-01-13 Diskussionsfäden Michael Andersen

Hej Søren

Nej, jeg kan stadig ikke se den. Jeg er formentlig nød til at slette min konfig 
fil for at få den opdateret og derefter bruge lidt tid på mine personlige 
preferencer igen. Suk.

Mandag den 13. januar 2014 22:18:10 skrev Soren Johannessen:
 Hej Michael
 
 Under Rediger Indstillinger WMS/TMS og på standardlisten ser du så
 det samme som i vedhæftet billede i din JOSM udvikler ? scroll lidt
 ned og  ser om ikke er der under DK og så Geodatastyrelsen (Denmark) -
 
 Hvis ja - så skulle den være automatisk på listen under Billedelag
 når du har vektor indhold fra Danmark inde -
 
 /Søren
 
 2014/1/13 Michael Andersen hj...@milvus.dk:
  Hejsa
  
  Jeg kører altid den nyeste udviklingsversion (som nu er 6673) og synes
  ikke
  jeg kan se det. Hvordan kommer jeg til det uden at ødelægge min nuværende
  konfiguration?
  
  Mvh
  Michael Andersen
  
  Mandag den 13. januar 2014 20:51:41 skrev Soren Johannessen:
  Hej alle sammen
  
  Hvis du installerer den nye nye JOSM version 6502
  http://josm.openstreetmap.de/ Så når du redigerer i Danmark, vil du i
  JOSM under Billedlag  nu have muligheden for at vælge
  Geodatastyrelsen (Denmark) luftfotos direkte. Det er den mapproxy
  service som Gregers Petersen for et par uger siden satte op som nu
  optræder som et standardvalg til den nye JOSM version.
  
  NB - Hvis du bruger iD
  Læs guide her til Geodatastyrelsens luftfotos
  http://www.microformats.dk/2014/01/02/mapproxy-tjenesten-af-geodatastyrel
  sen s-luftfotos-virker-ogsa-til-id-editoren/
  
  eller Potlatch 2 så læs  her
  http://www.microformats.dk/2013/12/24/openstreetmap-potlatch-2-editor-kan
  -nu -ogsa-kalde-geodatastyrelsens-luftfotos/
  
  
  vh
  Søren Johannessen
  
  ___
  Talk-dk mailing list
  Talk-dk@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-dk
  
  ___
  Talk-dk mailing list
  Talk-dk@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-dk

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

[Talk-dk] Stavefejl i den danske oversættelse på OSMs forside

2014-01-13 Diskussionsfäden Michael Andersen

Hej

Nu fik jeg lige øje på det igen (se vedlagte billedfil). Den slags ser ikke 
lige 
så professionelt ud (Ikke at vi nødvendigvis skal give indtryk af at være 
professionelle, men alligevel...), så hvordan bærer man sig ad med at rette 
det?

Mvh
  Michaelfilen øjebliksbillede1.png:
Originale billeder: øjebliksbillede1.png


attachment: image/png___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

[Talk-ar] (sin asunto)

2014-01-13 Diskussionsfäden correo

Finalmente han anunciado a Buenos Aires como sede del SotM 2014 global.[1]

Felicitaciones a todo el equipo de organización y a los geoinquietos!

Nos vemos en el trello[2] y pronto armamos un hangouts y reunión.

[1] http://blog.openstreetmap.org/2014/01/12/buenos-aires-hosts-sotm14
[2] https://trello.com/b/uzTbNlvW/state-of-the-map-2014




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

Re: [Talk-ar] (sin asunto)

2014-01-13 Diskussionsfäden Marcelo Aliaga

Abrazos y fuerza desde Chile! :)


2014/1/13 cor...@fernando.com.ar

 Finalmente han anunciado a Buenos Aires como sede del SotM 2014 global.[1]

 Felicitaciones a todo el equipo de organización y a los geoinquietos!

 Nos vemos en el trello[2] y pronto armamos un hangouts y reunión.

 [1] http://blog.openstreetmap.org/2014/01/12/buenos-aires-hosts-sotm14
 [2] https://trello.com/b/uzTbNlvW/state-of-the-map-2014




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




-- 
Ing. Marcelo Aliaga Quezada
marc...@aliaga.cl
___
Talk-ar mailing list
Talk-ar@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ar

[Talk-at] Relation in Kärnten

2014-01-13 Diskussionsfäden martin ringer

Ich habe in Kärnten eine Relation gefunden 
(http://www.openstreetmap.org/relation/2562011) bei der ich die Hilfe der 
Talk-Liste brauche.
Macht es Sinn so ein grosses Gebiet mit einer Relation zusammenzufassen und 
erst im zweiten Schritt sämtliche Flächen darin, die nicht Wald sind, 
herauszunehmen?
Ich finde das keine gute Idee, aber lasse mich gerne belehren.
  ___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] Baumstämme quer über den Weg

2014-01-13 Diskussionsfäden Christian Aigner

Hallo!

Bei einer Wanderung heute Nachmittag bin ich an eine Wegstelle gekommen,
wo ein Baum (Sturmschaden, abgebrochen) quer über dem Weg war. Die
Wanderer haben mittlerweile schon einen Ersatzweg rund herum getrampelt.

Irgendwann wird der Baumstamm sicher weg geräumt.

Frage: Soll in so einem Fall trotzdem die Wegführung geändert werden
und/oder eine Barriere eingezeichnet werden?

Wenn Barriere ja, dann welche?

LG,
Christian


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

Re: [Talk-at] Baumstämme quer über den Weg

2014-01-13 Diskussionsfäden Friedrich Volkmann


On 13.01.2014 19:33, Christian Aigner wrote:

Bei einer Wanderung heute Nachmittag bin ich an eine Wegstelle gekommen,
wo ein Baum (Sturmschaden, abgebrochen) quer über dem Weg war. Die
Wanderer haben mittlerweile schon einen Ersatzweg rund herum getrampelt.

Irgendwann wird der Baumstamm sicher weg geräumt.


Kommt darauf an wo. Um manche Wege, besonders im Hochgebirge, kümmern sich 
Wegemacher. Die räumen Hindernisse (Steine, Bäume) beiseite, beheben 
Erosionsschäden bzw. verlegen Wege so, dass künftig weniger Schäden 
auftreten. Es gibt aber auch viele Wege, um die sich keiner kümmert, oder 
nur ein Markierungswart, dem das Wegräumen von Hindernissen zu mühsam ist. 
Dort klettert man entweder übern Baumstamm drüber, oder (wenn noch zu viele 
Äste dran sind) man umgeht ihn. Auf der Hohen Wand kenne ich mindestens 2 
Stellen, wo die Umgehungen umgestürzter Bäume sogar markiert wurden.



Frage: Soll in so einem Fall trotzdem die Wegführung geändert werden
und/oder eine Barriere eingezeichnet werden?

Wenn Barriere ja, dann welche?


Wenn du glaubst, dass es nur vorübergehend ist, dann tu dir keine Mühe an. 
Vor allem weil die Mühe eine doppelte ist: Es muss nachher jemand zurückändern.


In Fällen, wo der Baum liegen bleibt, mappe ich ihn mitunter als barrier=log 
und/oder ich mappe den neuen Wegverlauf. Das hängt halt von der konkreten 
Situation ab und von der Lust auf Micromapping. So ein umgefallener Baum 
kann in einer Karte durchaus interessant sein, z.B. als Orientierungspunkt. 
Oder für Leute mit Kinderwagen als Kriterium, doch lieber die 
Alternativroute zu nehmen.


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

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

Re: [Talk-at] Baumstämme quer über den Weg

2014-01-13 Diskussionsfäden Andreas Labres

On 13.01.14 19:33, Christian Aigner wrote:
 Frage: Soll in so einem Fall trotzdem die Wegführung geändert werden
 und/oder eine Barriere eingezeichnet werden?
 Wenn Barriere ja, dann welche?

Wenn Du die Chance hast, das mitzukriegen, sobald der Baumstamm wieder entfernt
wurde, dann würde ich eine barrier=log machen.

Servus, Andreas

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

[Talk-ro] Raportul anual OpenStreetMap Romania 2013

2014-01-13 Diskussionsfäden Badita Florin

97% din totalul de Drumuri Nationale sunt adaugate in OpenStreetMap
89 % din totalul de Drumurile Judetene sunt adaugate in OpenStreetMap
28% din totalul de Drumuri Comunale sunt adaugate in OpenStreetMap
195,000 de kilometri de drumuri sunt adaugate in OSM, dintre care 73,000 au
fost adaugati in anul 2013
231,991 - Numarul de cladiri existente in OpenStreetMap. 47 % din ele fiind
adaugate in anul 2013

Mai multe statistici se pot gasi pe pagina de facebook OpenStreetMap
Romaniahttps://www.facebook.com/OsmRomania

https://www.facebook.com/OsmRomania/posts/263084250516429?stream_ref=10

O zi buna,
Badita Florin
___
Talk-ro mailing list
Talk-ro@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ro

Re: [Talk-ro] Raportul anual OpenStreetMap Romania 2013

2014-01-13 Diskussionsfäden Razvan


Deci anul 2013 a fost cel mai activ din multe puncte de evdere :D

Acum, problema drumurilor comunale si a celor judetene este ca, sunt 
desenate mult mai multe, dar nu sunt marcate ca atare, nu au ref toate...

On 13.01.2014 15:53, Badita Florin wrote:

97% din totalul de Drumuri Nationale sunt adaugate in OpenStreetMap
89 % din totalul de Drumurile Judetene sunt adaugate in OpenStreetMap
28% din totalul de Drumuri Comunale sunt adaugate in OpenStreetMap
195,000 de kilometri de drumuri sunt adaugate in OSM, dintre care 
73,000 au fost adaugati in anul 2013
231,991 - Numarul de cladiri existente in OpenStreetMap. 47 % din ele 
fiind adaugate in anul 2013


Mai multe statistici se pot gasi pe pagina de facebook OpenStreetMap 
Romania https://www.facebook.com/OsmRomania


https://www.facebook.com/OsmRomania/posts/263084250516429?stream_ref=10

O zi buna,
Badita Florin


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


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

[Talk-cz] Preklad wiki MapFeatures

2014-01-13 Diskussionsfäden Dalibor Jelínek

Ahoj,

pustil jsem se do prekladu wiki
http://wiki.openstreetmap.org/wiki/Cs:Map_Features

Puvodni preklad uz byl proveden docela davno a postupem casu toho hodne
chybelo,

nebo nektere veci byly uz i zavadejici a nepravdive.

Cilem bylo i krome otrockeho prekladu zohlednit nekde i ceska specifika,
pripadne

doplnit nejcastejsi useful combination tagy, ktere by sice idealne mely
byt popsane

v ceskych prekladech jednotlivych tagu, ale ty nejsou a asi hned tak
nebudou.

Tedy je to misty ukecane, ale snad k dobru veci.

 

Zatim jsem prosel:

-  highway

-  barrier

-  cycleway

-  tracktype

-  waterway

-  railway

-  aeroway

-  aerialway

-  power

-  man made

-  leisure

-  amenity

 

Byl bych rad, kdyby si to nekdo mohl precist a pripadne mi vytknout, co jsem
napsal spatne,

nebo doplnit dalsi informace, ktere me nenapadly.

 

Zdravi,

Dalibor

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

[Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

Dobrý den.

S nadšením jsem udělal pár editací OSM (stále se učím jak to dělat
kvalitně a správně). Používám pro editaci webový iD editor, který je
dostupný všude a bez instalace (i když na Atomu je trochu pomalý). Co
mne v tomto editoru chybí je přímá volba lepších leteckých podkladů.
Podklad Bing aerial pokud je dostupný tak je mdlý a hlavně posunutý
(alespoň tam, kde jsem se v ČR díval).

Slušné letecké mapy jsou k dispozici u ČUZK. Například z WMS mapové
služby:
http://geoportal.cuzk.cz/WMS_ORTOFOTO_PUB/WMService.aspx?service=WMSrequest=getCapabilities
lze (technicky) (při vhodných volbách) získat mapové dlaždice ve stylu
OSM.

K dispozici je přímo i dlaždicová služba WMTS viz:
http://geoportal.cuzk.cz/WMTS_ORTOFOTO/WMTService.aspx?service=WMTSrequest=GetCapabilities
Ale ta kupodivu se jeví méně kvalitní než služba WMS a dokonce i
pomalejší a asi je i méně aktuální. Ve webovém editoru iD pokud zadám
mapový podklad Vlastní a vložím url:
http://geoportal.cuzk.cz/WMTS_ORTOFOTO_900913/service.svc/get?SERVICE=WMTSREQUEST=GetTileVERSION=1.0.0LAYER=ortoSTYLE=defaultTILEMATRIXSET=googlemapscompatibleext2:epsg:3857TILEMATRIX={z}TILECOL={x}TILEROW={y}FORMAT=image%2Fjpg
tak to funguje (někdy), ale velmi pomalu.

Mé dotazy:
Je možné (legální) využívat letecké mapy, které na uvedených službách
ČUZK poskytuje pro editaci OSM map?
Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD
editoru nabízena přímo ČUZK letecká mapa?
Existují nějaké další mapové podklady ČR a s nimi spojené služby, které
by se daly využít jako podklad pro editaci OSM map a které by bylo možné
přímo doplnit v iD editoru do výběru vrstev?

Mít kvalitní podklad pro editaci map OSM na území ČR přímo ve webovém iD
editoru by bylo úžasné...

Zdraví
Marek Chlup


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

Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

2014-01-13 Diskussionsfäden Libor Pechacek

Ahoj Marku,

On Mon 13-01-14 15:18:27, Marek Chlup wrote:
 Mé dotazy:
 Je možné (legální) využívat letecké mapy, které na uvedených službách
 ČUZK poskytuje pro editaci OSM map?

Nikoli.  Viz 
http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje

 Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD
 editoru nabízena přímo ČUZK letecká mapa?

Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
konference.

HTH,
Libor

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

Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

Děkuji za odpověď.

ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na
dokument:
http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf
ten pak zmiňuje například vyhlášku č. 103/2010 Sb.:
http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf
Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko
posuzují (přiznám se, že i ODbL nechápu detailně)...

Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS
katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na
některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych
přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat
přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně
obrátit (aby to bylo zakomponováno do nabídky iD editoru)?

Zdraví
Marek Chlup

On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote:
Ahoj Marku,

On Mon 13-01-14 15:18:27, Marek Chlup wrote:
Mé dotazy:
Je možné (legální) využívat letecké mapy, které na uvedených službách
ČUZK poskytuje pro editaci OSM map?

Nikoli. Viz
http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje

Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD
editoru nabízena přímo ČUZK letecká mapa?

Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
konference.

HTH,
Libor

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

Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

2014-01-13 Diskussionsfäden Jan Vršovský

Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá:

https://github.com/osmlab/editor-imagery-index

Honza Vršovský



-- Původní zpráva --
Od: Marek Chlup m...@chlup.net
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

Děkuji za odpověď.

ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na
dokument:
http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf
ten pak zmiňuje například vyhlášku č. 103/2010 Sb.:
http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf
Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko
posuzují (přiznám se, že i ODbL nechápu detailně)...

Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS
katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na
některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych
přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat
přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně
obrátit (aby to bylo zakomponováno do nabídky iD editoru)?

Zdraví
Marek Chlup


On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote:
 Ahoj Marku,
 
 On Mon 13-01-14 15:18:27, Marek Chlup wrote:
  Mé dotazy:
  Je možné (legální) využívat letecké mapy, které na uvedených službách
  ČUZK poskytuje pro editaci OSM map?
 
 Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/
freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje
 
  Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD
  editoru nabízena přímo ČUZK letecká mapa?
 
 Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
 Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
 konference.
 
 HTH,
 Libor
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-cz] RUIAN nad OSM

2014-01-13 Diskussionsfäden Petr Vejsada

Také všechny zdravím,

Dne Po 13. ledna 2014 07:53:55, JV napsal(a):

 Zdravím všechny,
 ad artefakty - to není chyba, ale zcela legální stav. Je potřeba si
 uvědomit, že katastrální mapa *není* technická mapa a že do 31.12.2013
 budova a pozemek pod ní byly dvě nemovitosti (a u nemovitostí, existujících
 před 1.1.2014 to bude i nadále, pokud se vlastnické poměry liší - velice

rozumím, že katastrální mapa je mapa  právní a že tedy neodráží realitu, ale 
právní stav.  Opakovaně narážím na stav (RUIAN), o kterém si myslím, že nikdy 
nebyl stavem skutečným ani stavem právním. Je to v případech, kdy leží třeba 3 
budovy na sobě

https://ruian.poloha.net/20/50.08934/14.46915 - rozsviťte si overlay budov a 
je to dokonce vidět, jak ta překryvná vrstva má jinou barvu na budově 
Biskupcova 347/12. Biskupcova 14 a 16 ovšem chybí. Tedy nechybí, ale leží na 
Biskupcově 12. To není zdaleka jediný případ. Tento konkrétní případ vypadá v 
RUIAN takto:

  kod| budova_id | cisla_domovni
--+---+---
 21695270 | 884184101 | {347}
 21695547 | 884184101 | {382}
 21696519 | 884184101 | {501}


Zrovna tyto případy není nutné složitě hledat; postačil by vhodně zvolený 
dotaz do databáze.


Dalším ne zcela vzácným jevem je výskyt budovy na místě vnitrobloku:

https://ruian.poloha.net/20/50.08313/14.42040

přičemž v místě, kde budova má být, tak není. Vypadá to na nějakou zavlečenou 
chybu, nevím.

Mohu třeba tyto výskyty někam hlásit, pokud by to mělo skutečně smysl.

--
Petr

 zjednodušeně řečeno). Zrovna v těch Pardubicích to znamená, že budova je
 Ministerstva obrany (http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/46757481;
 - tlačítko Údaje o vlastnictví otevře Nahlížení do KN se zvýrazněným
 obvodem budovy), ale pozemky pod ní jsou částečně i města (to je ten
 hnusný artefakt).
 Netvrdím, že v katastru nejsou chyby - ale vždy je mít na paměti výše
 uvedené a že katastr eviduje *právní* stav. Tedy pokud v terénu již nějaká
 budova není, může se v katastru i nadále zobrazovat, protože nikdo tu změnu
 neohlásil. A aby to bylo ještě složitější, zrovna cesta k odstranění budovy
 začíná na stavebním úřadu a teprve následně je možné to oznámit katastru.
 
 J. Veselý
 
 
 -- Původní zpráva --
 Od: Petr Morávek [Xificurk] p...@pada.cz
 Datum: 11. 1. 2014
 Předmět: Re: [Talk-cz] RUIAN nad OSM
 
 Dne 11.1.2014 09:27, Marián Kyral napsal(a):
  Ad import budov)
  Kromě toho, že některé budovy v RUIAN chybí, jsou i takové, které
  přebývají.
  Třeba ulice Na Poříčí, mezi vlakovým a autobusovým nádražím. Tam je
  obrovská
  parcela, kde sice byly budovy, ale před několika lety je srovnali se zemí
  a teď tam roste jen tráva. Pokud by jsi provedl automatický import, budovy
  by se opět objevily. Asi bych se prvně zaměřil na místa, kde zatím není
  vůbec nic. Tam to pak stejně musí někdo znalý revidovat.
  
  Případně, bylo by možné udělat něco na způsob traceru? Tedy, že kliknu do
  mapy v místě, kde je nějaká budova, plugin se spojí s nějakým serverem a
  vrátí
  tvar budovy z RUIAN. Taky by tam mohla být volba Importuj vše v okolí
 
 pro
 
  místa, kde ještě vůbec nic není. Ať to není třeba dělat po jedné.
 
 Ahoj,
 
 bohužel kvalita budov v RUIAN není nijak dobrá. Já jsem narazil na to,
 že některá (části) budov jsou označeny jen jako zastavěná plocha a
 naopak zastavěné plochy jsou označeny jako budova. Navíc se občas objeví
 docela hnusné artefakty přímo v geometriích.
 
 http://maps.fordfrog.com/?zoom=17lat=50.02363lon=15.77651layers=B00FFF
 http://mapy.cz/#!x=15.774797y=50.023553z=15l=15
 
 Pokud tedy bude opravdu nějaký import budov probíhat, tak rozhodně
 nemůže být automatický, spíš opravdu něco na styl traceru.
 
 Zdraví,
 Petr Morávek aka Xificurk
 
 ___
 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-cz] iD editor a mapový podklad ČÚZK ortofoto

Hmm. Tady:
https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/CzechCUZKKM.json
je dokonce definice pro KM.

Marek

On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský wrote:
Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá:

https://github.com/osmlab/editor-imagery-index

Honza Vršovský

-- Původní zpráva --
Od: Marek Chlup m...@chlup.net
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

Děkuji za odpověď.

Zdraví
Marek Chlup

On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote:
Ahoj Marku,

On Mon 13-01-14 15:18:27, Marek Chlup wrote:
Mé dotazy:
Je možné (legální) využívat letecké mapy, které na uvedených službách
ČUZK poskytuje pro editaci OSM map?

Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/
freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje

Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém iD
editoru nabízena přímo ČUZK letecká mapa?

Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
konference.

HTH,
Libor

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

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

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

Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

2014-01-13 Diskussionsfäden Jan Vršovský

Aha, nojo, teď koukám, že iD nepodporuje WMS zdroje (umí zatím jen TMS a 
Bing), takže proto to KM nenabízí.
Než to někdo vyřeší (https://github.com/openstreetmap/iD/issues/1141), tak 
to lze řešit prostřednictvím proxy (http://whoots.mapwarper.net/).
Stačí zvolit v iD vlastní pozadí a zadat tam např.

http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/parcelni_cisla,obrazy_parcel,
RST_KMD,hranice_parcel,DEF_BUDOVY,RST_KN,dalsi_p_mapy,prehledka_kat_prac,
prehledka_kat_uz,prehledka_kraju-linie/http://services.cuzk.cz/wms/wms.asp

Honza


-- Původní zpráva --

Od: Marek Chlup m...@chlup.net
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

Hmm. Tady:
https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/
CzechCUZKKM.json
je dokonce definice pro KM.

Marek


On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský wrote:
 Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá:
 
 https://github.com/osmlab/editor-imagery-index
 
 Honza Vršovský
 
 
 
 -- Původní zpráva --
 Od: Marek Chlup m...@chlup.net
 Datum: 13. 1. 2014
 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
 
 Děkuji za odpověď.
 
 ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na
 dokument:
 http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf
 ten pak zmiňuje například vyhlášku č. 103/2010 Sb.:
 http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf
 Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko
 posuzují (přiznám se, že i ODbL nechápu detailně)...
 
 Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS
 katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na
 některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych
 přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat
 přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně
 obrátit (aby to bylo zakomponováno do nabídky iD editoru)?
 
 Zdraví
 Marek Chlup
 
 
 On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote:
  Ahoj Marku,
  
  On Mon 13-01-14 15:18:27, Marek Chlup wrote:
   Mé dotazy:
   Je možné (legální) využívat letecké mapy, které na uvedených 
službách
   ČUZK poskytuje pro editaci OSM map?
  
  Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_
Republic/
 freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje
  
   Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém 
iD
   editoru nabízena přímo ČUZK letecká mapa?
  
  Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
  Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
  konference.
  
  HTH,
  Libor
  
  ___
  Talk-cz mailing list
  Talk-cz@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-cz
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz;

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


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

Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto

Děkuji. S tím proxy to funguje.

Takže zřejmě až bude iD umět WMS zdroje tak asi do nabídky mapových
podkladů spadne výběr katastrálních map automaticky.

Mimochodem help v iD zřejmě předběhl dobu jelikož v sekci helpu
Podkladové snímky je text:
... Pro velkou část České republiky jsou také dostupné velmi detailní
satelitní snímky a navíc data z katastru nemovitostí.

iD mne každopádně fascinuje co vše je již možné v prohlížeči čistě na
bázi HTML/JavaScript realizovat (až na tu pomalost na Atom je super).

Marek


On Mon, Jan 13, 2014 at 09:52:00PM +0100, Jan Vršovský wrote:
 Aha, nojo, teď koukám, že iD nepodporuje WMS zdroje (umí zatím jen TMS a 
 Bing), takže proto to KM nenabízí.
 Než to někdo vyřeší (https://github.com/openstreetmap/iD/issues/1141), tak 
 to lze řešit prostřednictvím proxy (http://whoots.mapwarper.net/).
 Stačí zvolit v iD vlastní pozadí a zadat tam např.
 
 http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/parcelni_cisla,obrazy_parcel,
 RST_KMD,hranice_parcel,DEF_BUDOVY,RST_KN,dalsi_p_mapy,prehledka_kat_prac,
 prehledka_kat_uz,prehledka_kraju-linie/http://services.cuzk.cz/wms/wms.asp
 
 Honza
 
 
 -- Původní zpráva --
 
 Od: Marek Chlup m...@chlup.net
 Datum: 13. 1. 2014
 Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
 
 Hmm. Tady:
 https://github.com/osmlab/editor-imagery-index/blob/gh-pages/sources/europe/
 CzechCUZKKM.json
 je dokonce definice pro KM.
 
 Marek
 
 
 On Mon, Jan 13, 2014 at 08:13:05PM +0100, Jan Vršovský wrote:
  Ahoj, myslím, že nejlíp přes databázi podkladů, které iD používá:
  
  https://github.com/osmlab/editor-imagery-index
  
  Honza Vršovský
  
  
  
  -- Původní zpráva --
  Od: Marek Chlup m...@chlup.net
  Datum: 13. 1. 2014
  Předmět: Re: [Talk-cz] iD editor a mapový podklad ČÚZK ortofoto
  
  Děkuji za odpověď.
  
  ČÚZK u ORTOFOTO odkazuje pokud jde o podmínky poskytování (a i užití) na
  dokument:
  http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf
  ten pak zmiňuje například vyhlášku č. 103/2010 Sb.:
  http://inspire.gov.cz/sites/default/files/documents/103_2010.pdf
  Chvíli jsem si to pročítal, ale kolize s licencí ODbL se mi těžko
  posuzují (přiznám se, že i ODbL nechápu detailně)...
  
  Každopádně děkuji za odkaz na wiki. Díval jsem se zejména na WMS
  katastrální mapy, které jsou hodnoceny jako zdroj dat v pořádku. Na
  některé záležitosti jde i o lepší zdroj než ORTOFOTO. Tedy velmi bych
  přivítal, kdyby bylo možné v iD editoru na openstreetmap.org vybrat
  přímo vrstvu ČÚZK Katastrální mapy. Kam se s takovou prosbou dá vhodně
  obrátit (aby to bylo zakomponováno do nabídky iD editoru)?
  
  Zdraví
  Marek Chlup
  
  
  On Mon, Jan 13, 2014 at 03:42:51PM +0100, Libor Pechacek wrote:
   Ahoj Marku,
   
   On Mon 13-01-14 15:18:27, Marek Chlup wrote:
Mé dotazy:
Je možné (legální) využívat letecké mapy, které na uvedených 
 službách
ČUZK poskytuje pro editaci OSM map?
   
   Nikoli. Viz http://wiki.openstreetmap.org/wiki/WikiProject_Czech_
 Republic/
  freemap#Ov.C4.9B.C5.99ovac.C3.AD_zdroje
   
Co je třeba udělat (kam se obrátit), aby v oblasti ČR byla ve webovém 
 iD
editoru nabízena přímo ČUZK letecká mapa?
   
   Jak tomu rozumím, především svolení vlastníka s použitím ortofota v OSM.
   Myslím, že nějaké pokusy o získání souhlasu byly, podívej se do archivu
   konference.
   
   HTH,
   Libor
   
   ___
   Talk-cz mailing list
   Talk-cz@openstreetmap.org
   https://lists.openstreetmap.org/listinfo/talk-cz
  
  ___
  Talk-cz mailing list
  Talk-cz@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-cz;
 
  ___
  Talk-cz mailing list
  Talk-cz@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-cz
 
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz;

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


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

Re: [Talk-cz] RUIAN nad OSM

2014-01-13 Diskussionsfäden JV

Dobrý den,
ano, většinou to jsou chyby. U některých typů probíhají kontroly a 
katastrální pracoviště to postupně opravují. Tu možnost hlášení zjistím.

J. Veselý


-- Původní zpráva --
Od: Petr Vejsada o...@propsychology.cz
Datum: 13. 1. 2014
Předmět: Re: [Talk-cz] RUIAN nad OSM

Také všechny zdravím,

Dne Po 13. ledna 2014 07:53:55, JV napsal(a):

 Zdravím všechny,
 ad artefakty - to není chyba, ale zcela legální stav. Je potřeba si
 uvědomit, že katastrální mapa *není* technická mapa a že do 31.12.2013
 budova a pozemek pod ní byly dvě nemovitosti (a u nemovitostí, 
existujících
 před 1.1.2014 to bude i nadále, pokud se vlastnické poměry liší - velice

rozumím, že katastrální mapa je mapa právní a že tedy neodráží realitu, ale 
právní stav. Opakovaně narážím na stav (RUIAN), o kterém si myslím, že nikdy

nebyl stavem skutečným ani stavem právním. Je to v případech, kdy leží třeba
3 
budovy na sobě

https://ruian.poloha.net/20/50.08934/14.46915 - rozsviťte si overlay budov a

je to dokonce vidět, jak ta překryvná vrstva má jinou barvu na budově 
Biskupcova 347/12. Biskupcova 14 a 16 ovšem chybí. Tedy nechybí, ale leží na

Biskupcově 12. To není zdaleka jediný případ. Tento konkrétní případ vypadá 
v 
RUIAN takto:

kod | budova_id | cisla_domovni
--+---+---
21695270 | 884184101 | {347}
21695547 | 884184101 | {382}
21696519 | 884184101 | {501}


Zrovna tyto případy není nutné složitě hledat; postačil by vhodně zvolený 
dotaz do databáze.


Dalším ne zcela vzácným jevem je výskyt budovy na místě vnitrobloku:

https://ruian.poloha.net/20/50.08313/14.42040

přičemž v místě, kde budova má být, tak není. Vypadá to na nějakou 
zavlečenou 
chybu, nevím.

Mohu třeba tyto výskyty někam hlásit, pokud by to mělo skutečně smysl.

--
Petr

 zjednodušeně řečeno). Zrovna v těch Pardubicích to znamená, že budova je
 Ministerstva obrany (http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/
46757481
 - tlačítko Údaje o vlastnictví otevře Nahlížení do KN se zvýrazněným
 obvodem budovy), ale pozemky pod ní jsou částečně i města (to je ten
 hnusný artefakt).
 Netvrdím, že v katastru nejsou chyby - ale vždy je mít na paměti výše
 uvedené a že katastr eviduje *právní* stav. Tedy pokud v terénu již nějaká
 budova není, může se v katastru i nadále zobrazovat, protože nikdo tu 
změnu
 neohlásil. A aby to bylo ještě složitější, zrovna cesta k odstranění 
budovy
 začíná na stavebním úřadu a teprve následně je možné to oznámit katastru.
 
 J. Veselý
 
 
 -- Původní zpráva --
 Od: Petr Morávek [Xificurk] p...@pada.cz
 Datum: 11. 1. 2014
 Předmět: Re: [Talk-cz] RUIAN nad OSM
 
 Dne 11.1.2014 09:27, Marián Kyral napsal(a):
  Ad import budov)
  Kromě toho, že některé budovy v RUIAN chybí, jsou i takové, které
  přebývají.
  Třeba ulice Na Poříčí, mezi vlakovým a autobusovým nádražím. Tam je
  obrovská
  parcela, kde sice byly budovy, ale před několika lety je srovnali se 
zemí
  a teď tam roste jen tráva. Pokud by jsi provedl automatický import, 
budovy
  by se opět objevily. Asi bych se prvně zaměřil na místa, kde zatím není
  vůbec nic. Tam to pak stejně musí někdo znalý revidovat.
  
  Případně, bylo by možné udělat něco na způsob traceru? Tedy, že kliknu 
do
  mapy v místě, kde je nějaká budova, plugin se spojí s nějakým serverem a
  vrátí
  tvar budovy z RUIAN. Taky by tam mohla být volba Importuj vše v okolí
 
 pro
 
  místa, kde ještě vůbec nic není. Ať to není třeba dělat po jedné.
 
 Ahoj,
 
 bohužel kvalita budov v RUIAN není nijak dobrá. Já jsem narazil na to,
 že některá (části) budov jsou označeny jen jako zastavěná plocha a
 naopak zastavěné plochy jsou označeny jako budova. Navíc se občas objeví
 docela hnusné artefakty přímo v geometriích.
 
 http://maps.fordfrog.com/?zoom=17lat=50.02363lon=15.77651layers=B00FFF
 http://mapy.cz/#!x=15.774797y=50.023553z=15l=15
 
 Pokud tedy bude opravdu nějaký import budov probíhat, tak rozhodně
 nemůže být automatický, spíš opravdu něco na styl traceru.
 
 Zdraví,
 Petr Morávek aka Xificurk
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-cz;

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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014-01-13 Diskussionsfäden HELFER Denis

Pour déterminer les règles d’usage, vous pouvez vous servir de la page wiki ad 
hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos, 
l’import de l’opendata mulhousien avance bien. Bravo eiger

Denis

De : Matthias Dietrich [mailto:eiger@gmail.com]
Envoyé : samedi 11 janvier 2014 18:54
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ?

Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft 
jb.holcr...@gmail.commailto:jb.holcr...@gmail.com a écrit :

Quelle est la règle actuelle ?
REF:FR:M2A ?
Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir 
ref:FR:M2A.
Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de 
référence. Les stations Vélocité ont été importées depuis plus longtemps à 
partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro 
de station. La plupart des autres objets n'ont pas de d'identifiant.
Pour parler concrètement : est-ce que tu souhaites procéder à l'import des 
arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs 
disponibles (diamètre de la couronne, etc.).

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

Re: [OSM-talk-fr] Bâtiments se chevauchant

2014-01-13 Diskussionsfäden lenny



Le 13/01/2014 07:43, Jean-Francois Nifenecker a écrit : Le 12/01/2014 
21:18, didier2020 a écrit :

Le dimanche 12 janvier 2014 à 20:20 +0100, lenny a écrit :

- des Bâtiments se chevauchant

- des Bâtiments à l'intérieur d'un autre

pour ces mini erreurs, j'utilise un script qui les corrige
automatiquement. (je le fais regulierement sur la france)

je ne connaissais pas. Je regarde ça...


Il y a aussi un Osmecum :
http://wiki.openstreetmap.org/w/images/2/2d/Osmecum_integration_bati_v020.pdf

Mes 2 euro-cents,
Merci à tous les deux, ça fonctionne, j'ai corrigé et j'ai encore de la 
lecture.

Cette liste est vraiment une mine !!!
Lenny

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

Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname

2014-01-13 Diskussionsfäden Frédéric Rodrigo

Le 12 janvier 2014 23:37, Christian Quest cqu...@openstreetmap.fr a écrit
:

 184... c'est le nombre d'abréviations dans la colonne nature_voie de
 FANTOIR

 Pour certaines, j'ai du mal à trouver la correspondance, si vous voulez
 m'aider, c'est ici:

 https://docs.google.com/spreadsheet/ccc?key=0AkurI9Y66dXNdHVDRnNtNFk2TVlBUDdvRURIWmNDM1E

 Ensuite, je vais regarder les abréviation dans le nom de voies
 (GAL=Général MAL=Maréchal, etc).


Il me semble avoir déjà vu la liste dans une des doc du fantoir/rivoli
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014-01-13 Diskussionsfäden Pierre Knobel

Pour en revenir à l'image du taux de couverture, il y a un nombre
significatif de village que je pense avoir complété avec toutes les
adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en
vert clair (60-80%). Un exemple : Lembach, tout au nord de la région.
Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès
était plus complète que celle qu'on peut télécharger avec le plugin de JOSM
cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros,
parfois tout un côté de la rue, mais je pensais que ces données étaient
complètement absentes de la base cadastrale.


2014/1/13 HELFER Denis denis.hel...@rff.fr

  Pour déterminer les règles d’usage, vous pouvez vous servir de la page
 wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A
 ce propos, l’import de l’opendata mulhousien avance bien. Bravo eiger



 Denis



 *De :* Matthias Dietrich [mailto:eiger@gmail.com]
 *Envoyé :* samedi 11 janvier 2014 18:54
 *À :* Discussions sur OSM en français
 *Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ?



 Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com
 a écrit :

 Quelle est la règle actuelle ?
 REF:FR:M2A ?

 Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir
 ref:FR:M2A.

 Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de
 référence. Les stations Vélocité ont été importées depuis plus longtemps à
 partir des fichiers mis à disposition par JCDecaux, avec un simple
 ref=numéro de station. La plupart des autres objets n'ont pas de
 d'identifiant.

 Pour parler concrètement : est-ce que tu souhaites procéder à l'import des
 arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs
 disponibles (diamètre de la couronne, etc.).



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


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

Re: [OSM-talk-fr] données douteuses

2014-01-13 Diskussionsfäden claude marani

Bonjour

Contacté début décembre, reçu aucune réponse

cordialement
Claude


Le 7 décembre 2013 23:39, Christian Quest cqu...@openstreetmap.fr a écrit
:

 Tu contacte le contributeur...


 Le 7 décembre 2013 23:29, Claude claude.mar...@gmail.com a écrit :

 Bonsoir
 En faisant des mise à jours du coté de Briennon (42) je suis tombé sur
 une routes départementale avec un tag name=La Bourbasse. J'avais pas
 encore vu de départementale avec un nom comme ca mais pourquoi pas. En
 continuant mes tracé, j'en ai trouvé plein d'autre et ça m'a fais
 penser
 à Google Map. je suis allé vérifier Je pense que c'est bien ça.
 c'est flagrant ici
 http://osm.org/go/0AnsCL~I
 la D35 est coupé exactement au même point que sur Google Map et les
 nom
 sont identiques
 Que doit-je faire, je supprime les name?
 cordialement
 Claude

 --
  Envoyé avec Mozilla Thunderbird ---


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




 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

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


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

Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname

FANTOIR... où comment se cultiver...

La recherche de la rue Richepance (Paris 1er):
http://openstreetmap.fr/blogs/cquest/fantoir-et-culture-generale

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

Re: [OSM-talk-fr] données douteuses

Bizarre en effet...

Pas de BOURBASSE à Briennon dans FANTOIR...
http://openstreetmap.fr/outils/adresses?insee=42026

Par contre, on trouve des adresses comme une menuiserie au 7 La
Bourbasse...


Le 13 janvier 2014 12:28, claude marani claude.mar...@gmail.com a écrit :

 Bonjour

 Contacté début décembre, reçu aucune réponse

 cordialement
 Claude



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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014-01-13 Diskussionsfäden HELFER Denis

Plusieurs éléments de réponse :

· La base cadastrale sur laquelle je me suis appuyé contient plus 
d'éléments que de réelles adresses. J'avais empiriquement pris uniquement 92% 
de ce résultat pour tenir compte de cas particuliers que j'avais repéré : poste 
de transformation électrique qui avait une adresse, adresses placées alors 
qu'aucun bâtiment n'existe (cas dans des lotissements où l'adresse est 
prévisible), hangars agricoles avec adresse, etc.

· L'ensemble des adresses n'est pas affiché sur le plan cadastral. 
Parfois, il faut aller sur le site du cadastre, choisir une parcelle et 
afficher les informations. Il faut donc jongler entre JOSM et le cadastre à 
moins qu'une développeur fou ne nous permette de remonter l'info dans JOSM. Une 
bière (ou plus si affinités) à la clé !

· Comme déjà évoqué, il ne faut pas prendre les chiffres à la lettre 
(elle est bonne celle là ;-) Il s'agit plutôt d'un indicateur que l'on pourrait 
remplacer par : rien, un tout petit peu, un petit peu, un peu, pas mal, 
vraiment beaucoup, top moumoute. Prochaine version.

· Il faut tenir compte que la base de comparaison commence à dater un 
peu et fausse encore plus les calculs

· Enfin, il faut repasser régulièrement sur les communes, au moins 
annuellement. Les plans cadastraux évoluent pas mal surtout s'ils sont 
vectorisés.

Pour le cas particulier de Lembach, il y a une centaine d'adresses attribut de 
bâti qui ne sont pas comptées sur Pfaffenbronn (je ne compte que les points par 
pure fainéantise). Sur la rue André Maginot, tu peux raisonnablement interpoler 
les n°11 et 13. L'impasse des Noyers a 6 adresses, etc.
Tu dois pouvoir basculer très rapidement dans la catégorie « pas mal » voire 
même « vraiment beaucoup ».
Je referai une analyse début février.

Denis

De : Pierre Knobel [mailto:pierr...@gmail.com]
Envoyé : lundi 13 janvier 2014 11:58
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ?

Pour en revenir à l'image du taux de couverture, il y a un nombre significatif 
de village que je pense avoir complété avec toutes les adresses que j'arrive à 
distinguer sur le cadastre mais qui apparaissent en vert clair (60-80%). Un 
exemple : Lembach, tout au nord de la région. Est-ce que ça veut dire que la 
base cadastrale à laquelle tu avais accès était plus complète que celle qu'on 
peut télécharger avec le plugin de JOSM cadastre-fr ? J'ai remarqué qu'il 
manquait un certain nombre de numéros, parfois tout un côté de la rue, mais je 
pensais que ces données étaient complètement absentes de la base cadastrale.

2014/1/13 HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr
Pour déterminer les règles d'usage, vous pouvez vous servir de la page wiki ad 
hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos, 
l'import de l'opendata mulhousien avance bien. Bravo eiger

Denis

De : Matthias Dietrich [mailto:eiger@gmail.commailto:eiger@gmail.com]
Envoyé : samedi 11 janvier 2014 18:54
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ?

Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft 
jb.holcr...@gmail.commailto:jb.holcr...@gmail.com a écrit :

Quelle est la règle actuelle ?
REF:FR:M2A ?
Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir 
ref:FR:M2A.
Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de 
référence. Les stations Vélocité ont été importées depuis plus longtemps à 
partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro 
de station. La plupart des autres objets n'ont pas de d'identifiant.
Pour parler concrètement : est-ce que tu souhaites procéder à l'import des 
arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs 
disponibles (diamètre de la couronne, etc.).


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

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

Re: [OSM-talk-fr] données douteuses

2014-01-13 Diskussionsfäden claude marani

Bonjour
Il y a un lieu dit La Bourbasse.à Briennon (source base Hexavia)



Le 13 janvier 2014 12:44, Christian Quest cqu...@openstreetmap.fr a écrit
:

 Bizarre en effet...

 Pas de BOURBASSE à Briennon dans FANTOIR...
 http://openstreetmap.fr/outils/adresses?insee=42026

 Par contre, on trouve des adresses comme une menuiserie au 7 La
 Bourbasse...


 Le 13 janvier 2014 12:28, claude marani claude.mar...@gmail.com a écrit
 :

 Bonjour

 Contacté début décembre, reçu aucune réponse

 cordialement
 Claude



 --
 Christian Quest - OpenStreetMap France

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


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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014-01-13 Diskussionsfäden Pierre Knobel

D'accord, donc dans ce cas particuliers ça s'explique bien par la quantité
d'adresses placées sur le bâti (Pfafenbronn et aussi Mattstall). Pour les
autres villages il va falloir que je jette un deuxième coup d'oeil,
l'explication des adresses sur polygones ne fonctionne que pour Lembach ;-)
http://tools.geofabrik.de/osmi/?view=addresseslon=7.74758lat=48.94608zoom=12overlays=buildings_with_addresses,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,nearest_roads

Autre question : Est-ce qu'on a une technique pour les villages qui n'ont
pas de cadastre vectoriel (Dambach) ?

2014/1/13 HELFER Denis denis.hel...@rff.fr

Plusieurs éléments de réponse :

· La base cadastrale sur laquelle je me suis appuyé contient plus
d’éléments que de réelles adresses. J’avais empiriquement pris uniquement
92% de ce résultat pour tenir compte de cas particuliers que j’avais
repéré : poste de transformation électrique qui avait une adresse, adresses
placées alors qu’aucun bâtiment n’existe (cas dans des lotissements où
l’adresse est prévisible), hangars agricoles avec adresse, etc.

· L’ensemble des adresses n’est pas affiché sur le plan
cadastral. Parfois, il faut aller sur le site du cadastre, choisir une
parcelle et afficher les informations. Il faut donc jongler entre JOSM et
le cadastre à moins qu’une développeur fou ne nous permette de remonter
l’info dans JOSM. Une bière (ou plus si affinités) à la clé !

· Comme déjà évoqué, il ne faut pas prendre les chiffres à la
lettre (elle est bonne celle là ;-) Il s’agit plutôt d’un indicateur que
l’on pourrait remplacer par : rien, un tout petit peu, un petit peu, un
peu, pas mal, vraiment beaucoup, top moumoute. Prochaine version.

· Il faut tenir compte que la base de comparaison commence à
dater un peu et fausse encore plus les calculs

· Enfin, il faut repasser régulièrement sur les communes, au
moins annuellement. Les plans cadastraux évoluent pas mal surtout s’ils
sont vectorisés.

Pour le cas particulier de Lembach, il y a une centaine d’adresses
attribut de bâti qui ne sont pas comptées sur Pfaffenbronn (je ne compte
que les points par pure fainéantise). Sur la rue André Maginot, tu peux
raisonnablement interpoler les n°11 et 13. L’impasse des Noyers a 6
adresses, etc.

Tu dois pouvoir basculer très rapidement dans la catégorie « pas mal »
voire même « vraiment beaucoup ».

Je referai une analyse début février.

Denis

*De :* Pierre Knobel [mailto:pierr...@gmail.com]
*Envoyé :* lundi 13 janvier 2014 11:58

*À :* Discussions sur OSM en français
*Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ?

Pour en revenir à l'image du taux de couverture, il y a un nombre
significatif de village que je pense avoir complété avec toutes les
adresses que j'arrive à distinguer sur le cadastre mais qui apparaissent en
vert clair (60-80%). Un exemple : Lembach, tout au nord de la région.
Est-ce que ça veut dire que la base cadastrale à laquelle tu avais accès
était plus complète que celle qu'on peut télécharger avec le plugin de JOSM
cadastre-fr ? J'ai remarqué qu'il manquait un certain nombre de numéros,
parfois tout un côté de la rue, mais je pensais que ces données étaient
complètement absentes de la base cadastrale.

2014/1/13 HELFER Denis denis.hel...@rff.fr

Pour déterminer les règles d’usage, vous pouvez vous servir de la page
wiki ad hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A
ce propos, l’import de l’opendata mulhousien avance bien. Bravo eiger

Denis

*De :* Matthias Dietrich [mailto:eiger@gmail.com]
*Envoyé :* samedi 11 janvier 2014 18:54
*À :* Discussions sur OSM en français
*Objet :* Re: [OSM-talk-fr] combien d'adresses en Alsace ?

Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft jb.holcr...@gmail.com
a écrit :

Quelle est la règle actuelle ?
REF:FR:M2A ?

Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir
ref:FR:M2A.

Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de
référence. Les stations Vélocité ont été importées depuis plus longtemps à
partir des fichiers mis à disposition par JCDecaux, avec un simple
ref=numéro de station. La plupart des autres objets n'ont pas de
d'identifiant.

Pour parler concrètement : est-ce que tu souhaites procéder à l'import des
arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs
disponibles (diamètre de la couronne, etc.).

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

Re: [OSM-talk-fr] Raildar OSM

2014-01-13 Diskussionsfäden Ab_fab

Bonjour Pierre,

Je ne connais pas toutes les subtilités des tags dans ce domaine, mais en
regardant certaines gares parisiennes, j'ai décelé quelques noeuds taggués
comme suit :

public_transport = stop_position
train = yes


Selon [1] il est possible d'ajouter un numéro de référence, du genre (pour
la voie N°3)

ref = 3


Il y a également des mentions concernant les références / noms UIC.
Ces informations sont généralement situées sur le noeud décrivant
l'ensemble de la gare. En conséquence j'aurais tendance à ne pas les
multiplier pour chacun des points d'arrêt (*)

Les quais peuvent également être référencés.

NB : Pour faciliter la contribution des nouveaux arrivants dans osm, et en
particulier ceux qui s'intéressent à un sujet en particulier, il est
possible de mettre en place une fiche osmecum [2]
C'est très pratique comme pense-bête, et ça permet de maintenir une bonne
homogénéité dans les contributions.
Il n'existe pas encore pour le domaine ferroviaire.

Il est également bienvenu de partager les zones que l'on sait très bien
cartographiées.
Un recensement existe pour un grand nombre de domaines et donne deux
exemples de gares :
Avignon TGV et Cologne [3].
Comme souvent dans OSM, l'exemple allemand est très ... fourni ;-) (*)

En affichant la carte sur le site principal, il est possible de cliquer sur
les éléments (points, polylignes ...) en allant dans le menu des couches et
en cochant la case Données de la carte.
Les noeuds qui comportent des tags sont cerclés.

Bonne journée
-
[1] http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
[2] http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum
[3] http://wiki.openstreetmap.org/wiki/FR:Cartotheque#Transport_ferroviaire

(*) Pour la gare de Cologne, chaque point d'arrêt porte les infos de la
gare (nom, références nationale et internationale)


Le 13 janvier 2014 02:16, Pierre Beyssac p...@fasterix.frmug.org a écrit :

 Bonjour,

 Je rebondis sur la discussion en cours.

 Je me présente car c'est mon premier message ici : je travaille,
 euh m'amuse disons, sur le projet Raildar lancé par Bruno.

 Je m'intéresse donc principalement aux voies ferrées dans OSM et à
 vrai dire (pour avoir fait beaucoup de traces GPS ferroviaires au
 fil des ans et rencontré des problèmes de précision) je trouve la
 base de bonne qualité et plutôt complète.

 J'ai fait pas mal de corrections dans OSM suite aux bugs de voies
 trouvés par Raildar et j'ai créé un visualisateur de routes
 ferroviaires OSRM pour aider au debug (il est là
 http://www.raildar.fr/osrm/osrm.html ou là pour la version de dev
 http://signal.eu.org/osm/ ).

 Comme je suis (indépendamment de Raildar) un indécrottable amateur
 de trains j'ai aussi ajouté/complété des gares et voies.

 On Mon, Jan 13, 2014 at 12:00:43AM +0100, Spyou wrote:
  Le 11/01/2014 23:57, François Lacombe a écrit :
   A mon avis il serait peut-être possible de se servir du type de voie
   pour faire le routage plutôt que de rajouter des waypoints fantômes.
   C'est à dire qu'OSRM devrait tenir compte du fait qu'un TER ne peut
   pas prendre les voies TGV par exemple.
 
  OSRM est malheureusement incapable de prendre des consignes à l'entrée
  lors des demandes. Tout passe par la conf en LUA qui doit ensuite être
  moulinée pendant deux bonnes heures avant de donner une db utilisable.
  On peut bien entendu faire tourner X instances d'OSRM (une pour les TGV,
  une pour les TER, une pour les RER, ...) mais c'est autant de boulot à
  maintenir :(

 Je vois quand même un cas où des infos supplémentaires dans OSM
 pourraient être très utiles et d'intérêt général : des labels aux
 voies/quais dans les gares, qui permettraient de relier une indication
 de voie pour un train (de SNCF Direct  co) avec une position
 géographique, qui est un des points qui posent problème à Raildar
 dans les (nombreuses) gares avec des quais ne desservant pas toutes
 les destinations.
 --
 Sent from my FreeBSD server on its IPv6 connection
 Pierre Beyssac  p...@fasterix.frmug.org

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




-- 
ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab
Il n'y a pas de pas perdus, Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014-01-13 Diskussionsfäden HELFER Denis

Pour les cadastres raster, tout se fait à la mano. La visite terrain est un
plus !!

De : Pierre Knobel [mailto:pierr...@gmail.com]
Envoyé : lundi 13 janvier 2014 15:23
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014/1/13 HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr
Plusieurs éléments de réponse :

* La base cadastrale sur laquelle je me suis appuyé contient plus
d'éléments que de réelles adresses. J'avais empiriquement pris uniquement 92%
de ce résultat pour tenir compte de cas particuliers que j'avais repéré : poste
de transformation électrique qui avait une adresse, adresses placées alors
qu'aucun bâtiment n'existe (cas dans des lotissements où l'adresse est
prévisible), hangars agricoles avec adresse, etc.

* L'ensemble des adresses n'est pas affiché sur le plan cadastral.
Parfois, il faut aller sur le site du cadastre, choisir une parcelle et
afficher les informations. Il faut donc jongler entre JOSM et le cadastre à
moins qu'une développeur fou ne nous permette de remonter l'info dans JOSM. Une
bière (ou plus si affinités) à la clé !

* Comme déjà évoqué, il ne faut pas prendre les chiffres à la lettre
(elle est bonne celle là ;-) Il s'agit plutôt d'un indicateur que l'on pourrait
remplacer par : rien, un tout petit peu, un petit peu, un peu, pas mal,
vraiment beaucoup, top moumoute. Prochaine version.

* Il faut tenir compte que la base de comparaison commence à dater un
peu et fausse encore plus les calculs

* Enfin, il faut repasser régulièrement sur les communes, au moins
annuellement. Les plans cadastraux évoluent pas mal surtout s'ils sont
vectorisés.

Pour le cas particulier de Lembach, il y a une centaine d'adresses attribut de
bâti qui ne sont pas comptées sur Pfaffenbronn (je ne compte que les points par
pure fainéantise). Sur la rue André Maginot, tu peux raisonnablement interpoler
les n°11 et 13. L'impasse des Noyers a 6 adresses, etc.
Tu dois pouvoir basculer très rapidement dans la catégorie « pas mal » voire
même « vraiment beaucoup ».
Je referai une analyse début février.

Denis

De : Pierre Knobel [mailto:pierr...@gmail.commailto:pierr...@gmail.com]
Envoyé : lundi 13 janvier 2014 11:58

À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ?

Pour en revenir à l'image du taux de couverture, il y a un nombre significatif
de village que je pense avoir complété avec toutes les adresses que j'arrive à
distinguer sur le cadastre mais qui apparaissent en vert clair (60-80%). Un
exemple : Lembach, tout au nord de la région. Est-ce que ça veut dire que la
base cadastrale à laquelle tu avais accès était plus complète que celle qu'on
peut télécharger avec le plugin de JOSM cadastre-fr ? J'ai remarqué qu'il
manquait un certain nombre de numéros, parfois tout un côté de la rue, mais je
pensais que ces données étaient complètement absentes de la base cadastrale.

2014/1/13 HELFER Denis denis.hel...@rff.frmailto:denis.hel...@rff.fr
Pour déterminer les règles d'usage, vous pouvez vous servir de la page wiki ad
hoc : http://wiki.openstreetmap.org/wiki/Mulhouse/MulhouseData. A ce propos,
l'import de l'opendata mulhousien avance bien. Bravo eiger

Denis

De : Matthias Dietrich [mailto:eiger@gmail.commailto:eiger@gmail.com]
Envoyé : samedi 11 janvier 2014 18:54
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] combien d'adresses en Alsace ?

Le 11 janvier 2014 18:06, Jean-Baptiste Holcroft
jb.holcr...@gmail.commailto:jb.holcr...@gmail.com a écrit :

Quelle est la règle actuelle ?
REF:FR:M2A ?
Il n'y en a pas ;-) (de règle), mais cela pourrait en effet devenir
ref:FR:M2A.
Les jeux de données de la M2A ne comportent pas tous d'identifiant ou de
référence. Les stations Vélocité ont été importées depuis plus longtemps à
partir des fichiers mis à disposition par JCDecaux, avec un simple ref=numéro
de station. La plupart des autres objets n'ont pas de d'identifiant.
Pour parler concrètement : est-ce que tu souhaites procéder à l'import des
arbres de la M2A ? Il faudrait s'accorder sur ce qu'on fait des attributs
disponibles (diamètre de la couronne, etc.).

___
Talk-fr mailing list
Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org

[OSM-talk-fr] Forum Ile-de-France

La liste de diffusion local-idf n'ayant jamais décollé, j'ai proposé sur
celle-ci de basculer sur le forum phpBB. Il n'y a eu qu'une réponse
(positive), donc le forum IdF est maintenant dispo sur
http://forum.openstreetmap.fr/viewforum.php?f=18

Rdv pour y parler de sujets francilio-franciliens !

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

Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname

2014-01-13 Diskussionsfäden PierreV

c'est peut etre cela que tu cherches Christian:
www.agencealpha.com/download/r_cadastraux.doc

Par contre pour VC j'ai pas trouvé la réponse...
Pour info chez moi j'ai un VC VILLAGE DE LA ROCHE AVANE c'est un village
avec un petit lotissement mais aussi une rue unique... bref je voit pas trop
a quoi correspond le c a part pour comunal?




--
View this message in context: 
http://gis.19327.n5.nabble.com/Rendu-QA-ajout-croisement-FANTOIR-et-visu-noname-tp5791052p5792898.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Rendu QA: ajout croisement FANTOIR et visu noname