date:20110528

Dave F. wrote:
 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels
[...]
 This statement:
 
 allows both the way(s) crossing the structure /and/ those passing under
 it to be identified (river and most canals bridges only pass /over/ the
 waterway, and using only the Way tag bridge=yes means that intersection
 tests would have to be used to determine the bridges; now we can
 associate the bridges with the waterway as well.
 
 is unclear (to me) as to why it's necessary. Why does an intersection
 test need to be performed; doesn't the 'bridge=' tag define that the two
 crossing ways are separate?

Let's say my application needs to answer, for whatever reason[1], the
question what ways are below this bridge.

If there is no relation, then this is what the application would do:
* gather at all the ways around the bridge
* find ways that intersect the bridge way, ignoring the third dimension
* check the layer on these ways
- all ways that intersect the bridge way (in 2D representation!) and
have a lower layer are below the bridge.

With a relation, these calculations would not be necessary. In my
opinion, this is not a reason to use a bridge relation, though. (There
/are/ reasons for using a bridge relation, but this is not one of them.)

-- Tobias Knerr

[1] most programs don't even need to know that. Routers can rely on the
convention that there is no connection between ways without a common
node, and 2D renderers only need the layer. A group of applications
which actually need that information are advanced 3D renderers.

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

Re: [OSM-talk] Bridge relation on way going under?

2011-05-28 Diskussionsfäden Lennard


On 28-5-2011 18:46, Tobias Knerr wrote:


With a relation, these calculations would not be necessary.


The people that come up with these types of relations seem to forget 
that spatial data is what OSM is all about.



For instance, using the osm2pgsql schema:

http://www.openstreetmap.org/browse/way/13884500

Which roads/railways/waterways does this bridge cross?

select osm_id,highway,railway,waterway,name
 from (
  select l1.osm_id,l1.highway,l1.railway,l1.waterway,l1.name,
case when l1.layer ~ E'^-?[[:digit:]]+(\.[[:digit:]]+)?$'
then cast (l1.layer as float) else 0 end as crossing_layer,
case when l2.layer ~ E'^-?[[:digit:]]+(\.[[:digit:]]+)?$'
then cast (l2.layer as float) else 0 end as bridge_layer
from planet_osm_line l1, planet_osm_line l2
where ST_Crosses(l2.way, l1.way)
  and l2.osm_id = 13884500
  and (l1.highway is not null or l1.waterway is not null
   or l1.railway is not null)
 ) as foo
 where crossing_layer  bridge_layer;


  osm_id   |   highway| railway | waterway |   name
---+--+-+--+--
  41050723 |  | rail|  |
  98667698 |  | rail|  |
  25933220 | unclassified | |  | Ferdinand Perdieusstraat
  71890307 | path | |  | Brampad
   9923332 |  | rail|  | Lijn 36
 107068083 | residential  | |  | Brandweg
  53085949 | cycleway | |  |
  25806811 | path | |  | Tunnelstraat
  22903417 | unclassified | |  | Brandenstraat
(9 rows)

Time: 7.328 ms


--
Lennard

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

Re: [talk-au] Kempsey, NSW

2011-05-28 Diskussionsfäden Mark Pulley


On 26/05/2011, at 4:50 AM, John Smith wrote:


There is Bing imagery covering Kempsey, but a distinct lack of
mapping, or was before I started adding them, but still plenty to do.



Many of the towns on the north coast need Bing mapping - Taree and  
Nambucca Heads spring to mind, as I have done some surveys in this  
area. I won't have time to do anything here for a while, as I've just  
arrived back home from a 2 week holiday in outback South Australia -  
it will take a while to go through the traces and voice recordings. (I  
did some work with Bing before I left, including the entire town of  
Peterborough.)


Mark P.

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

[Talk-de] Ausschnit auf Kartendarstellungen mit Relationen

2011-05-28 Diskussionsfäden Andreas Tille

Hallo,

unter

   http://www.openstreetmap.org/?relation=rel-ID

kann man sich Relationen darstellen lassen.  Gibt es auch eine
Möglichkeit, den Kartenausschnitt von vorn herein auf eine bestimmte
Stelle zu zoomen.  Ich möchte die Darstellung eines Fernwanderwegs
im Gebiet einer bestimmten Stadt als Link angeben, ohne den Besucher
erst dort langwierig hinzoomen zu lassen.

Viele Grüße

 Andreas.

-- 
http://fam-tille.de

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

Re: [Talk-de] Ausschnit auf Kartendarstellungen mit Relationen

2011-05-28 Diskussionsfäden Norbert Kück


Hallo,
am 28.05.2011 09:21 schrieb Andreas Tille:

http://www.openstreetmap.org/?relation=rel-ID

kann man sich Relationen darstellen lassen.  Gibt es auch eine
Möglichkeit, den Kartenausschnitt von vorn herein auf eine bestimmte
Stelle zu zoomen.  Ich möchte die Darstellung eines Fernwanderwegs im
Gebiet einer bestimmten Stadt als Link angeben, ohne den Besucher
erst dort langwierig hinzoomen zu lassen.

Nichts ausprobiert?
Einfach obigen Aufruf machen, den Ausschnitt wählen. Wie wäre es dann 
mit Permanentlink oder Shortlink? Bei mir geht das.

gruß
nk

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

Re: [Talk-de] Ausschnit auf Kartendarstellungen mit Relationen

2011-05-28 Diskussionsfäden Henning Scholland


Am 28.05.2011 09:21, schrieb Andreas Tille:

Hallo,

unter

http://www.openstreetmap.org/?relation=rel-ID

kann man sich Relationen darstellen lassen.  Gibt es auch eine
Möglichkeit, den Kartenausschnitt von vorn herein auf eine bestimmte
Stelle zu zoomen.  Ich möchte die Darstellung eines Fernwanderwegs
im Gebiet einer bestimmten Stadt als Link angeben, ohne den Besucher
erst dort langwierig hinzoomen zu lassen.

Viele Grüße

  Andreas.


http://www.openstreetmap.org/?relation=...lon=...lat=...

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer


Am 27.05.2011 19:46, schrieb Heiko Jacobs:

Am 27.05.2011 14:07, schrieb Peter Wendorff:

Am 27.05.2011 12:20, schrieb Markus:

Ich könnte mir das so vorstellen:

Mapper  E-Verarbeitungsschicht  DB  ...

Da hast du mich falsch verstanden!
Ich bin für Mapper  DB  ...



Die Daten des Mappers (1)

werden von einem intelligenten Editor entgegengenommen
 und vorverarbeitet und in die Eingangs-Verarbeitungsschicht 
gespeichert (2).

so intelligent kann die Schicht nicht sein, dass dadurch keine
Informationen verloren gehen.
Außerdem ist einiges in dem Bereich nicht sinnvollerweise
bei jedem Upload durchzuführen.


Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen.
Eins jedoch sollten Editoren -- oder wenn die es nicht machen --
die Eingangschicht der DB machen:
Splits und Vereinigungen erkennen und eine saubere Historie
auch für diese erzeugen. Das ist nicht nur DER Knackpunkt
der Relizenzierung (ohne saubere Historie auch bei Splits
und Vereinigungen ist die rechtlich angreifbar), sondern
auch ganz generell lästig, wenn man die Entstehungsgeschichte
eines Objekts verfolgen möchte, wann und von wem und warum bspw.
Tag X drangehängt wurde an die Y-Straße ...

+10!
Ja, ganz klar - das fehlt bisher in API und Editoren völlig.

Allerdings hilft das auch nur zum Teil: Bei der Beobachtung mancher 
Mapper (und etlicher Changesets) ist mir aufgefallen, dass oft eben 
nicht gelöscht + neu angelegt wird, sondern mal eben wiederverwendet, 
verschoben und umgewidmet wird.
Da soll eine Wiese gelöscht und ein Gebäude hinzugefügt werden - dann 
nimmt man den way der Wiese, arrangiert die Nodes des way neu und 
vergibt neue Tags - das kann beim besten Willen kein Editor als neues 
Objekt erkennen.


Gruß
Peter

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

Re: [Talk-de] Ausschnit auf Kartendarstellungen mit Relationen

2011-05-28 Diskussionsfäden Henning Scholland


Sorry...die Reihenfolge war falsch...
osm.org/?lat=...lon=zoom=...relation=...

Bsp: 
http://www.openstreetmap.org/?lat=60.71lon=17.03zoom=6layers=Mrelation=1028016



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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

Wir haben keinen Plasberg hier (oder? :D), aber ein Antrag an den 
erweiterten Faktencheck:
Man untersuche mal die OSM-Datenbank auf Überschneidungen von Tags und 
Tag-Gruppen. Also:
- Überschneiden sich landuses tatsächlich weitgehend NICHT mit highways? 
wenn doch, ist das ein Fehler oder eigentlich korrekt? Wenn es korrekt 
ist, ist hier der Layer eigentlich nicht machbar.

- Analog zu Routing-relevanten Tags (also im weitesten Sinne highway=*)

Wenn noch mehr Kapazität da wäre, würde ich weiter fragen - obwohl ich 
mir spätestens hier eigentlich auch selbst eine Antwort geben kann:
- Sind gleichzeitige (im Sinne von in-einem-changeset-getätigte) 
Änderungen an nur geometrisch naheliegenden Objekten (z.b. landuse und 
highway) voneinander unabhängig? Ich behaupte, das sind sie häufig 
nicht: Ich verschiebe den Weg und korrigiere die angrenzenden Flächen 
entsprechend (denn das Feld geht bis zum Straßenrand und auf der anderen 
Seite beginnt direkt neben der Straße das Fabrikgelände).
Trennt man jetzt aber die Layer, dann erschwert man dieses simultane 
Bearbeiten - und versteckt die dadurch provozierten Fehler eher vor dem 
Nutzer.


Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer


Am 27.05.2011 21:59, schrieb Torsten Leistikow:

Henning Scholland schrieb am 27.05.2011 20:28:

Von einer solchen Abstufung halte ich nichts. Schließlich soll der
Renderer (und der Programmierer dahinter) entschieden wann er was
darstellt.

+1

Die Entscheidung liegt ja auch weiterhin bei dem Renderer. Er ist ja nicht
gezwungen die Hilfstags auszuwerten, und wenn er es tut, dann kann er das ja
auch fuer verschiedene Elemente unterschiedlich handhaben. Eine Karte fuer
Radfahrer koennte so z.B. Radwege immer darstellen wollen, eine Karte fuer
Autofahrer wuerde sich in diesem Falle anders entscheiden, und bei Gleisen
wuerde es beiden reichen, nur eins von mehreren parallel darzustellen.

Das Tag ist ja keine verbindliche Vorgabe fuer die Renderer, sondern es ist nur
ein Hilfmittel, um den Auswerteprogrammen das Weglassen von Objekten zu 
erleichtern.
Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf 
strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma 
auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine 
Straße auf dem Weg als besonders wichtig einstufen.
Klar - man kann die Regeln des Renderers anpassen und das da eben nicht 
mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher 
oder später jemanden geben, der sie ausnutzt, um die Standardkarte den 
eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu 
rendern.


Hier zeigt sich eben auch (mal wieder), dass das Konzept von der 
OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe 
nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration 
zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für 
Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre 
aber ein Glanzpunkt, was die Konzept-Implementierung angeht.


Gruß
Peter

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

Re: [Talk-de] Bahnstrecke vs. Gleis


Am 27.05.2011 19:28, schrieb Heiko Jacobs:

Am 27.05.2011 12:26, schrieb Garry:

Am 27.05.2011 10:51, schrieb Steffen Grunewald:


Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende
Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal 
gesehen.
Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen 
Stuttgart und Ulm sein,

in bergigen Regionen kommt das öfter mal vor.


Da isses platt wie 'ne Flunder:
http://www.openstreetmap.org/?lat=52.7583lon=9.6679zoom=14layers=M
Kennt da jemand zufällig den Grund?
Dass in Deutschland Autobahnen lange Zeit und oft mit beiden Fahrbahnen 
auf gleicher Ebene, meist sogar auf der selben Trasse gebaut worden 
sind, ist erstmal fast ein Sonderfall.
Oft kommt das AFAIK daher, dass es so möglich wird, Abschnitte der 
Autobahn schnell zu planieren und als Start-/Landebahn einsetzen zu können.


Die Beispiele in den Bergen sind auch in DE Gegenbeispiele, in anderen 
Ländern ist das teilweise noch viel seltener so (ohne dass ich jetzt 
konkrete Beispiele nennen könnte).


Gruß
Peter

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

Re: [Talk-de] Kundenparkplatz


Am 28.05.2011 00:08, schrieb Peter:

[...]
Nur ist es so wenn 'die hohen Herren' das Werkzeug nicht geeignet
bauen (mal harsch daher gesagt:-) dann geht der gemeine Mapper
halt hin und macht was daraus was ihm geeignet scheint. So
sind die Leute nunmal.
Also wenn es um die reine Funktionalität der Editoren geht, gestehe ich 
jemandem, der nicht oder wirklich nicht gut programmieren kann, die 
Aussage der hohen Herren zu.Ich habe mal die Parkplätze (nur way) 
einer Großstadt gesucht:

400 Stück, 20% haben Namen, über den Daumen gepeilt sind die
hälfte(!) Kundenparkplätze, an den Namen erkennbar.
access=customers haben 2(!)

Ergo ist das ganze ein Dokumentationsproblem, oder am Editor (josm
bietet weder in access noch in der Vorlage 'Parkplatz' was an)
Die Vorlagen sind aber meines Wissens in allen Editoren einfache 
XML-Dateien, die man sehr leicht anpassen kann.
Ich denke, dies hier wäre ein Beispiel, das (wenn das Proposal durch und 
angenommen ist) sicher gerne als Patch angenommen würde.


Gruß
Peter

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

2011-05-28 Diskussionsfäden Heiko Jacobs


Am 27.05.2011 20:28, schrieb Henning Scholland:

Im Falle vom Fußweg/Radweg/Straße bspw. könnte man kennzeichnen,
dass der Radweg und der Fußweg zur Straße gehören und nicht
einen eigenständigen Weg bilden.


Das ist eine Info, die auch zum (Rad-)Routen nützlich ist.

Gruß Mueck




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

Re: [Talk-de] Kundenparkplatz

2011-05-28 Diskussionsfäden Flaimo

das proposal zieht in erster linie aber auf parken entlang von straßen
ab. wenn es dir um richtige parking lots geht, so könntest du auch das
parking space proposal als vorlage hernehmen, sofern du entsprechend
hochauflösende bing bilder zur verfügung hast. das ist nämlich schon
approved und beinhaltet sowohl einen vorschlag für die rollenthematik
(access:customer) als auch wie man es in relation zu sonstigen
elementen stellt (site relation). gerendert wird es aber auch noch
nicht.

http://wiki.openstreetmap.org/wiki/Proposed_features/parking

flaimo

 Message: 2
 Date: Sat, 28 May 2011 00:08:11 +0200
 From: Peter peter@gmx.net
 To: talk-de@openstreetmap.org
 Subject: Re: [Talk-de] Kundenparkplatz
 Message-ID: irp7c5$apq$1...@dough.gmane.org
 Content-Type: text/plain; charset=ISO-8859-15; format=flowed

 Am 24.05.2011 18:15, schrieb Stephan Wolff:
 Am 24.05.2011 17:06, schrieb Peter:
 Am 23.05.2011 20:11, schrieb Stephan Wolff:

 Mir nicht. name=Kunden Rewe ist offensichtlich falsch.

 Seh' ich nicht das das falsch ist.
 das mit note/desc. mag ok sein, aber wenn man das nicht in der
 Karte sieht ist es fast nutzlos.
 []
 OSM ist auch eine Karte, keine Datenhalde.

 Du hast das Grundprinzip von OSM nicht verstanden.
 OSM ist eine Datensammlung aus der (unter anderem) verschiedene
 Karten berechnet werden. Bei Bedarf werden die Regeln zur
 Kartendarstellung angepasst, nicht die Daten an die erw?nschte
 Darstellung.

 Ich hab' das schon verstanden. Was 'ne Unterstellung.

 Nur ist es so wenn 'die hohen Herren' das Werkzeug nicht geeignet
 bauen (mal harsch daher gesagt:-) dann geht der gemeine Mapper
 halt hin und macht was daraus was ihm geeignet scheint. So
 sind die Leute nunmal.

 Ich habe mal die Parkpl?tze (nur way) einer Gro?stadt gesucht:
 400 St?ck, 20% haben Namen, ?ber den Daumen gepeilt sind die
 h?lfte(!) Kundenparkpl?tze, an den Namen erkennbar.
 access=customers haben 2(!)

 Ergo ist das ganze ein Dokumentationsproblem, oder am Editor (josm
 bietet weder in access noch in der Vorlage 'Parkplatz' was an)

 Ich werf' da keinem der t?tigen was vor (nur den Meckerern),
 das sind einfach Kleinigkeiten die vorkommen.

 Nun warte man bis das Parkplatz proposal erledigt ist, das mit
 access oder wie auch immer man den Parkplatz an den Laden
 bindet, dann die Renderer angepasst sind (wird dann name=''
 oder der zugeh?rige Laden angezeigt? Besser beides.)

 Danach kannst du dann hingehen und die gesch?tzt 5000 name='Laden'
 l?schen:-)
 Ich werde den einen Kundenparkplatz den ich erfasste dann
 h?chst pers?nlich korrigieren.

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

Re: [Talk-de] Bahnstrecke vs. Gleis

2011-05-28 Diskussionsfäden Wolfgang

Hallo,
Am Samstag 28 Mai 2011 10:00:28 schrieb Peter Wendorff:

 Dass in Deutschland Autobahnen lange Zeit und oft mit beiden Fahrbahnen
 auf gleicher Ebene, meist sogar auf der selben Trasse gebaut worden
 sind, ist erstmal fast ein Sonderfall.
 Oft kommt das AFAIK daher, dass es so möglich wird, Abschnitte der
 Autobahn schnell zu planieren und als Start-/Landebahn einsetzen zu können.
 
 Die Beispiele in den Bergen sind auch in DE Gegenbeispiele, in anderen
 Ländern ist das teilweise noch viel seltener so (ohne dass ich jetzt
 konkrete Beispiele nennen könnte).
 
Das ist genau wie das Argument mit der Bombe ein schwer auszurottendes 
Gerücht. Es gibt einzelne Autobahnabschnitte, die tatsächlich als 
Behelfsflugplätze eingerichtet sind, z.B. auf der A7 in Schleswig-Holstein. 
Dazu gibt es auch etwas in Wikipedia. 

Im allgemeinen ist es aber ganz schlicht in jeder Beziehung einfacher und 
billiger, eine breitere Trasse zu bauen als 2 Schmale. Die Planungskosten sind 
niedriger, es reicht eine Achse und eine Gradiente, pro Station ein 
Querprofil, es sind weniger Anrainer betroffen, es ist in der Bauausführung 
einfacher und billiger, im Betrieb ist es einfacher, den Verkehr ggf. 
umzuleiten, etc. . Die Fahrbahnen werden eigentlich nur getrennt, wenn sonst 
unverhältnismäßig große Massen bewegt werden müssten, insbesondere in bergigem 
Gebiet.

Auf der A7 gibt es in der Nähe von Soltau eine Stelle, wo sich die Fahrbahnen 
trennen. Die Autobahn wurde in den 50er Jahren gebaut (AFAIK). Damals wurde 
noch mit Lorenbahn und Schaufel gearbeitet. Da spielte es dann schon eine 
Rolle, wenn ein relativ niedriger Hügel auf 2 Trassen umgangen wurde und damit 
weniger Erdbewegung erforderlich wurde.

Eine einfache Rechnung: Eine Autobahn soll auf einem Niveau-Unterschied zum 
umliegenden Gelände von 2m gebaut werden.

Der Platzbedarf für 2 Fahrspuren und Standstreifen ist immer derselbe.

Hinzu kommt pro Trasse 2x Bankett (ca 1,50m), 2x Entwässerungsgraben (ca 
1,50m), 2x Böschung (1:2 bei 2m - 4m)

Eine gemeinsame Trasse braucht hier zusätzlich zur Fahrbahn ca. 14m. 2 Trassen 
brauchen ca. 28m. Dazu kommt die eigentliche Nutzbreite mit ca. 11m pro 
Richtungsfahrbahn. Das heißt, bei einer Nutzbreite von 22m werden zusätzliche 
Breiten von 14/28m benötigt. Anders ausgedrückt, 22 +14 = 36 gegen  50 m. Das 
entpricht ca 40% mehr Massenbewegung = Baukosten. Hinzu kommen die Mehrkosten 
für Planung, rechtliche Durchsetzung, Anwohnerentschädigung etc. Außerdem ist 
es für einen Bauausführenden eine andere Kalkulation, wenn er 2 einzelne 
schmale Baustellen hat statt einer breiten. Auch da entstehen Mehrkosten, z.B. 
durch Machinentransport. (Bitte jetzt keine Erbsen zählen, ich habe die 
Breiten so geschätzt, ohne Standardquerschnitte heranzuziehen).

Bei einem größeren Niveauunterschied sind diese Mehrkosten noch beträchtlich 
höher.

In anderen Ländern ist es häufig so, dass bisherige Straßen zur Autobahn 
ausgebaut werden. Ein solchen Beispiel kenne ich aus Spanien, wo einfach neben 
die bestehende Landstraße eine zweite Spur gebaut wurde. Da kommt es dann 
schon vor, dass neben der Landstraße liegende Hindernisse von der neuen Spur 
einfach umgangen werden.

Besonders deutlich ist das auf dieser Karte zu sehen:
http://www.openstreetmap.org/?lat=38.38311lon=-3.50458zoom=15layers=M

Am Pass Despañaperros wurde einfach die Süd-Nord-Fahrbahn neu gebaut, 
während die Nord-Süd-Richtung auf der unveränderten Passstraße liegt, 
einschließlich Serpentinen und Parkplätzen auf der für den Verkehr jetzt 
linken Seite. Als ich die Straße befahren habe, waren sogar die 
Fahrbahnmarkierungen noch die Alten. Möglicherweise wurden die Parkplätze 
inzwischen umgebaut.

Im Gegensatz dazu werden in Deutschland Autobahnen überwiegend auf einer neuen 
Trasse gebaut, wo die Baukosten entscheidend sind, s. o. . Es gibt allerdings 
Ausnahmen, wie z.B. die A21.

Gruß, Wolfgang

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

Re: [Talk-de] amazon.de-affiliate für OSM?

Am 26.05.2011 23:20, schrieb malenki:
 Aufgrund der überwältigenden Nachfrage gibt es nun die Möglichkeit,
 OpenStreetMap über das deutsche Amazon Prozente seines Einkaufes
 zukommen zu lassen. 
 Es sollte genügen, über diesen Link einzukaufen:
 http://www.amazon.de/?_encoding=UTF8tag=opensde-21
 
 Als Bankverbindung wurde die des FOSSGIS verwendet.

Ist das dann eine zweckgebundene Spende für Aktivitäten im Zusammenhang
mit OSM oder geht das Geld ohne weitere Einschränkungen an den Verein?

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

Re: [Talk-de] amazon.de-affiliate für OSM?

2011-05-28 Diskussionsfäden Lars Lingner

Am 28.05.2011 15:27, schrieb Tobias Knerr:
 Am 26.05.2011 23:20, schrieb malenki:
 Aufgrund der überwältigenden Nachfrage gibt es nun die Möglichkeit,
 OpenStreetMap über das deutsche Amazon Prozente seines Einkaufes
 zukommen zu lassen. 
 Es sollte genügen, über diesen Link einzukaufen:
 http://www.amazon.de/?_encoding=UTF8tag=opensde-21

 Als Bankverbindung wurde die des FOSSGIS verwendet.
 
 Ist das dann eine zweckgebundene Spende für Aktivitäten im Zusammenhang
 mit OSM oder geht das Geld ohne weitere Einschränkungen an den Verein?
 


Ja. ;)


Alle Zuwendungen die beim Verein für OSM eingehen werden auch für OSM
reserviert. Eine Verwendung für andere (Nicht-OSM-)Zwecke erfolgt nicht.

Das Geld wird auf dem Vereinskonto gesammelt. Einmal jährlich findet
eine Vollversammlung statt, bei der auch über die Verwendung und
Verteilung informiert wird.


Lars

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

2011-05-28 Diskussionsfäden Torsten Leistikow

Peter Wendorff schrieb am 28.05.2011 09:50:
 Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf
 strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma
 auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine
 Straße auf dem Weg als besonders wichtig einstufen.

So ganz hast du die Idee des Vorschlags noch nicht verstanden. Mit den
vorgeschlagenen Hilfstags kann man keine Anzeige beim Renderer erzwingen, ein
Element kann dadurch nicht wichtiger werden, als es jetzt schon ist. In der
umgekehrten Richtung gibt es dem Mapper allerdings die Moeglichkeit, Elemente
fuer hohe oder niedrige Detail-Auswertungen als nachrangig zu kennzeichnen, da
sie auf diesem Detaillevel durch ein anderes Element hinreichend repraesentiert
werden.

 Klar - man kann die Regeln des Renderers anpassen und das da eben nicht
 mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher
 oder später jemanden geben, der sie ausnutzt, um die Standardkarte den
 eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu
 rendern.

Die Missbrauchsmoeglichkeiten sind da sehr beschraenkt:
1. Ein Mapper kennzeichnet etwas als main, was von anderen eher als minor
gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen nicht
ausgeblendet - Die Karte sieht genauso aus wie heute ohne solche Zusatztags.
Die Lage hat sich also durch den Missbrauch nicht verschlechtert.
2. Ein Mapper kennzeichnet was als minor, was von anderen eher als main
gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen
eventuell von einigen Renderen nicht mehr angezeigt (bei vielen Typen wuerde ein
minor heute keinen Sinn machen und von einem Renderer deshalb auch nicht
beruecksichtigt werden.) - Ein andere Mapper wird das Element auf der Karte
vermissen und das Tagging entsprechen korregieren. Das ist genauso, wie Mapper
auch heute bei den Strassenkategorien unterschiedlicher Meinung sein koennen,
davon geht die OSM-Karte nicht unter.
Auf die Kennzeichnung abstract gehe ich hier nicht weiter ein, da es bislang
keine derartigen Elemente gibt, das waere also eher was fuer die Zukunft, wenn
sich entsprechender Bedarf ergibt.

 Hier zeigt sich eben auch (mal wieder), dass das Konzept von der
 OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe
 nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration
 zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für
 Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre
 aber ein Glanzpunkt, was die Konzept-Implementierung angeht.

Dem will ich nicht widersprechen, vorallem deshalb, weil ich nicht verstanden
habe, was du damit sagen willst ;-)

Gruss
Torsten

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

[Talk-de] Fahrradrouten von Alltagsradlern - Commuteing Cycle Network?

2011-05-28 Diskussionsfäden Markus Straub


Liebe Liste,

ich würde gerne wissen was ihr vom Taggen von Alltagsradwegen in Form 
eines Netzwerks haltet.


Ausgangspunkt: Hier in Wien gibt es ein sehr zerstückeltes offizielles 
Radwegenetz, das nur teilweise die tatsächlich gefahrenen Routen (vor 
allem vom Alltagsradverkehr -- 'commuter') wiedergibt. In anderen 
Städten (z.B. Linz) gibt es innerhalb der Stadt überhaupt keine 
beschilderten Radwege.


In der Realität existiert aber ein solches Netz und ich würde in es in 
Wien gerne mit Hilfe der lokalen Fahrradlobby/vereinigung einzeichnen.


Meine Recherche zum passenden Taggingschema hat mich zu nichts 
existierendem geführt, ich könnte mir aber vorstellen einen neuen Typ 
von Cycle Routes[1] einzuführen:

network=ccn (commuting cycle network)

Von früheren Ideen ein solches Netzwerk mit Cycleworth[2] oder ähnlichen 
Tags zu realisieren bin ich abgekommen, da das Endresultat ein 
geschlossenes Netz sein soll, was denke ich durch Relationen gefördert 
wird. Außerdem ist role=forward/backward von Bedeutung.


Liebe Grüße,
Markus (evod)

[1] http://wiki.openstreetmap.org/wiki/Cycle_routes#Relations
[2] http://wiki.openstreetmap.org/wiki/Cycleworth


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

Re: [Talk-de] Fahrradrouten von Alltagsradlern - Commuteing Cycle Network?

2011-05-28 Diskussionsfäden Johannes Huesing

Markus Straub markus.straub...@gmail.com [Sat, May 28, 2011 at 06:10:07PM 
CEST]:
 Liebe Liste,
 
 ich würde gerne wissen was ihr vom Taggen von Alltagsradwegen in
 Form eines Netzwerks haltet.
 
 Ausgangspunkt: Hier in Wien gibt es ein sehr zerstückeltes
 offizielles Radwegenetz, das nur teilweise die tatsächlich
 gefahrenen Routen (vor allem vom Alltagsradverkehr -- 'commuter')
 wiedergibt. In anderen Städten (z.B. Linz) gibt es innerhalb der
 Stadt überhaupt keine beschilderten Radwege.
 
 In der Realität existiert aber ein solches Netz und ich würde in es
 in Wien gerne mit Hilfe der lokalen Fahrradlobby/vereinigung
 einzeichnen.
 
 Meine Recherche zum passenden Taggingschema hat mich zu nichts
 existierendem geführt, ich könnte mir aber vorstellen einen neuen
 Typ von Cycle Routes[1] einzuführen:
 network=ccn (commuting cycle network)
 

Die allgemeine Ideologie ist, dass wir nur taggen, was wir sehen.
Es gab mal Diskussionen über unterirdisch geführte Seekabel, ao
das Echo eher kritisch war. 

Unvollständig beschilderte Radruten (welche ist schon vollständig
beschildert) würde ich schon eintragen, rein konzipierte eher nicht.
Ich hatte mal überlegt, ob ich die hochpraktischen Radweit-Verbindungen
von Ulrich Lamm eintragen sollte, aber das war mir 1) zu umständlich 
und steht 2) der allgemeinen Ideologie entgegen.


-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi)

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer


Am 28.05.2011 16:38, schrieb Torsten Leistikow:

Peter Wendorff schrieb am 28.05.2011 09:50:

Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf
strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma
auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine
Straße auf dem Weg als besonders wichtig einstufen.

So ganz hast du die Idee des Vorschlags noch nicht verstanden. Mit den
vorgeschlagenen Hilfstags kann man keine Anzeige beim Renderer erzwingen, ein
Element kann dadurch nicht wichtiger werden, als es jetzt schon ist. In der
umgekehrten Richtung gibt es dem Mapper allerdings die Moeglichkeit, Elemente
fuer hohe oder niedrige Detail-Auswertungen als nachrangig zu kennzeichnen, da
sie auf diesem Detaillevel durch ein anderes Element hinreichend repraesentiert
werden.

Ich hab den Vorschlag sehr wohl verstanden.
Aber wenn ich nicht wichtiger taggen kann, dann tagge ich eben alle 
konkurrierenden Objekte als minder wichtig, um mein Ziel zu erreichen.


Wo Leute die Sandgrube auf dem Golfplatz als Strand taggen, weil das 
Rendering die schönere Farbe zeigt, wird auch das früher oder später 
passieren.
Wie? Mapnik zeigt die Nachbarstraße an und nicht die Straße, in der ich 
wohne? dann tagge ich die Nachbarstraße eben als weniger wichtig.

Klar - man kann die Regeln des Renderers anpassen und das da eben nicht
mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher
oder später jemanden geben, der sie ausnutzt, um die Standardkarte den
eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu
rendern.

Die Missbrauchsmoeglichkeiten sind da sehr beschraenkt:
1. Ein Mapper kennzeichnet etwas als main, was von anderen eher als minor
gekennzeichnet werden wuerde -  Das Element wird bei niedrigen Zoom-Stufen 
nicht
ausgeblendet -  Die Karte sieht genauso aus wie heute ohne solche Zusatztags.
Die Lage hat sich also durch den Missbrauch nicht verschlechtert.
Falsch: Heute wird irgendwas ausgeblendet, dann wird bevorzugt etwas 
anderes ausgeblendet.

Klar: man kann dadurch nicht MEHR anzeigen, aber ANDERES.
Richtig ist zwar, dass sich die Lage nicht verschlechtert hat, 
verbessern wird sich dadurch aber auch nichts.

2. Ein Mapper kennzeichnet was als minor, was von anderen eher als main
gekennzeichnet werden wuerde -  Das Element wird bei niedrigen Zoom-Stufen
eventuell von einigen Renderen nicht mehr angezeigt (bei vielen Typen wuerde ein
minor heute keinen Sinn machen und von einem Renderer deshalb auch nicht
beruecksichtigt werden.) -  Ein andere Mapper wird das Element auf der Karte
vermissen und das Tagging entsprechen korregieren. Das ist genauso, wie Mapper
auch heute bei den Strassenkategorien unterschiedlicher Meinung sein koennen,
davon geht die OSM-Karte nicht unter.
Aber warum gibst du hier dem Mapper die Möglichkeit, bewusst zu 
entscheiden, dass etwas nicht gerendert werden soll?
Wenn jemand ein solches Element heute löscht, ist das Vandalismus und 
als solcher in OSM geächtet.
Wenn jemand nur dranpappt, dass das irrelevant ist, dann ist die Wirkung 
für einige, potenziell die wegweisenden Renderings die gleiche, aber du 
kannst es kaum noch als Vandalismus darstellen.

Gewonnen ist damit aber nichts.

Hier zeigt sich eben auch (mal wieder), dass das Konzept von der
OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe
nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration
zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für
Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre
aber ein Glanzpunkt, was die Konzept-Implementierung angeht.

Dem will ich nicht widersprechen, vorallem deshalb, weil ich nicht verstanden
habe, was du damit sagen willst ;-)
Die Mapnik-Karte wird von einigen OSM-Aktivisten (mich eingeschlossen) 
nicht in erster Linie als gute Karte angesehen.
Es geht nicht darum, dass die Standard-Stile auf osm.org die 
best-aussehenden Karten darstellen; es geht vielmehr darum, sichtbar zu 
machen, was mit OSM alles möglich ist.


Ein neuer Nutzer kommt auf die Webseite und sieht: boah, da ist sogar 
der Fußgängerweg nebenan eingezeichnet - den hab ich sonst noch auf 
keiner Karte gesehen!.
Spannend in dem Zusammenhang gerade auch die Radfahrer- und ÖPNV-Karten 
- obwohl die nicht auf der Startseite zu sehen sind.


Auch die sind aus kartographischen Gesichtspunkten beurteilt keine 
herausragenden Werke; aber sie zeigen, was möglich ist.


Andererseits nutzen Mapper wie wir die Karten, um festzustellen, wo noch 
POIs fehlen oder wo Fehler zu beheben sind.
Wenn aber die technischen Möglichkeiten von Mapnik dahingehend genutzt 
(und insofern demonstriert) würden, dass Linienbündel zusammengefasst 
werden, dann gehen möglicherweise da wieder visuelle Informationen 
verloren, und ich kann die Frage, ob es sich jetzt um ein Eisenbahngleis 
oder eine mehrspurige Strecke handelt, möglicherweise nur noch schlecht 
beantworten.


Gruß
Peter

Re: [Talk-de] amazon.de-affiliate für OSM?

Am 27.05.2011 09:55, schrieb Walter Nordmann:
 bedeutet das wirklich, dass alles, was von amazon über diesen link
 eingekauft wird, 5% für osm bringt?
 
 das würde bei einigen 1000 aktiven os-nutzern in deutschland doch wohl mehr
 bringen als die läppischen 25 pfund/quartal in uk, oder?
 
 nur müsste man das etwas mehr publik machen.

Im Wiki gibt es an einigen Stellen auch schon Amazon-Links auf einzelne
Bücher. Da könnte man eigentlich auch überall eine OSM-ID einbauen, oder?

Um das angesichts von Amazons etwas umständlichen URLs zu erleichtern,
habe ich mal eine Vorlage gebaut:
http://wiki.openstreetmap.org/wiki/Template:Amazon.de

Benötigt nur die ISBN-10 als Parameter. Erste Verwendung hier:
http://wiki.osm.org/Books#Rund_ums_GPS_im_praktischen_Einsatz

Kann jemand bestätigen, dass die Links so auch wirklich funktionieren
(d.h. Geld einbringen würden)?

Tobias

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

Re: [Talk-de] Konzept für Daten, Karte und Renderer

2011-05-28 Diskussionsfäden Torsten Leistikow

Peter Wendorff schrieb am 28.05.2011 19:17:
 Aber wenn ich nicht wichtiger taggen kann, dann tagge ich eben alle
 konkurrierenden Objekte als minder wichtig, um mein Ziel zu erreichen.

Das klappt deshalb nicht, weil ein Renderer ja gar nicht pauschal alles mit
minor markiertes unterdruecken wuerde, es kommt dabei ja immer noch zusaetzlich
auf den Typ des Objektes an.
Ausserdem wuerde damit ein Objekt ja auch nicht komplett aus der gerenderten
Karte verschwinden, sondern nur auf Zoom-Stufen, wo es in der Anzeige sowieso
mit einem anderen Objekt konkurrieren wuerde, d.h. mit guter Wahrscheinlichkeit
sowieso verdeckt waere.

Auch jetzt ist es so, dass ein Renderer ab einer bestimmten Zoom-Stufe
entscheidet, dass ein Objekt zu Gunsten der Uebersicht nicht mehr angezeigt
wird. Durch das Detail-Mapping haben wir nun aber immer haeufiger den Fall, dass
der Renderer allein aufgrund des Typs der Objekte nicht ausreichend auswaehlen
kann, was er weg lassen sollte (es gibt einfach zu viele gleichrangige Objekte).
Ist es da nicht sinnvoller, wem man als Mapper dem Renderer einen Tipp geben
kann, was er bei der Anzeige im Zweifelsfall unterdruecken koennte, als dass das
zufaellig passiert?

 Wie? Mapnik zeigt die Nachbarstraße an und nicht die Straße, in der ich
 wohne? dann tagge ich die Nachbarstraße eben als weniger wichtig.

Wenn man ein Objekt (eine Strasse) in der Anzeige bevorzugen moechte, dann hat
man auch heute schon die Moeglichkeit, an der Klassifizierung rumzuspielen.

 Die Mapnik-Karte wird von einigen OSM-Aktivisten (mich eingeschlossen)
 nicht in erster Linie als gute Karte angesehen.
 Es geht nicht darum, dass die Standard-Stile auf osm.org die
 best-aussehenden Karten darstellen; es geht vielmehr darum, sichtbar zu
 machen, was mit OSM alles möglich ist.

Mir geht es ja auch nicht darum, dass unbedingt die Mapnik-Karten besser
aussehen soll, das Problem betrifft naemlich auch alle anderen automatisch
erzeugten Karten. Wenn jemand also das Ziel hat, eine optisch moeglichst schoene
Karte zu erzeugen (im Gegensatz zu deinem Anspruch an die Standardkarte), dann
verbauen wir ihm dafuer jegliche Moeglichkeit.

Wenn wir den Mappern keine Moeglichkeit geben, in gewissen Grenzen die
Kartenansicht mit zu beeinflussen, dann neigen die Mapper dazu, zu diesem Zweck
die Daten zu verfaelschen (Mappen fuer den Renderer, haeufigster Fall ist da
sicherlich das Layer-Tag bei Flaechen). Das Problem ist bei einem Hilfstag
ausgeschlossen, wenn es per Definition fuer die Bedeutung des Elementes
irrelevant ist.

Gruss
Torsten

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

[Talk-de] Kandidaten fuer weitere tile layer auf osm.org?

2011-05-28 Diskussionsfäden Kai Krueger

Hallo allerseits,

Das Kernziel von OpenStreetMap ist es freie Kartendaten zu sammeln. Ein
wichtiger Vorteil das die Rohdaten frei zur verfuegung stehen, ist das man
daraus eine grosse Vielfalt von Anwendungen und anderer Dinge machen kann.

Es ist also wichtig diese Vielfalt herauszuheben und diese Neueinsteigern
moeglichst gut zu vermitteln.

Eine (einfache) Moeglichkeit diese Vielfalt etwas besser der breiten
Oeffentlichkeit klar zu machen waere indem man zusaetzliche (spezialisierte)
Karten auf der Homepage von OpenStreetMap.org anzeigen wuerde. Derzeit
stehen vier Karten-Layer zur Auswahl (Mapnik, Osmarender, OpenCycleMap und
no-name). Die OpenStreetMap Gemeine hat jedoch weit mehr, zum Teil sehr
interessante Karten layer zu bieten und insofern waere es schoen ein paar
weitere auf der Homepage aufzunehmen.

Um dies zu erleichtern, und etwaige Vorwuerfe a la Wieso wurde Karte A
aufgenommen und nicht Karte B, das ist doch unfaire Werbung fuer Betreiber
der Karte A durch sachliche Kriterien entgegenzuwirken, sowie ein
Mindestmass an Qualitaet zu sichern, wurden dafuer Richtlinien entworfen
[1], unter welchen Bedingungen Karten layer aufgenommen werden und welche
bevorzugt wuerden.

Zu den Kriterien gehoeren:

1) Sowohl der Kartenstil-Autor als auch der Betreiber der Server die die
Karte rendern muessen damit einverstanden sein das der Kartenstil in osm.org
aufgenommen wird. Besonders der Server betreiber ist wichtig um sicher zu
stellen, das es nicht dessen Tile usage policy verletzt und die
verursachten Kosten fuer zusaetzlichen Trafic kein Problem sind.

2) Als internationales Projekt, sollten alle Karten die auf der Homepage
angezeigt werden eine globale Abdeckung haben um nicht einzelne Regionen zu
bevorzugen / benachteiligen.

3) Der Server des Kartenstiles muss einigermassen zuverlaessig sein und
robust / leistungsfaehig genug um den zu erwartenden Trafic zu verkraften.
Ein privater DSL Anschluss z.B. wuerde dem z.B. warscheinlich nicht
genuegen. Es ist schwer abzuschaetzen wieviel Trafic durch eine Einbindung
in Osm.org tatsachlich zusaetzlich verkraftet werden muss, aber sehr grob
geschaetzt wuerde ich mal behaupten so ca 1 - 10 Mbit/s.

4) Die Karten muessen regelmaessig aktualisiert werden. Minuetlich waere
natuerlich ideal, aber das waere wohl ein zu strenges Kriterium fuer die
meisten Karten betreiber, insofern ist regelmaessig aktuallisiert deutlich
lockerer definiert bei denen woechentlichen updates auch noch OK waeren.

Zusaetzlich zu diesen Harten Kriterien die erfuellt sein muessen, gibt es
noch ein paar weitere Kriterien um zu entscheiden welche Karten bevorzugt
wuerden, sollte es je zu viele Optionen geben um sie alle einzubinden.

Hierzu zaehlt das die Karte moeglichst verschieden zu den bestehenden
Karten ist, das der Kartenstil bevorzugt zur freien verfuegung stehen
sollte, das er interessante und neue Aspekte der Daten zeigt und das
Karten von Community Mitgliedern bevorzugt gegenueber reinen kommerziellen
Anbietern betrachtet wuerden.

Die Frage ist nun kennt jemand / betreibt jemand einen Karten-layer der
diese Kriteren erfuellen wuerde und somit auf osm.org aufgenommen werden
koennte? Es waere schoen wenn wir dort eine groessere Vielfahlt erreichen
koennten und das grosse Potential von OSM besser zu verdeutlichen.

Kai

[1]
http://wiki.openstreetmap.org/wiki/Strategic_working_group/New_Tile_Layer_Guidelines
[2] http://wiki.openstreetmap.org/wiki/Featured_tiles

--
View this message in context:
http://gis.638310.n2.nabble.com/Kandidaten-fuer-weitere-tile-layer-auf-osm-org-tp6415090p6415090.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] amazon.de-affiliate für OSM?

2011-05-28 Diskussionsfäden malenki

Tobias Knerr schrieb:

Im Wiki gibt es an einigen Stellen auch schon Amazon-Links auf einzelne
Bücher. Da könnte man eigentlich auch überall eine OSM-ID einbauen,
oder?

Imo ja. 
Einen Hinweis wie in dem Template, dass über den Einkauf via diesen
Link OSM eine Umsatzbeteiligung erhält, fände ich der Transparenz
halber angebracht.

Um das angesichts von Amazons etwas umständlichen URLs zu erleichtern,
habe ich mal eine Vorlage gebaut:
http://wiki.openstreetmap.org/wiki/Template:Amazon.de

Schön :)

Benötigt nur die ISBN-10 als Parameter. Erste Verwendung hier:
http://wiki.osm.org/Books#Rund_ums_GPS_im_praktischen_Einsatz

Kann jemand bestätigen, dass die Links so auch wirklich funktionieren
(d.h. Geld einbringen würden)?

Das sollte funktionieren.

Die beiden amazon.co.uk-Links sind übrigens mit einer zu Steve Coast
gehörenden ID versehen.

malenki



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

Re: [Talk-de] amazon.de-affiliate für OSM?

Am 28.05.2011 22:03, schrieb malenki:
 Die beiden amazon.co.uk-Links sind übrigens mit einer zu Steve Coast
 gehörenden ID versehen.

tag=asklater-21 gehört also Steve Coast?

Ich hab jetzt jedenfalls mal mit tag=openstreetmap-21 (wie auf der
Merchandise-Seite erwähnt) auch ein Template für amazon.co.uk gebastelt:

http://wiki.osm.org/Template:Amazon.co.uk

Tobias

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

[Talk-de] Informationsfreiheitsgesetz

2011-05-28 Diskussionsfäden Markus

Wer hat schon mal jemand versucht, von Behörden Geodaten aufgrund des 
Informationsfreiheitsgesetzes zu bekommen?

Mit welchem Erfolg?

Gruss, Markus

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

Re: [Talk-de] amazon.de-affiliate für OSM?

2011-05-28 Diskussionsfäden malenki

Tobias Knerr schrieb:

Am 28.05.2011 22:03, schrieb malenki:
 Die beiden amazon.co.uk-Links sind übrigens mit einer zu Steve Coast
 gehörenden ID versehen.

tag=asklater-21 gehört also Steve Coast?

Die Links wurden vom User Steve hinzugefügt. Ein Klick auf den Name
fürt zu einer eindeutigen Userseite, wo seine emailadresse
@asklater.com lautet.

Ich hab jetzt jedenfalls mal mit tag=openstreetmap-21 (wie auf der
Merchandise-Seite erwähnt) auch ein Template für amazon.co.uk
gebastelt:

http://wiki.osm.org/Template:Amazon.co.uk

Danke.

Gerade habe ich versucht, eine ID für Amazon.com generieren, damit
Mapper aus den USA auch mitmachen können (und dir die Arbeit
nicht ausgeht :))
Allerdings braucht es dafür ein Konto in den USA. Heute wird das nix
mehr.

Gruß
malenki



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

Re: [Talk-de] Informationsfreiheitsgesetz

2011-05-28 Diskussionsfäden Thomas Barris

ich habe das mal versucht. Also nicht direkt Geodaten, aber Verträge, die
die Erhebung von Geodaten zum Inhalt hatten, speziell unter welcher Lizenz
Daten stehen, die allein durch eine deutsche Förderung im Ausland erhoben
wurden. Das Ende vom Lied war, dass sie mir eine nichts sagende Auskunft
gegeben haben mit dem Verweis, dass weitere Auskünfte kostenpflichtig wären.
Nach dem Informationsfreiheitsgesetzkann das bis zum 500€ kosten. Das war es
mir dann nicht wert

Am 28. Mai 2011 23:31 schrieb Markus liste12a4...@gmx.de:

 Wer hat schon mal jemand versucht, von Behörden Geodaten aufgrund des
 Informationsfreiheitsgesetzes zu bekommen?
 Mit welchem Erfolg?

 Gruss, Markus

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

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

Re: [Talk-de] Kandidaten fuer weitere tile layer auf osm.org?

2011-05-28 Diskussionsfäden Kolossos

Hallo, wenn man systematisch durchgeht, auf welche Weisen sich Menschen
auf der Welt fortbewegen und dafür Karten brauchen, fiele mir dafür
spontan die ÖPNV-Karte ein.

Eine Seekarte wäre auch nicht schlecht, allerdings bringt OpenSeaMap im
Binnenland nicht viel. Da gefällt mir der Wasser-Overlay von Itoworld
bald besser:

http://www.itoworld.com/product/data/ito_map/main?view=3lat=46.951081lon=7.438637zoom=13
Ein Wanderkarte mit Höhenrelief wäre nicht schlecht (hikebikemap) und
etwas für die überregionalen Bahnstrecken, Parkplätze und POIs.

Stromleitungen und anderes führen bei Ottonormal-Netznutzer vielleicht
eher zur abschreckende Frage: Was soll ich damit? Was nützt das mir?

Generell sollte man sich überlegen, wie sich OSM da darstellen will, so
einen Layer wie Straßen ohne Name sehe ich eher in einer
dahinter-liegenden Ebene der Qualitätssicherung. Wenn man solche Karten
mit einbringt, sollte man diese als solche kenntlich machen.

Die guten Karten bringen ja meistens etwas Zusatzlogik mit, wie die
klickbaren Haltestellen der ÖPNV oder auch Legenden. Auf so was zu
verzichten wäre schade.

Neben Karten sehe ich auch sowas wie eine Straßenliste für den
Ausschnitt als eine mögliche Anwendung.

Wenn eine Karte so gut ist, das sie auf die Hauptkarte mit soll, dann
sollte es nicht am Server scheitern, ggf. sollte dann osm.org einen
Serverplatz dem Kartenaentwickler anbieten.

Grüße Tim

Am 28.05.2011 21:22, schrieb Kai Krueger:

Kai

[1]
http://wiki.openstreetmap.org/wiki/Strategic_working_group/New_Tile_Layer_Guidelines
[2] http://wiki.openstreetmap.org/wiki/Featured_tiles

--
View this message in context:
http://gis.638310.n2.nabble.com/Kandidaten-fuer-weitere-tile-layer-auf-osm-org-tp6415090p6415090.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] Kandidaten fuer weitere tile layer auf osm.org?

2011-05-28 Diskussionsfäden Kai Krueger

Kolossos wrote:

Hallo, wenn man systematisch durchgeht, auf welche Weisen sich Menschen
auf der Welt fortbewegen und dafür Karten brauchen, fiele mir dafür
spontan die ÖPNV-Karte ein.

Die ÖPNV-Karte waere sicherlich auch einer meiner Favoriten. Die Frage aber
ist: entspricht die Karte den zuvor genannten Kriterien? Das heisst will der
Autor der ÖPNV-Karte es und sind die Server leistungsfaehig genug?

Alternativ gibt es den Transport layer, der OpenCycleMap die ebenfalls den
oeffentlichen Nahverkehr darstellt. Die erfuellt so weit ich weis die
meisten der genannten Kriterien und koennte somit aufgenommen werden.

Kolossos wrote:

Eine Seekarte wäre auch nicht schlecht, allerdings bringt OpenSeaMap im
Binnenland nicht viel.

Die Kriterien sagen nur das die Karte weltweit verfuegbar sein muss, nicht
das sie Weltweit nuetzlich ist.. ;-) Umgekehrt ist eine Strassenkarte auch
auf dem Meer nicht nuetzlich und der Pazifik und Atlantik deckt
wahrscheinlich mehr als die Haelfte der Weltoberflaeche ab. Insofern wuerde
ich das nicht unbedingt als das Problem sehen.

Kolossos wrote:

Ein Wanderkarte mit Höhenrelief wäre nicht schlecht (hikebikemap) und
etwas für die überregionalen Bahnstrecken, Parkplätze und POIs.

Die hikebikemap waere sicherlich auch eine gute Option, aber wiederum ist
die Frage wuerde es in diesem Fall Wikimedia (toolserver) unterstuetzen das
die Karte auf osm.org angezeigt wird? Ausserdem muesste die Updates
funktionieren, die zum Teil auf dem Toolserver wohl etwas problematisch
sind.

Kolossos wrote:

Stromleitungen und anderes führen bei Ottonormal-Netznutzer vielleicht
eher zur abschreckende Frage: Was soll ich damit? Was nützt das mir?

Ich persoenlich faende eine Stromleitungskarte gerade sehr interessant. Aus
meiner Sicht ist Sinn des ganzen den Leuten zu vermitteln das OpenStreetMap
eben nicht nur eine Street Map ist, sonder das man so ziemlich alles
erfassen kann auch sehr spezielle Dinge die die meisten normalerweise nicht
interessieren wuerden. Dafuer waere eine Stromleitungskarte oder andere
spezial Karten sehr gut geeignet. Es wuerde auch den Punkt herueber bringen
das nicht jede Karte alles was gemappt wird anzeigen muss, sonder das man
dafuer eben Spezialkarten erzeugen kann. Das haette den Vorteil das es
vielleicht etwas den Druckt nimmt alle features auf der Haupt mapnik Karte
darstellen zu wollen.

Kolossos wrote:

Die guten Karten bringen ja meistens etwas Zusatzlogik mit, wie die
klickbaren Haltestellen der ÖPNV oder auch Legenden. Auf so was zu
verzichten wäre schade.

Legenden waeren moeglich. Es haben ja auch derzeit alle vier Kartenstile
eine Legende. Zusatz features wie klickbare Haltestellen wird es aber auf
osm.org wohl eher nicht geben. Dazu muss man dann doch auf die eigentlichen
Webseiten gehen.

Kolossos wrote:

Wenn eine Karte so gut ist, das sie auf die Hauptkarte mit soll, dann
sollte es nicht am Server scheitern, ggf. sollte dann osm.org einen
Serverplatz dem Kartenaentwickler anbieten.

Es waere schoen wenn es nicht am Server scheitern wuerde, aber auf die OSMF
kann man vermutlich nicht zaehlen. Nach allem was ich bislang gehoert habe
lehnt es die OSMF ab Serverkapazitaeten fuer weitere Kartenstile oder
Dienste bereit zu stellen. Die OSMF versucht insgesamt moeglichst
minimalistisch zu bleiben und sich nur um die Daten(bank) zu kuemmern. Alles
was irgendwie nach Endanwender riecht versucht sie wenn moeglich zu umgehen
und verweist auf etwaige Drittanbieter. Insofern muessten Serverkapazitaeten
fuer Zusaetzlayer durch andere organisiert werden (z.B. durch lokale Gruppen
wie den FOSSGIS, Firmen, oder Privatspenden)

Insofern sind weitere Layer bislang meistens eher doch an mangelnder
Serverkapazitaet gescheitert.

Kai

--
View this message in context:
http://gis.638310.n2.nabble.com/Kandidaten-fuer-weitere-tile-layer-auf-osm-org-tp6415090p6415692.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-in] GSoC Project's Name Suggestion

2011-05-28 Diskussionsfäden Parveen Arora

Finally I have selected MeraMap as my project name.
I liked it because it is a simple small word, easy to remember and
easy to pronounce.
In includes Mera which refers to the community's own Map, and Map
already has a well defined definition i.e A diagrammatic
representation of an area of land or sea showing physical features,
cities, roads, etc.
I have joined these two words, to make it just single word.

Thanks to all of you for your help and support.

--
Parveen Arora
www.parveenarora.in

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

Re: [Talk-it] Targhe commemorative

2011-05-28 Diskussionsfäden Simone Saviolo

Il giorno 28 maggio 2011 18:59, Damjan Gerl dam...@damjan.net ha scritto:

 Io per queste cose uso historic=memorial [0] anche se non sembrerebbe
 giusto, però per il testo Much like a monument, but smaller. Might range
 from a WWII memorial to a simple plate on a wall. dalla pagina principale
 di Map Features, mi sembra che ci siamo


Anch'io ho usato historic=memorial, con memorial=plate:
http://www.openstreetmap.org/browse/node/1223218514

Ciao,

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

Re: [Talk-it] Targhe commemorative

2011-05-28 Diskussionsfäden M∡rtin Koppenhoefer

2011/5/29 Simone Saviolo simone.savi...@gmail.com:
 Il giorno 28 maggio 2011 18:59, Damjan Gerl dam...@damjan.net ha scritto:

 Io per queste cose uso historic=memorial [0] anche se non sembrerebbe
 giusto, però per il testo Much like a monument, but smaller. Might range
 from a WWII memorial to a simple plate on a wall. dalla pagina principale
 di Map Features, mi sembra che ci siamo

 Anch'io ho usato historic=memorial, con memorial=plate:
 http://www.openstreetmap.org/browse/node/1223218514


se volete inserire delle foto in un database per proprio questo tema,
c'è un apposito progetto appena nato e con licenza pd:
http://openplaques.org/
http://openplaques.org/places/it

ciao,
Martin

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

Re: [Talk-at] Nutzung der Stadt Wien OGD-Daten

2011-05-28 Diskussionsfäden David Schmitt


Hallo Andres,

On 27/05/11 10:37, Andreas Trawoeger wrote:

Hallo an Alle!

Gestern war das erste Open Government Data (OGD) Plattform Treffen der
Stadt Wien und dabei war die Nutzung der Daten durch OpenStreetMap
kurz ein Thema.

Der aktuelle Stand aus Sicht der Stadt Wien ist folgender:
- Aus Sicht der Stadt Wien steht der Nutzung der OGD Daten durch OSM
grundsätzlich nichts im Wege
- Was die durch die CC BY 3.0 [0] geforderte Namensnennung  betrifft,
würde es der Stadt Wien (eventuell) reichen, wenn die Stadt Wien unter
http://www.openstreetmap.org/copyright als Datenquelle genannt wird.
- Wir bekommen das (vielleicht) auch in irgendeiner Form schriftlich

Beim nächtsten OGD Treffen am 30. Juni 2011 [1] sollen die für das
Thema zustängigen JuristInnen teilnehmen, wo wir das Thema im Detail
besprechen bzw. eventuell endgültig klären können.

Zusätzlich soll bis zum nächsten OGD Treffen der Katalog der
verfügbaren Daten weiter ausgebaut werden und es sind in dem
Zusammenhang die Worte Hausnummern, Bildkacheln und Orthofotos
gefallen. Welche Daten aber in welcher Form freigegeben werden, wird
erst wirklich klar sein sobald es soweit ist.



Zuerstmal ein Dankschön im Namen aller schweigsamen Lurker wie mir, dass 
Du da schon am Ball bist!



Ist es möglich/sinnvoll/angedacht einige der Basisdatensätze (zB 
Bezirksgrenzen) automatisiert und regelmässig zu übernehmen?



MfG David

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

Re: [Talk-at] Fahrradrouten von Alltagsradlern - Commuteing Cycle Network?

2011-05-28 Diskussionsfäden Felix Hartmann

Aus genau den Gründen, ist class:bicycle einfach besser. Das kannst ja 
genauso als Netzwerk aufbauen, noch dazu als intelligentes Netwerk, dass 
sich ergibt...


On 28.05.2011 21:05, Friedrich Volkmann wrote:

On 05/28/11 18:10, Markus Straub wrote:
ich würde gerne wissen was ihr vom Taggen von Alltagsradwegen in Form 
eines

Netzwerks haltet.


Gar nichts, weil die Vorlieben individuell verschieden sind. Der eine 
fährt lieber am Radweg, der andere lieber auf der Fahrbahn. Der eine 
lieber den schnelleren, der andere lieber den ruhigeren Weg. Wir 
mappen das, was existiert, und brauchen uns keine Routen ausdenken. 
Das ist Sache der Anwendungen (Router) und ihrer Parameter.



Ausgangspunkt: Hier in Wien gibt es ein sehr zerstückeltes offizielles
Radwegenetz, das nur teilweise die tatsächlich gefahrenen Routen (vor 
allem

vom Alltagsradverkehr -- 'commuter') wiedergibt.


Dieses Radwegenetz ist nur ein Propagandainstument der 
Stadtpolitiiker. Nach dem Motto: Wir sind so gut, denn wir fördern den 
Radverkehr. Wir fördern ihn, indem wir das Radwegenetz um soundsoviel 
verlängern. Dazu werden z.B. grüne Schilder aufgestellt und schwupps 
kann man die Straßenlänge schon dazurechnen. Aber immer noch besser 
als wirkliche Radwege, denn die sind erwiesenermaßen gefährlich 
(Abbieger, Fußgänger, Hunde, Dreck...).


Für Alltagsradler sind Radwege nur dort von Nutzen, wo für Pkw ein 
Fahrverbot ist, z.B. durch den Prater. Aber sogar dort hab ich schon 
erlebt, dass ich einer ausgeschilderten Radroute gefolgt bin und 
plötzlich mitten auf einer Großbaustelle war...



In anderen Städten (z.B.
Linz) gibt es innerhalb der Stadt überhaupt keine beschilderten Radwege.


Blaue Lollis aber schon? Würde mich sonst wundern.

In der Realität existiert aber ein solches Netz und ich würde in es 
in Wien

gerne mit Hilfe der lokalen Fahrradlobby/vereinigung einzeichnen.


www.argus.or.at, die selbsternannte Radlerlobby. Mit etwas Glück sagen 
sie dir das gleiche wie ich.


Meine Recherche zum passenden Taggingschema hat mich zu nichts 
existierendem
geführt, ich könnte mir aber vorstellen einen neuen Typ von Cycle 
Routes[1]

einzuführen:
network=ccn (commuting cycle network)


Konsequenterweise müsste man dann auch ein network=cpcn (commuting 
passenger car network) und ein cln (cummuting lorry network) usw. 
einführen.


Eh gut. Dann haben Anfänger wenigstens die Chance, zuerst unwichtige 
Relationen hinzumachen. :-)





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

[Talk-at] Haltestellendaten

2011-05-28 Diskussionsfäden liberalerhumanist

Ich lese gerade im Standard einen Artikel, in dem beklagt wird, dass die ÖBB 
ihre Fahrplandaten (und damit die des gesamten Österreichischen ÖPNV) nicht an 
Google Maps übergeben wollen, damit diese ihr eigenes ÖPNV-Routing-System 
basteln können. 

Gäbe es die Möglichkeit, bei uns in die Haltestellen einen Link auf die 
Abfahrtsauskunft auf der ÖBB-Fahrplanauskunft zu setzen? Eine 
Nutzungsmöglichkeit für den Benutzer wäre die Möglichkeit, von einem 
Internetfähigen Endgerät aus auf der Karte die nächste Haltestelle zu suchen 
und durch einen Klick die nächsten Abfahrten einsehen zu können. Die 
entsprechende Seite für eien Beispielhaltestelle sieht so aus 
(http://fahrplan.oebb.at/bin/stboard.exe/dn?L=vs_livetickerevaId=915033boardType=depproductsFilter=0dirInput=tickerID=depstart=yeseqstops=falseshowJourneys=12additionalTime=0),
 die Integration des Links in einen Tag dürfte kein Problem sein.  

MfG, LH
-- 
NEU: FreePhone - kostenlos mobil telefonieren!  
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)

2011-05-28 Diskussionsfäden Jean-Guilhem Cailton

Hi,

Great find Daniel !

To use directly the GeoTiff images in JOSM, you could try the
ImportImagePlugin, but I haven't tried it.

I put the EO1-ALI images from Earth Observatory online, in WMS and TMS,
with the coordinates included in the GeoTiff files.

Apparently, they were not georeferenced in relation to ground control
points, but with the imagery layer shift option included in Josm, it is
not too difficult to align them to existing data. For example, a shift
of 197; -514 quickly adjusted over Venise-en-Québec seems to give a
reasonable alignment in other areas of the images too.

We could try to improve the georeferencing of the original images with
ground control points, but for now it seems that having a try at mapping
the flood extent with the current setup has higher priority. Let me know
if you think more work on georeferencing would be useful.


URLs:

For the natural color image in TMS (recommended over WMS), use the
following link in Josm:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_coulnat/{zoom}/{x}/{y}.jpg

For the shortwave infrared image in TMS:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_swir/{zoom}/{x}/{y}.jpg


The base WMS URL is :
http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map

Thus, for the natural color image in WMS, use the following link in Josm:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.mapFORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20110508_natcol;

For the shortwave infrared image in WMS:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.mapFORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20110508_swir;


Now on to OSM-style-collaborative-iterative flood extent mapping,
without - and probably then with - boots :)

Best wishes,

Jean-Guilhem


Le 28/05/2011 05:53, Daniel Begin a écrit :

 Hi all,

  

 I've tried to put my boots on the ground without  going there !-).
  I found a pretty clear satellite image of the river at its max level
 (30-31m) - which doesn't really changed since ...

  

 http://earthobservatory.nasa.gov/NaturalHazards/view.php?id=50577

  

 I made few geometric adjustments to the image and compare the result
 with 30m GeoBase and SRTM contours. Geobase contours gives better
 results between St-Jean and L'Île aux Noix but from there to the US
 boundary, neither GeoBase nor SRTM is right.

  

 I'm trying to produce a flooded area from DEM data while I'm looking
 at an image that contains what I'm looking for - the flooded area! 
 Why not mapping from it? I understand the image can be used -
 http://earthobservatory.nasa.gov/ImageUse/

  

 Any idea on how I can use this GeoTiff image in JOSM?

  

 Cheers,

 Daniel

  

  

 



-- 
pgp 0x5939EAE2

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

[Talk-ca] Railways duplicated in CanVec data

2011-05-28 Diskussionsfäden Samuel Longiaru

I've been importing in south central BC and have noticed that there is a
consistent duplication of railway = rail ways in the CanVec data.  No
big deal as if I forget, it is caught by the validator, but there must
be a glitch somewhere in converting to OSM?

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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec

2011-05-28 Diskussionsfäden Daniel Begin

Hi all,

an image interpretation of the flooded area of Haut-Richelieu has been
uploaded, replacing the first work done by Pierre (Thanks to Pierre) .It's
time to put our boots on the ground - in the water?!!

Daniel

 

  _  

From: Jean-Guilhem Cailton [mailto:j...@arkemie.com] 
Sent: May-28-11 07:07
To: Daniel Begin; Pierre Beland
Cc: 'HOT Openstreetmap'; 'talk-ca'
Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada
:Follow-up(Complement of information)

 

Hi,

Great find Daniel !

To use directly the GeoTiff images in JOSM, you could try the
ImportImagePlugin, but I haven't tried it.

I put the EO1-ALI images from Earth Observatory online, in WMS and TMS, with
the coordinates included in the GeoTiff files. 

Apparently, they were not georeferenced in relation to ground control
points, but with the imagery layer shift option included in Josm, it is not
too difficult to align them to existing data. For example, a shift of 197;
-514 quickly adjusted over Venise-en-Québec seems to give a reasonable
alignment in other areas of the images too.

We could try to improve the georeferencing of the original images with
ground control points, but for now it seems that having a try at mapping the
flood extent with the current setup has higher priority. Let me know if you
think more work on georeferencing would be useful.


URLs:

For the natural color image in TMS (recommended over WMS), use the following
link in Josm:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_coulnat/{zoom}/
{x}/{y}.jpg

For the shortwave infrared image in TMS:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_swir/{zoom}/{x}
/{y}.jpg


The base WMS URL is : 
http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map

Thus, for the natural color image in WMS, use the following link in Josm:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map
http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.mapFORMA
T=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20
110508_natcol
FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautriche
lieu20110508_natcol

For the shortwave infrared image in WMS:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map
http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.mapFORMA
T=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20
110508_swir
FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautriche
lieu20110508_swir


Now on to OSM-style-collaborative-iterative flood extent mapping, without -
and probably then with - boots :)

Best wishes,

Jean-Guilhem


Le 28/05/2011 05:53, Daniel Begin a écrit : 

Hi all,

 

I've tried to put my boots on the ground without  going there !-).  I
found a pretty clear satellite image of the river at its max level (30-31m)
- which doesn't really changed since ...

 

http://earthobservatory.nasa.gov/NaturalHazards/view.php?id=50577

 

I made few geometric adjustments to the image and compare the result with
30m GeoBase and SRTM contours. Geobase contours gives better results between
St-Jean and L'Île aux Noix but from there to the US boundary, neither
GeoBase nor SRTM is right.

 

I'm trying to produce a flooded area from DEM data while I'm looking at an
image that contains what I'm looking for - the flooded area!  Why not
mapping from it? I understand the image can be used -
http://earthobservatory.nasa.gov/ImageUse/

 

Any idea on how I can use this GeoTiff image in JOSM?

 

Cheers,

Daniel

 

 

  _  

 






-- 
pgp 0x5939EAE2
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec

2011-05-28 Diskussionsfäden Pierre Béland

Daniel Begin wrote on 2011-05-28 
 an image interpretation of the flooded area of Haut-Richelieu has been 
 uploaded, replacing the first work done by Pierre (Thanks to Pierre) .It's 
 time to put our boots on the ground -  in the water?!!

Fantastic, Daniel.  Whats about a super-relation to show simultaneously the 6 
relations you created?

Just a bit of insight.

I have to tell you that after three weeks of long boots, walking in the water, 
we start to be a bit tired. But it's nothing as compared to affected peoples. 
Some are discouraged, stressed and very emotional, isolated in their houses 
surrounded by corrupted water.  After more than a month, there are still 
families that have to leave the house behind, because of the contaminution and 
health risks.

The planning of the Grande Corvée (Big drudgery ?) to show solidarity to 
these people is going very well. After last monday high waters and the 
prediction of high waters for tomorrow again, the public reaction to the 
various medias was spontaneous and fantastic. In three days, 3,000 people have 
already called to indicate their participation at the Grande Corvée planned 
for the 11-12 of june. If weather help! And all kind of propositions are made 
to help affected people : Pick-up Trucks, food,  psychological help, tow truck, 
amphibious vehicle, chain saws, etc.

regards, 




Pierre Béland 




De : Daniel Begin 
Date/heure : 2011-05-28  13:10:39 
A : 'Jean-Guilhem Cailton'; 'Pierre Beland' 
Cc : 'HOT Openstreetmap'; 'talk-ca' 
Sujet : RE: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec 
 
Hi all,
an image interpretation of the flooded area of Haut-Richelieu has been 
uploaded, replacing the first work done by Pierre (Thanks to Pierre) .It's time 
to put our boots on the ground - in the water?!!
Daniel
 



From: Jean-Guilhem Cailton [mailto:j...@arkemie.com] 
Sent: May-28-11 07:07
To: Daniel Begin; Pierre Beland
Cc: 'HOT Openstreetmap'; 'talk-ca'
Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada 
:Follow-up(Complement of information)
 
Hi,

Great find Daniel !

To use directly the GeoTiff images in JOSM, you could try the 
ImportImagePlugin, but I haven't tried it.

I put the EO1-ALI images from Earth Observatory online, in WMS and TMS, with 
the coordinates included in the GeoTiff files. 

Apparently, they were not georeferenced in relation to ground control points, 
but with the imagery layer shift option included in Josm, it is not too 
difficult to align them to existing data. For example, a shift of 197; -514 
quickly adjusted over Venise-en-Québec seems to give a reasonable alignment in 
other areas of the images too.

We could try to improve the georeferencing of the original images with ground 
control points, but for now it seems that having a try at mapping the flood 
extent with the current setup has higher priority. Let me know if you think 
more work on georeferencing would be useful.


URLs:

For the natural color image in TMS (recommended over WMS), use the following 
link in Josm:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_coulnat/{zoom}/{x}/{y}.jpg

For the shortwave infrared image in TMS:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_swir/{zoom}/{x}/{y}.jpg


The base WMS URL is : 
http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map

Thus, for the natural color image in WMS, use the following link in Josm:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.mapFORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20110508_natcol;

For the shortwave infrared image in WMS:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.mapFORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20110508_swir;


Now on to OSM-style-collaborative-iterative flood extent mapping, without - and 
probably then with - boots :)

Best wishes,

Jean-Guilhem


Le 28/05/2011 05:53, Daniel Begin a écrit : 
Hi all,
 
I've tried to put my boots on the ground without  going there !-).  I found a 
pretty clear satellite image of the river at its max level (30-31m) - which 
doesn't really changed since ...
 
http://earthobservatory.nasa.gov/NaturalHazards/view.php?id=50577
 
I made few geometric adjustments to the image and compare the result with 30m 
GeoBase and SRTM contours. Geobase contours gives better results between 
St-Jean and L'Île aux Noix but from there to the US boundary, neither GeoBase 
nor SRTM is right.
 
I'm trying to produce a flooded area from DEM data while I'm looking at an 
image that contains what I'm looking for - the flooded area!  Why not mapping 
from it? I understand the image can be used - 
http://earthobservatory.nasa.gov/ImageUse/
 
Any idea on how I can use this GeoTiff image in JOSM?
 
Cheers,
Daniel
 
 



 




-- 
pgp 0x5939EAE2
___
Talk-ca mailing list
Talk-ca@openstreetmap.org

Re: [Talk-ca] Railways duplicated in CanVec data

2011-05-28 Diskussionsfäden Adam Dunn

Indeed. In fact, this issue has already been listed on the wiki page:
http://wiki.openstreetmap.org/wiki/CanVec#CanVec_7
:)

Adam

On Sat, May 28, 2011 at 9:06 AM, Samuel Longiaru longi...@shaw.ca wrote:
 I've been importing in south central BC and have noticed that there is a
 consistent duplication of railway = rail ways in the CanVec data.  No big
 deal as if I forget, it is caught by the validator, but there must be a
 glitch somewhere in converting to OSM?

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



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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada:Follow-up(Complement of information)

2011-05-28 Diskussionsfäden Pierre Béland

Jean-Guilhem Cailton wrote on 2011-05-28
 I put the EO1-ALI images from Earth Observatory online, in WMS and TMS, with 
 the coordinates included in the GeoTiff files. 

I created a openlayers page accessing the two images. We have the ability to 
overlay the natural color image over the base layers (opacity=0.5).

url : 
http://pierzen.dev.openstreetmap.org/hot/openlayers/richelieu-flooding-2011.htm 

regards




Pierre Béland 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-cz] Navigace OSMAnd - odbočování na dálnici

2011-05-28 Diskussionsfäden CZ_Tibo

Pokud se nejedná o chybu, tak dálnice pravděpodobně v daném místě zatáčí 
doleva, zatímco odbočka k pumpě vede v přímém směru. To by měla navigace buď 
ignorovat, nebo hlásit jako držte se vlevo, nikoli odbočte doleva. Nejsem 
si ale jistý, jestli OSMAnd toto rozlišuje.
Opravit to půjde změnou tvaru odbočky, aby svírala s dálnicí větší úhel.

Tibo

  Původní zpráva 
 Od: Marek Prokop ma...@sovavsiti.cz
 Předmět: [Talk-cz] Navigace OSMAnd - odbočování na dálnici
 Datum: 27.5.2011 21:43:55
 
 Ahoj,
 
 před pár dny jsem začal používat navigaci OSMAnd na Androidu a všiml
 jsem si zajímavé věci. Po cestě z Prahy do Jihlavy po D1 mi na dvou
 místech říkala, ať zahnu doleva. V obou případech to bylo na místě
 odbočky k pumpě. Na zpáteční cestě bylo takové místo jedno.
 
 Jedná se o chybu navigace, nebo je na těch místech v OSM něco nevhodně
 otagováno, co bych mohl opravit?
 
 Díky,
 
 Marek
 
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz
 
 
 

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

Re: [Talk-cz] Navigace OSMAnd - odbočování na dálnici

2011-05-28 Diskussionsfäden Marek Prokop

Ahoj,

 dálnice pravděpodobně v daném místě zatáčí doleva,
 zatímco odbočka k pumpě vede v přímém směru.

Ano, je to tak.

 To by měla navigace buď ignorovat, nebo hlásit jako
 držte se vlevo, nikoli odbočte doleva. Nejsem si ale
 jistý, jestli OSMAnd toto rozlišuje.

Někdy rozlišuje, ale zde ne.

 Opravit to půjde změnou tvaru odbočky,
 aby svírala s dálnicí větší úhel.

Vyzkouším, ale nenapadá někoho, jak to pak co nejrychleji otestovat?
Přeci jen bych nerad po každé opravě znovu jezdil do Jihlavy ;-)

Díky,

Marek

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

Re: [Talk-cz] Navigace OSMAnd - odbočování na dálnici

2011-05-28 Diskussionsfäden Jirka Daněk

2011/5/28 Marek Prokop ma...@sovavsiti.cz

Vyzkouším, ale nenapadá někoho, jak to pak co nejrychleji otestovat?
 Přeci jen bych nerad po každé opravě znovu jezdil do Jihlavy ;-)


Android má v menu Nastavení v sekci Aplikace možnosti ohledně povolení
instalace aplikací třetích zdrojů, povolení debugování… Taky je tam povolení
simulovaných poloh.

Takže by mělo jít tohle zapnout, připojit telefon k počítači a v Androidím
SDK tomu dát gpx soubor který to má simulovat. Nevím, jestli se to dá udělat
na příkazové řádce (asi ano), ale v pluginu do Eclipse je na to klikátko.

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

Re: [Talk-cz] Navigace OSMAnd - odbočování na dálnici

2011-05-28 Diskussionsfäden Karel Volný


 Opravit to půjde změnou tvaru odbočky, aby svírala s dálnicí větší úhel.

mno, dosti pochybuju, že by tohle ŘSD zafinancovalo, a jelikož jde i o moje 
daně, tak za sebe jsem zásadně proti

- co takhle radši opravit tu navigaci?

K.

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

Re: [OSM-talk-fr] Pédagogie...

2011-05-28 Diskussionsfäden JonathanMM

Le 28/05/2011 00:18, Vincent Pottier a écrit :
 Sinon il y a des choses comme ça :
 http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum
Mais c'est excellent ce truc \o/
Bon, petit bémol, perso, j'aurais mis Les boutiques : shop=* au lieu de
Les boutiques *=shop
À part ça, je trouve que ça ferait un excellent cadeau de bienvenue aux
nouveaux membres du projet ;)
JonathanMM

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

Re: [OSM-talk-fr] Pédagogie...

2011-05-28 Diskussionsfäden Vincent Pottier


Le 28/05/2011 09:27, JonathanMM a écrit :

Le 28/05/2011 00:18, Vincent Pottier a écrit :

Sinon il y a des choses comme ça :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum

Mais c'est excellent ce truc \o/
Bon, petit bémol, perso, j'aurais mis Les boutiques : shop=* au lieu de
Les boutiques *=shop

Sur quelle fiche ?
Et puis c'est libre... Donc ça se corrige facilement par quiconque.

À part ça, je trouve que ça ferait un excellent cadeau de bienvenue aux
nouveaux membres du projet ;)
En tout cas je crois que ça commence à trouver sa place dans les 
mapping-parties.

--
FrViPofm

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

Re: [OSM-talk-fr] Pédagogie...

2011-05-28 Diskussionsfäden JonathanMM

Le 28/05/2011 09:53, Vincent Pottier a écrit :
 Le 28/05/2011 09:27, JonathanMM a écrit :
 Le 28/05/2011 00:18, Vincent Pottier a écrit :
 Sinon il y a des choses comme ça :
 http://wiki.openstreetmap.org/wiki/WikiProject_France/Osmecum
 Mais c'est excellent ce truc \o/
 Bon, petit bémol, perso, j'aurais mis Les boutiques : shop=* au lieu de
 Les boutiques *=shop
 Sur quelle fiche ?
La toute première de la page : A la ville, niveau facile ;)
 Et puis c'est libre... Donc ça se corrige facilement par quiconque.
Certes, mais je suis flemmard :p
JonathanMM

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

Re: [OSM-talk-fr] Source de données potentielle: Onema/ROE (Référentiel des Obstacles à l’Ecoulement)

2011-05-28 Diskussionsfäden RatZilla$

Bonjour @tou[te]s,

Merci Vincent pour le rappel de cette info.
La personne en charge de cette base à l'ONEMA m'a sollicité aux
rencontres SIG La Lettre pour une réunion à ce sujet.
Que pensez vous de la semaine 24 ou 25 pour une rencontre à Paris
autour de ce sujet?
Qui est volontaire pour un échange ?

Gaël

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

[OSM-talk-fr] Compte rendu KAL-Haïti

2011-05-28 Diskussionsfäden RatZilla$

Bonjour @tou[te]s,

Jean Guilhem Cailton, Nicolas Chavent et moi même avons participé aux
ateliers contributeurs Kal-Haïti Jeudi et Vendredi dernier à Télécom
ParisTech.

Il s'agit d'un projet de mise en commun de données pour des projets
d'études , de Construction et de Reconstruction d'Haïti.
Nous sommes intervenus surtout dans la gestion de crise et
l'aménagement du territoire.
Nous avons suscité beaucoup d'intérêt car OSM a été depuis le séisme
une des bases la plus complète.
De nombreux organismes nous connaissent et travaillent avec des données OSM.

Ces ateliers ont été l'occasion pour nous d'insister sur les licences
associées aux données (filaire, photos etc ...)
mais aussi d'avoir des avis d'experts sur la qualité des données et
les possibilité d'améliorer OSM.
Ce projet va durer 4 ans avec une forte demande de doctorants ou de
stagiaires dans les thématiques citées plus haut.
Jean et Nicolas n'hésitez pas à compléter ce post si j'omets de citer
des points importants.

Cordialement,

Gaël

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

[OSM-talk-fr] Radars de contrôle routier et OSM

2011-05-28 Diskussionsfäden Christian Rogel

Tout le monde sait que le gouvernement français communique abondamment 
sur la suppression de l'information sur les emplacements de radars de 
contrôle de vitesse sur les routes.
Il ne faut pas en déduire qu'il faudrait supprimer les indications de 
radars répertoriées par OSM en France :
- Commme l'indique le wiki OSM (versions anglaise et française), il faut 
s'abstenir de cartographier les radars dans les pays où le repérage est 
interdit, ce qui n'est pas du tout le cas en France.

(cela doit exister dans des dictatures)
Ce qui est annoncé, c'est l'interdiction de commercialiser des 
applications qui donnent les emplacements et les usagers pourraient se 
voir infliger jusqu'à 1 500 € d'amendes, s'ils les utilisent.
- Les forces de police pourront-elles vraiment vérifier qu'une 
application est dans le téléphone mobile, l'autoradio ou... le climatiseur?
- Le gouvernement peut viser les sociétés commerciales, même si elles 
font appel à des participations citoyennes, mais pas les individus qui 
envoient les infos
- Les applications et, au premier chef, la carte de base OSM, seront 
hors d'atteinte si elles sont sur un serveur à l'étranger


Remarque perso : Cela va peut-être relancer la CB.


Christian



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

Re: [OSM-talk-fr] Radars de contrôle routier et OSM

2011-05-28 Diskussionsfäden Thomas Clavier

Le 28/05/2011 12:33, Christian Rogel a écrit :
 Tout le monde sait que le gouvernement français communique abondamment
 sur la suppression de l'information sur les emplacements de radars de
 contrôle de vitesse sur les routes.
 Il ne faut pas en déduire qu'il faudrait supprimer les indications de
 radars répertoriées par OSM en France

Surtout qu'il n'y a ni décret ni loi  D'autre part le Comité
interministériel de la sécurité routière indique dans sa mesure 2 :
Interdire tous les avertisseurs de radars.

* Jusqu’à deux ans de prison et 30 000 euros d’amende pour la vente
  d’appareils signalant la position des radars (fixes et mobiles).
* Jusqu’à 1 500 euros d’amende et le retrait de 6 points pour la
  possession de ce type de matériel.


Et dans sa mesure 3 : Supprimer l’annonce des radars.

* Les cartes de radars ne seront plus rendues publiques.


Tout ça pour dire que rien n'est dit sur la collecte de l'information.
Le sujet n'ayant pas encore été abordé, malgré sa place dans les médias,
je suppose qu'il ne motive pas grand monde :-)

-- 
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org
+33 (0)6 20 81 81 30   +33 (0)950 783 783



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Radars de contrôle routier et OSM

2011-05-28 Diskussionsfäden Eric SIBERT


Tout ça pour dire que rien n'est dit sur la collecte de l'information.


C'est un peu le problème de cette mesure, c'est qu'il faut se crever les 
yeux avant de prendre la route...


Sinon, rien n'interdit les applications qui indiquent en permanence les 
limitations de vitesse, bien au contraire. Faites chauffer le tag 
maxspeed=* ;-)


Eric

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

Re: [OSM-talk-fr] Comment différencier une Zone 30 d'une limitation à 30 ?

2011-05-28 Diskussionsfäden adrien carpentier

Pour l'instant sur Lille, nous avons codés les z30 uniquement avec le
maxspeed, je partage l'avis général que ça n'est pas satisfaisant, surtout
pour les applications pour les cyclistes, une zone 30 est bien un
aménagement pour les vélos et les piétons, ce que n'est pas une rue limitée
à 30
cependant, ici les rues limitées à 3O sont des z30, il n'y a pas ou très peu
de rues limitées à 30km/h
je suis assez partant pour un tag supplémentaire du type :
FR:zone30=yes, et faire taffer les bots...
@+
adrien

Le 27 mai 2011 14:50, Vincent Pottier vpott...@gmail.com a écrit :

 Le 27/05/2011 14:18, Olivier Cédric a écrit :

  Le 27/05/2011 13:39, Pieren a écrit :

 2011/5/27 Olivier Cédriccedric.oliv...@free.fr

  Je ne trouve pas cela normal ... limiter la zone 30 uniquement à
 l'aspect
 limitation de vitesse à 30 km/h est très réducteur de ce qu'est
 réellement
 une zone 30 :


  C'est le panneau lui-même qui se limite à cette information principale.
 Le
 fait que les vélos puissent circuler à double sens est assez récent et
 nécessite l'ajout d'un autre panneau de toute façon (et un autre tag dans
 OSM aussi).

 Dans Besançon, ils ont peint des petits vélos à contre sens par terre, ça
 permet de rappeler aux voitures qu'elles risquent de rencontrer des
 cyclistes. Mais pas de panneau en plus.

  Moi je ne taggue pratiquement jamais les zones 30 parce que contrairement
 à
 ce que dit le texte cité, les panneaux de fins de zones ne sont que très
 rarement présents sur le terrain. Bref, on nous montre toujours quand ça
 commence mais jamais quand ça finit. Ca fait toujours quelques euros de
 gagné en pannaux de signalisation...
 Vous pouvez ajouter tous les nouveaux tags imaginables, si un logiciel
 veut
 traiter les limites de vitesses dans OSM, il se contentera du tag
 maxspeed.

 Certes, mais...

  Tout le reste est trop aléatoire (valeurs par défaut, etc) et
 aucun logiciel ne prendra le risque de spéculer sur une vitesse limite
 (ou
 la circulation à contre sens des vélos) suivant des polygones landuse ou
 un
 source:maxspeed sans valeur effective ou qui varie d'un pays à l'autre
 (je
 sais que les allemands s'en servent beaucoup mais c'est du local).

 Il faut aussi préciser que les living_street ou zones de rencontre n'ont
 rien à voir avec les zones 30.

 Pour conclure, dans un sens unique d'une zone 30, je préfère voir les
 tags:
 - oneway=yes
 - maxspeed=30
 - bicycle=opposite

 plutôt que
 - oneway=yes
 - source:maxspeed=zone30 ou urban:30 ou FR:urban:zone:30 ou BE:zone20,
 etc

 Pieren


 Je pense tout de même qu'il serait interessant de pouvoir dissocier les
 zone 30 des simples limitations à 30.
 Par contre je suis 100% d'accord, qu'il faut laisser le maxspeed=30,
 oneway=yes, bicycle = opposite etc si il y a autre chose...

 Je me contenterais bien d'ajouter en + de ces informations FR:zone30=yes,
 ce qui permettra en cas de modification de législation de savoir repérer
 facilement les zone 30 dans OSM.

 Tout à fait d'accord pour que l'info maxspeed, bicycle... bref toutes les
 spécificités de la zone 30 soient indiquées sur le way, pour qu'elle soit
 exploitée.
 Mais ça fait redondant et je suis paresseux. Et faire la mise à jour à la
 main... pfff.
 Et bien c'est à ça que servent les robots.


 Le 27/05/2011 12:15, Ab_fab a écrit :

  Dans l'esprit, cela se rapproche de cette relation 934933 code de la
 Route [1], appliquée à la relation 11980 [2] pour la France Métropolitaine.
 Si les règles changeaient au niveau national, il suffirait d'aller
 modifier la valeur ici.
 Et sous la condition que la pratique d'utilisation de ce schéma se
 développe et qu'il soit utilisé par les logiciels de routage.
 [1] http://www.openstreetmap.org/browse/relation/934933
 [2] http://www.openstreetmap.org/browse/relation/11980

  Je doute aussi que dans un avenir proche, les logiciels de routage en
 tiennent compte.
 Donc robots taggeurs.
 C'est relativement simple de lire les informations dans la relation Code
 de la route et de les appliquer aux highways ayant le tag qui va bien.
 Mais s'il vous plaît pas un source:*
 source est fait pour autre chose.

 Bon, je ne sais pas bien faire ça... Mais d'autres sont très doués.

 Probablement que la syntaxe de la relation defaults est perfectible, plus
 genre xpath...
 Mais c'est une piste.

 Promis, s'il y a un bot qui pose et révise périodiquement les tags maxspeed
  bicycle sur les zones 30, je mets les tags zone 30 !
 --
 FrViPofm


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




-- 
http://www.virage-energie-npdc.org/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Radars de contrôle routier et OSM

2011-05-28 Diskussionsfäden Lionel Gueganton

Bonjour,
Je suis le sujet et j'ai aussi vu que certaines déclarations semblaient 
indiquer que l'état pourrait donner les limitations de vitesses, les zones 
dangeureuses et l'état du traffic.
http://www.accessoweb.com/Les-avertisseurs-de-radars-ne-seront-pas-interdits-en-France-mais-modifies_a9147.html
C'est un vrai partenariat qui unira les fabricants avec l'Etat où ce dernier 
devra fournir les limitations de vitesse, l'état du traffic et les zones 
dangereuses. 

Reste à voir comment, sous quelle license. 
Mais il est vrai que si la license s'y prête, cela pourrait être un moyen de 
pallier à la pauvreté de renseignement du tag maxspeed= dans OSM (si je ne 
m'abuse il est assez peu renseigné non ? ou alors j'ai une fausse idée de sa 
popularité ?)

Lionel.


On May 28, 2011, at 6:19 PM, Eric SIBERT wrote:

 Tout ça pour dire que rien n'est dit sur la collecte de l'information.
 
 C'est un peu le problème de cette mesure, c'est qu'il faut se crever les yeux 
 avant de prendre la route...
 
 Sinon, rien n'interdit les applications qui indiquent en permanence les 
 limitations de vitesse, bien au contraire. Faites chauffer le tag maxspeed=* 
 ;-)
 
 Eric
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-ja] Potlatch2操作ガイド

2011-05-28 Diskussionsfäden Shu Higashi

東です。

Potlatch2操作ガイドシリーズその２です。
お店で貰ったレシートを元に描く方法をまとめました。
これであなたもレシートを簡単に捨てられなくなりますw

◆Calc版
http://dl.dropbox.com/u/201898/osm/Potlatch2/Potlach2_example1_POI_by_receipt.ods

◆Excel版
http://dl.dropbox.com/u/201898/osm/Potlatch2/Potlach2_example1_POI_by_receipt.xls

(それぞれ約7MBあります)



11/05/24 Shu Higashi s_hig...@mua.biglobe.ne.jp:
 東です。

 以前、大和田さんがOSM入門講座をやろうとした際に
 使える資料があまりに少ないことにいまさらながら気付いてしまったので
 初めての方に編集操作を説明できることを目指して
 まずはPotlatch2の操作ガイドを作ってみました。
 よろしければご自由にお使いください。

 スクリーンショットを張り付けて簡単な説明を付けただけですので
 過度な期待は禁物です ^^;
 随時改版していくつもりです。

 ◆Calc版
 http://dl.dropbox.com/u/201898/osm/Potlatch2/Potlatch2_guide_0_1.ods

 ◆Excel版
 http://dl.dropbox.com/u/201898/osm/Potlatch2/Potlatch2_guide_0_1.xls

 (それぞれ約20MBあります)


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

Re: [Talk-GB] Kent Pharmacy, OSM Validation

2011-05-28 Diskussionsfäden Ed Avis

TimSC mapping@... writes:

I have done further investigations. As I said, the national dataset has 
about 90% of pharmacies exactly located. But in the Kent data set does 
not include this precise data and instead has the postcode centre as the 
pharmacy position. IMHO, if we can get permission for the national level 
data set, we should import/merge the good 90% (and manually survey the 
remainder).

If pharmacies are just points with lat/lon, it is not always simple to import
into the existing map, even if we knew the position were entirely accurate.
The road network in OSM has some margin for error so a pharmacy might end up
on the wrong side of the road.  In areas with buildings, the pharmacy node might
appear in the next-door building by mistake.

That said, if you are looking for a pharmacy, it is certainly more useful to 
have
one within a five metre accuracy rather than no data at all.  So I would still
be in favour of adding the data.

-- 
Ed Avis e...@waniasset.com


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

Re: [Talk-GB] Kent Pharmacy, OSM Validation

2011-05-28 Diskussionsfäden TimSC


I have given the site a face lift:

http://toolserver.org/~timsc/locateservices/

Is there anyone interesting in testing a beta on a different data set? I 
would supply the code and help to try to get it imported. Basic HTML 
would be good but not necessary. They would also need somewhere to host 
it (with PHP enabled) - like the OSM dev server.


Regarding importing with clashes against nearby shops, I would say that 
is a reason FOR doing an import, as it shows the deficiencies in the 
existing data!


TimSC

On 28/05/11 14:33, Ed Avis wrote:

TimSCmapping@...  writes:


I have done further investigations. As I said, the national dataset has
about 90% of pharmacies exactly located. But in the Kent data set does
not include this precise data and instead has the postcode centre as the
pharmacy position. IMHO, if we can get permission for the national level
data set, we should import/merge the good 90% (and manually survey the
remainder).

If pharmacies are just points with lat/lon, it is not always simple to import
into the existing map, even if we knew the position were entirely accurate.
The road network in OSM has some margin for error so a pharmacy might end up
on the wrong side of the road.  In areas with buildings, the pharmacy node might
appear in the next-door building by mistake.

That said, if you are looking for a pharmacy, it is certainly more useful to 
have
one within a five metre accuracy rather than no data at all.  So I would still
be in favour of adding the data.




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

Re: [Talk-us] US highway classification

On Fri, May 27, 2011 at 10:04 AM, Nathan Mills nat...@nwacg.net wrote:
 On Fri, 27 May 2011 09:26:41 -0400, Nathan Edgars II wrote:

 No, trunk is also used for a major intercity highway that's not a
 freeway. Take a look at the UK and their network of trunks.

 I'm sorry, I thought I posted to talk-us. My mistake. ;)

 Seems to me that trunk has no meaning if it is used in that way.

Trunk has no meaning beyond color the road the same color as other
things that are tagged trunk.

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

Re: [Talk-us] Ideas for OSMF US Swag

2011-05-28 Diskussionsfäden Kai Krueger


Thea Aldrich wrote:
 
 My two cents about the flyers. I really like the one produced by
 GeoFabrik.
 However, it might be nice to make a few tweeks to that model so its more
 US
 centric and plays better in this market. But thats just me...
 
Great.

Yes I too think a few tweeks to make it more US centric would be good,
though, to make sure it attracts people in the US with their needs.

--
View this message in context: 
http://gis.638310.n2.nabble.com/Ideas-for-OSMF-US-Swag-tp6408754p6414252.html
Sent from the USA mailing list archive at Nabble.com.

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

Re: [Talk-us] US highway classification

2011-05-28 Diskussionsfäden Mike N


On 5/28/2011 9:12 AM, Anthony wrote:

Trunk has no meaning beyond color the road the same color as other
things that are tagged trunk.


  Even color is not defined - some trunks can be toll / not toll.

  However, trunk *could* serve as a router hint that the road is a 
better selection than primary / secondary.


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

Re: [Talk-us] US highway classification

2011-05-28 Diskussionsfäden Richard Welty


On 5/28/11 10:40 AM, Mike N wrote:

On 5/28/2011 9:12 AM, Anthony wrote:

Trunk has no meaning beyond color the road the same color as other
things that are tagged trunk.


  Even color is not defined - some trunks can be toll / not toll.

  However, trunk *could* serve as a router hint that the road is a 
better selection than primary / secondary.

yes, it could, and that would be a valid reason for the distinction.

but for that, we need to use it consistently and there need to be
some focused meaning that usage.

richard


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

Re: [Talk-us] US highway classification


On Sat, 28 May 2011 01:36:00 -0400, Nathan Edgars II wrote:



I mean best route, period. There's no diagonal Interstate there.


US-71 to I-44 to I-40 is faster. Not really a route I'd enjoy, but 
still faster.


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

Re: [Talk-us] US highway classification

On Sat, May 28, 2011 at 10:40 AM, Mike N nice...@att.net wrote:
 On 5/28/2011 9:12 AM, Anthony wrote:

 Trunk has no meaning beyond color the road the same color as other
 things that are tagged trunk.

  Even color is not defined - some trunks can be toll / not toll.

  However, trunk *could* serve as a router hint that the road is a better
 selection than primary / secondary.

In my experience the difference between primary and trunk is generally
very minor, to the point where I'm not sure there'd be any advantage
at all in a router using it as a hint.

But maybe that's just because the places where I use OSM are mapped wrong.

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

Re: [Talk-us] US highway classification


On Sat, 28 May 2011 15:19:03 -0400, Anthony wrote:

In my experience the difference between primary and trunk is 
generally

very minor, to the point where I'm not sure there'd be any advantage
at all in a router using it as a hint.

But maybe that's just because the places where I use OSM are mapped 
wrong.


Using NE2's criteria, trunk is not really any different from a routing 
standpoint than primary. Using mine, trunk is something that would be 
primary if it weren't a physically better sort of road, so should be 
preferred over a nearby primary if the distances are similar. I'm 
harping on physical characteristics for this one particular tag because 
I think without that as a differentiator, it's basically useless fluff 
we shouldn't be using at all because primary already covers that usage.


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

Re: [Talk-us] US highway classification


On 5/28/2011 3:39 PM, Nathan Mills wrote:

On Sat, 28 May 2011 15:19:03 -0400, Anthony wrote:


In my experience the difference between primary and trunk is generally
very minor, to the point where I'm not sure there'd be any advantage
at all in a router using it as a hint.

But maybe that's just because the places where I use OSM are mapped
wrong.


Using NE2's criteria, trunk is not really any different from a routing
standpoint than primary.


No, trunk is to primary as primary is to secondary.

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

Re: [Talk-us] US highway classification


On Sat, 28 May 2011 20:54:07 -0400, Nathan Edgars II wrote:


You described your criteria, but did not explain how trunk is more
appropriate than primary for a two lane rural highway between two
small-to-tiny cities. If you use trunk for that, there is no way to
describe (in a way that shows up on the tiles) a road which is not a
motorway but is better than the typical rural highway.


There are many types of roads that it's not possible to describe. How
do you tag an unpaved classified road so the map shows that it's
unpaved (this is very common in the third world, but also occurs in
extremely rural areas of the US)? You don't.


Don't let the perfect be the enemy of the good, my friend. It's 
nonsensical to say that just because there are other roads that can't be 
adequately described (few and far between in my experience, but perhaps 
more common out west than I'm aware) we should waste trunk on US 
highways that could be adequately described with primary.





I also upgrade major state-numbered highways from secondary to
primary. This leaves more breathing room in secondary and tertiary 
for

the lesser roads.


As makes sense if the highway is the most direct non-Interstate,
non-trunk route between two regionally important cities. Why would 
trunk

be used for the same thing? That's what I've been trying (apparently
rather poorly) to get at.


I understand your assumption - that trunk is only to be used for
surface expressways. I simply disagree.


So you continue to assert that trunk is most useful if it essentially a 
duplicate of primary?


Take, as an example, US 84 in western Alabama. Why on earth did you 
change it to trunk when it's a terribly substandard road that isn't even 
a major route between cities of any real size? The westernmost couple of 
miles in Alabama were being upgraded last I was there, but the rest of 
it from Elba on west is pretty bad, excluding the bypasses, of course. 
There is no reasonable standard that could have it classified the same 
as 231 between Dothan and Montgomery or even 280 between Birmingham and 
Columbus, GA, now that it's almost 100% upgraded and almost all of the 
towns are bypassed. It makes zero sense to a user of the map. (of which 
I count myself..I've been eating my own dog food for a few years now, 
which is why I care in more than an abstract way)


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

Re: [Talk-us] US highway classification

On Sat, May 28, 2011 at 9:13 PM, Nathan Mills nat...@nwacg.net wrote:
 Take, as an example, US 84 in western Alabama.

FWIW, Google has it as the top level non-motorway.  As far as I can
tell there's no other more important east-west road within 50 miles.

What road would you use traveling east/west along the same route?

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

Re: [Talk-us] US highway classification

On Sat, May 28, 2011 at 9:27 PM, Anthony o...@inbox.org wrote:
 On Sat, May 28, 2011 at 9:13 PM, Nathan Mills nat...@nwacg.net wrote:
 Take, as an example, US 84 in western Alabama.

 FWIW, Google has it as the top level non-motorway.  As far as I can
 tell there's no other more important east-west road within 50 miles.

 What road would you use traveling east/west along the same route?

Say, Dothan, Alabama to Hattiesburg, Mississippi, avoid motorways.
What should the router take?

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

Re: [Talk-us] US highway classification


On Sat, 28 May 2011 21:30:50 -0400, Anthony wrote:


Say, Dothan, Alabama to Hattiesburg, Mississippi, avoid motorways.
What should the router take?


In that particular case, it should in fact take US-84. (US-231 to I-10 
to US-98 would in fact be faster; I know this having taken both routes, 
but you said avoid motorways) But US-84 ought to be tagged primary for 
the reasons I previously stated. Trunk is useless if it describes the 
same thing that primary does. Primary means (at least according to most 
of the wiki pages) the primary non-motorway route between two cities. It 
does not imply any particular quality of road. That seems perfectly 
applicable to US-84 in most of central and western Alabama.


Another example is US-71 between Fort Smith and Texarkana. It is in 
fact the fastest route between Fort Smith and Texarkana, but it is 
terribly slow going. The fact that it is the fastest route between those 
two regionally important cities is adequately described by primary. Why, 
then, are we wasting trunk on something like that? Trunk seems more 
appropriate for OK-51 between I-35 and Stillwater or the non-turnpike 
(and non-city) sections of US-412 between Tulsa, OK and Springdale, AR 
where it has a meaning above and beyond what primary means.


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

Re: [Talk-us] US highway classification


On 5/28/2011 9:13 PM, Nathan Mills wrote:

So you continue to assert that trunk is most useful if it essentially a
duplicate of primary?

Maybe a duplicate of your version of primary, but not mine.


Take, as an example, US 84 in western Alabama. Why on earth did you
change it to trunk when it's a terribly substandard road that isn't even
a major route between cities of any real size?


It's been rebuilt as a good-quality four-lane in Mississippi, eastern 
Alabama, and Georgia. Alabama has been a little slower at four-laning 
than its neighbors, but US 84 in western Alabama is still a direct route 
connecting the four-laned portions.


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

Re: [Talk-us] US highway classification


On 5/28/2011 9:47 PM, Nathan Mills wrote:

Another example is US-71 between Fort Smith and Texarkana. It is in fact
the fastest route between Fort Smith and Texarkana, but it is terribly
slow going. The fact that it is the fastest route between those two
regionally important cities is adequately described by primary. Why,
then, are we wasting trunk on something like that?
I could ask you the same question: why are we wasting primary on what 
can be adequately described by trunk?


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

Re: [Talk-us] US highway classification


On Sat, 28 May 2011 21:51:31 -0400, Nathan Edgars II wrote:


It's been rebuilt as a good-quality four-lane in Mississippi, eastern
Alabama, and Georgia. Alabama has been a little slower at four-laning
than its neighbors, but US 84 in western Alabama is still a direct
route connecting the four-laned portions.


More than a little slower. There's perhaps 20 miles of four lane in 
Alabama west of Enterprise. Maybe 30 if they've completed the far 
western section they were working on last time I was through there. As I 
mentioned in another post, it's faster to detour to I-10. And once 
again, the 'direct route' issue is adequately communicated with the 
primary tag.


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

Re: [Talk-us] US highway classification

On Sat, May 28, 2011 at 10:39 PM, Anthony o...@inbox.org wrote:
 On Sat, May 28, 2011 at 9:47 PM, Nathan Mills nat...@nwacg.net wrote:
 Primary means (at least according to most of the wiki pages)
 the primary non-motorway route between two cities.

 Any wiki pages that say that are clearly wrong.  Trunk is the primary
 non-motorway route between two cities.  Yes, it's dumb terminology,
 but it's too late to fix that.

You agree that if a router has two possible roads to take between two
cities, and one is a trunk, and one is a primary, and all other things
are equal, that the router should choose the trunk, right?  Doesn't
that make trunk, by definition, the primary non-motorway route between
two cities?

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

Re: [Talk-us] US highway classification


On Sat, 28 May 2011 22:39:51 -0400, Anthony wrote:
On Sat, May 28, 2011 at 9:47 PM, Nathan Mills nat...@nwacg.net 
wrote:

Primary means (at least according to most of the wiki pages)
the primary non-motorway route between two cities.


Any wiki pages that say that are clearly wrong.  Trunk is the primary
non-motorway route between two cities.  Yes, it's dumb terminology,
but it's too late to fix that.


If it were clearly wrong, we wouldn't be having this discussion.

Another example is US-71 between Fort Smith and Texarkana. It is in 
fact the
fastest route between Fort Smith and Texarkana, but it is terribly 
slow
going. The fact that it is the fastest route between those two 
regionally
important cities is adequately described by primary. Why, then, are 
we

wasting trunk on something like that?


Do you agree that a road which would be a trunk in one area of the
world might not be a trunk in another area?  Or do I first have to
convince you of that?


I said as much previously. Obviously, I'm only considering the US, 
given that this is talk-us. I guess I'm just failing to see what use 
trunk is if it's essentially interchangeable with primary.


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

Re: [Talk-us] US highway classification




You agree that if a router has two possible roads to take between two
cities, and one is a trunk, and one is a primary, and all other 
things

are equal, that the router should choose the trunk, right?  Doesn't
that make trunk, by definition, the primary non-motorway route 
between

two cities?


Only if trunk has a meaning that implies that a road tagged trunk is 
somehow better than a road tagged primary, which it apparently does not, 
at least in some people's minds. If you're going to waste trunk on curvy 
two lane roads, a router may as well use distance or maxspeed as a 
better metric. As it stands, some of us are using trunk as more of a 'I 
know it when I see it' thing than something useful for routing purposes 
like motorway.


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

Re: [Talk-us] US highway classification

On Sat, May 28, 2011 at 10:49 PM, Nathan Mills nat...@nwacg.net wrote:
 On Sat, 28 May 2011 22:39:51 -0400, Anthony wrote:

 On Sat, May 28, 2011 at 9:47 PM, Nathan Mills nat...@nwacg.net wrote:

 Primary means (at least according to most of the wiki pages)
 the primary non-motorway route between two cities.

 Any wiki pages that say that are clearly wrong.  Trunk is the primary
 non-motorway route between two cities.  Yes, it's dumb terminology,
 but it's too late to fix that.

 If it were clearly wrong, we wouldn't be having this discussion.

It is, and we are.

 Another example is US-71 between Fort Smith and Texarkana. It is in fact
 the
 fastest route between Fort Smith and Texarkana, but it is terribly slow
 going. The fact that it is the fastest route between those two regionally
 important cities is adequately described by primary. Why, then, are we
 wasting trunk on something like that?

 Do you agree that a road which would be a trunk in one area of the
 world might not be a trunk in another area?  Or do I first have to
 convince you of that?

 I said as much previously. Obviously, I'm only considering the US, given
 that this is talk-us.

Right, which leads to my next question.  Do you agree that a road
which would be a trunk in one area of the US might not be a trunk in
another area?

Grove Hill, Alabama, and New York City, New York don't exactly have
very much in common.

 I guess I'm just failing to see what use trunk is if it's essentially 
 interchangeable with primary.

It's not essentially interchangeable with primary.

On Sat, May 28, 2011 at 10:52 PM, Nathan Mills nat...@nwacg.net wrote:
 You agree that if a router has two possible roads to take between two
 cities, and one is a trunk, and one is a primary, and all other things
 are equal, that the router should choose the trunk, right?  Doesn't
 that make trunk, by definition, the primary non-motorway route between
 two cities?

 Only if trunk has a meaning that implies that a road tagged trunk is somehow
 better than a road tagged primary, which it apparently does not, at least in
 some people's minds.

So no, routers shouldn't choose trunk over primary, all other things
being equal?

 If you're going to waste trunk on curvy two lane roads,
 a router may as well use distance or maxspeed as a better metric.

We're assuming maxspeed isn't present.

So, if the primary road is 2 inches shorter than the trunk, the router
should take the primary?

And the reasoning for this is, to spite the people who wasted trunk
on curvy two lane roads (when there was nothing better in a 50 mile
radius)?

Instead of giving me hypothetical if..then answers, can you give me a
straightforward answer?

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

Re: [Talk-us] US highway classification


On Sat, 28 May 2011 23:00:11 -0400, Anthony wrote:


Instead of giving me hypothetical if..then answers, can you give me a
straightforward answer?


You're trying to get an exact answer to something that isn't an exact 
science, so no. I'm allowing for the fact that there may be a situation 
in which trunk should be applied to a two lane road because not doing so 
would misrepresent the area to viewers of the map and routing engines 
more than not using it would. I don't have personal experience with 
every road in the US, after all. In the cases I've personally seen, I 
think the roads could have been adequately described with primary.


Obviously, my preference would be that trunk only be used for roads 
with more than two lanes and a barely-existent shoulder, but barring 
that I would like it to mean 'very important road that is not a 
motorway.'


And yes, as it presently stands, a routing engine would probably be 
better off using the two foot shorter primary than the two foot longer 
trunk, given that we have a bunch of roads tagged as trunk that are no 
more suitable for long distance travel than most roads tagged as 
primary.


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

Re: [Talk-us] US highway classification


On 5/28/2011 10:52 PM, Nathan Mills wrote:

Only if trunk has a meaning that implies that a road tagged trunk is
somehow better than a road tagged primary, which it apparently does not,
at least in some people's minds. If you're going to waste trunk on curvy
two lane roads, a router may as well use distance or maxspeed as a
better metric. As it stands, some of us are using trunk as more of a 'I
know it when I see it' thing than something useful for routing purposes
like motorway.


Your same argument applies to the difference between primary and 
secondary, and that between secondary and tertiary.


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

Re: [Talk-us] US highway classification


On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:


If you want to get people to tag more than two lanes and a
barely-existent shoulder, I think you'd have much more success
creating tags for those features than convincing people that their
area of the country isn't allowed to have any trunks.


That's quite the misrepresentation of what I'm saying. Again, my point 
is that trunk is much more useful (especially to people using rendered 
mapnik tiles) if it is mainly restricted to four lane divided sorts of 
roads here in the US. You can bring up all the corner cases you want, 
but that doesn't change the fact that using trunk to describe roads that 
can adequately handled with primary (for all purposes, no less!) means 
that it's simply not possible to represent that with any tagging simple 
enough to be reliably used everywhere.


US-441 between St. Cloud and Yeehaw Junction could easily be trunk by 
NE2's definition (and apparently yours, although you haven't really 
indicated how exactly it should be used), but is also adequately 
described by primary, and handily enough renders rather well.


Yeah, we shouldn't tag specifically for the renderer, but we shouldn't 
waste tags either. Nor should we avoid being mindful of how things are 
rendered.


Perhaps if you explain it very slowly, you can help me understand why 
primary isn't emphatic enough in the cases that have been mentioned. Or 
how it is that a routing engine would be confused by them being tagged 
as primary rather than trunk (as many of them were for years before NE2 
went off and changed them). As I said, I see those changes as making the 
map less useful to someone reading it, not more useful.


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

Re: [Talk-us] US highway classification

On Sun, May 29, 2011 at 12:37 AM, Nathan Mills nat...@nwacg.net wrote:
 On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:
 If you want to get people to tag more than two lanes and a
 barely-existent shoulder, I think you'd have much more success
 creating tags for those features than convincing people that their
 area of the country isn't allowed to have any trunks.

 That's quite the misrepresentation of what I'm saying.

It was an exact quote.

 Again, my point is
 that trunk is much more useful (especially to people using rendered mapnik
 tiles) if it is mainly restricted to four lane divided sorts of roads here
 in the US.

And my point is 1) that you aren't going to convince people to do
that; and 2) that if you could convince people to tag the number of
lanes, you'd be better off having them use a tag which says the number
of lanes.

On Sun, May 29, 2011 at 12:37 AM, Nathan Mills nat...@nwacg.net wrote:
 US-441 between St. Cloud and Yeehaw Junction could easily be trunk by NE2's
 definition (and apparently yours, although you haven't really indicated how
 exactly it should be used)

I indicated how trunk should be used in my first post to this thread.
When you've got a non-motorway, and you want mapnik to color the road
green, and show it at z5, you use trunk.

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

Re: [Talk-us] US highway classification


On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:


convincing people that their
area of the country isn't allowed to have any trunks.


Also, why is this any worse than not having a motorway? I don't think 
the folks in Newton County Arkansas care a whit whether the main road 
through their very rural county is trunk or primary or secondary or even 
tertiary. The roads in that county just aren't major roads. That's not 
disparaging the people, it's just a statement of what is.


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

Re: [Talk-us] US highway classification

On Sun, May 29, 2011 at 12:59 AM, Nathan Mills nat...@nwacg.net wrote:
 On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:

 convincing people that their
 area of the country isn't allowed to have any trunks.

 Also, why is this any worse than not having a motorway?

Why is what worse than not having a motorway?

 I don't think the
 folks in Newton County Arkansas care a whit whether the main road through
 their very rural county is trunk or primary or secondary or even tertiary.

They do if they're looking at a map, and none of the roads are drawn,
because tertiaries aren't drawn at that zoom level.

On Sun, May 29, 2011 at 12:37 AM, Nathan Mills nat...@nwacg.net wrote:
 US-441 between St. Cloud and Yeehaw Junction could easily be trunk by NE2's
 definition (and apparently yours, although you haven't really indicated how
 exactly it should be used)

Having now looked at it quickly on other maps, yes, I think it could.

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

Re: [Talk-us] US highway classification


On Sun, 29 May 2011 00:57:30 -0400, Anthony wrote:


That's quite the misrepresentation of what I'm saying.


It was an exact quote.


You may have heard of the concept of the pull quote. It describes 
using partial quotations to misrepresent someone else's position.



Again, my point is
that trunk is much more useful (especially to people using rendered 
mapnik
tiles) if it is mainly restricted to four lane divided sorts of 
roads here

in the US.


And my point is 1) that you aren't going to convince people to do
that; and 2) that if you could convince people to tag the number of
lanes, you'd be better off having them use a tag which says the 
number

of lanes.


I find it difficult to believe that you object so strenuously to making 
it simple to tag one of the main things an end user of a road map 
desires to know when looking at said map. Is it a practical you can't 
get people to agree to that objection, or a I don't think it should be 
done that way objection?


Once again, there is, to most non-mapgeeks a class of road which is 
less than a motorway, but better than all other classes of road. In my 
part of the country, most people call it an expressway. This should be 
easy to tag, so that the map is most useful to end users (and simple to 
edit for casual editors, who you're almost certainly not going to 
convince to tag width and lane count on every edit). Trunk seems to fit 
that bill, and is used that way already in many areas. It was used that 
way in a lot more areas until one specific editor decided he wanted to 
edit roads in places he's never even been to use that designation. I 
can't think of a downside to using it that way.


What advantage does trunk have over primary in any of the mentioned 
examples?


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

Re: [Talk-us] US highway classification


On Sun, 29 May 2011 01:04:24 -0400, Anthony wrote:
On Sun, May 29, 2011 at 12:59 AM, Nathan Mills nat...@nwacg.net 
wrote:

On Sun, 29 May 2011 00:13:33 -0400, Anthony wrote:


convincing people that their
area of the country isn't allowed to have any trunks.


Also, why is this any worse than not having a motorway?


Why is what worse than not having a motorway?


Not having any trunks. Why is that worse than not having any motorways?


I don't think the
folks in Newton County Arkansas care a whit whether the main road 
through
their very rural county is trunk or primary or secondary or even 
tertiary.


They do if they're looking at a map, and none of the roads are drawn,
because tertiaries aren't drawn at that zoom level.


I don't think it's a problem if rural areas have a low density of roads 
drawn at low zoom. That's how most every map made is drawn. (Yes, 
tertiary may have been taking it too far, but for reasons of rendering, 
not the importance of the road)


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

Re: [Talk-us] US highway classification

On Sun, May 29, 2011 at 1:08 AM, Nathan Mills nat...@nwacg.net wrote:
 On Sun, 29 May 2011 00:57:30 -0400, Anthony wrote:

 That's quite the misrepresentation of what I'm saying.

 It was an exact quote.

 You may have heard of the concept of the pull quote. It describes using
 partial quotations to misrepresent someone else's position.

Yes, I have.

 And my point is 1) that you aren't going to convince people to do
 that; and 2) that if you could convince people to tag the number of
 lanes, you'd be better off having them use a tag which says the number
 of lanes.

 I find it difficult to believe that you object so strenuously to making it
 simple to tag one of the main things an end user of a road map desires to
 know when looking at said map.

Good, because I don't.

 Is it a practical you can't get people to
 agree to that objection, or a I don't think it should be done that way
 objection?

It's both.  I don't think you are going to convince people to base the
trunk tag on the number of lanes, and I don't think we should use the
term trunk to tag the fact that a road has four lanes.

 Once again, there is, to most non-mapgeeks a class of road which is less
 than a motorway, but better than all other classes of road. In my part of
 the country, most people call it an expressway. This should be easy to tag,
 so that the map is most useful to end users (and simple to edit for casual
 editors, who you're almost certainly not going to convince to tag width and
 lane count on every edit).

I agree.

 Trunk seems to fit that bill, and is used that way already in many areas.

Here I disagree.  The problem with using trunk to represent the class
of road, and primary to represent the most important non-motorway, is
that you can't tag something trunk *and* primary.

 What advantage does trunk have over primary in any of the mentioned
 examples?

It is rendered at z5.

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

Re: [Talk-us] US highway classification