date:20110609

Am 9. Juni 2011 23:02 schrieb Manuel Reimer :
> Hallo,
>
> wie werden denn Wege zu Nutzgärten, bzw. Schrebergärten korrekt getaggt?
>
> Ich tendiere hier zwischen highway=track oder highway=service.


ich würde eher service nehmen, auf dem Land aber vielleicht auch mal
track, kann beides passen, je nach Situation.

Gruß Martin

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

[Talk-de] Wie Wege zu Gärten taggen?

2011-06-09 Diskussionsfäden Manuel Reimer


Hallo,

wie werden denn Wege zu Nutzgärten, bzw. Schrebergärten korrekt getaggt?

Ich tendiere hier zwischen highway=track oder highway=service.

Gruß

Manuel


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

Re: [Talk-de] postgresql (osmosis schema) liste von nodes -> Polygon?

Am Donnerstag, den 09.06.2011, 20:38 + schrieb Sven Geggus:
> Alexander Matheisen  wrote:
> 
> > Warum kann man nicht wie bisher mit osm2pgsql eine hstore DB updaten?
> 
> Weil es keinen Sinn ergibt wenn wir sowieso Spezialdatenbaken
> erzeugen. Die osmosis Datenbank ist einfach universeller und hat
> außerdem auch schon länger ebenfalls einen hstore.

Wie werden die Spezialdatenbanken erzeugt? Ein simples INSERT/SELECT?


Alex


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

Re: [Talk-de] postgresql (osmosis schema) liste von nodes -> Polygon?

Am Donnerstag, den 09.06.2011, 13:32 -0700 schrieb Walter Nordmann:
> Alexander Matheisen wrote:
> > 
> > Warum kann man nicht wie bisher mit osm2pgsql eine hstore DB updaten?
> Das mit osmosis erzeugte snapshot-schema enthält selbstverständlich auch
> einen hstore.
> 
> Ausserdem haben "wir" keine Probleme damit - eventuell nur du?

Ich sicher nicht, aber wenn das neue System keinen nennenswerten Vorteil
bringen würde, dann muss man sich ja nicht unnötige Arbeit machen.

Waren auch nur Überlegungen eines Außenstehenden. Nun weiß ich ja auch,
warum die osmosis-Lösung besser ist.

Alex

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

Re: [Talk-de] postgresql (osmosis schema) liste von nodes?->?Polygon?

Sarah Hoffmann  wrote:

> SELECT ST_PointOnSurface(ST_MakePolygon(ST_MakeLine(n.geom))) 
>FROM (SELECT unnest(nodes) 
>FROM ways WHERE id = 99382824) as w, nodes n 
> WHERE w.unnest = n.id;

Danke! Das sieht doch schonmal gut aus:

http://www.openstreetmap.org/?zoom=18&mlat=48.22436155&mlon=8.58008285781844

900913 brauch ich dafür nicht. Soll ja kml werden.

Gruss

Sven

-- 
"Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
Source-Betriebssystem bedenken sollten, ist, dass Sie kein
Windows-Betriebssystem erhalten." (von http://www.dell.de/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] postgresql (osmosis schema) liste von nodes -> Polygon?

On Thu, Jun 09, 2011 at 01:26:38PM -0700, Walter Nordmann wrote:
> st_centroid berechnet die Mittelpunkt des Polygons; dieser kann aber bei
> bestimmten Formen des Polygons durchaus ausserhalb der Fläche liegen (z.B.
> Bumerang oder U).
> 
> st_pointOnSurface garantiert, dass der Punkt innerhalb der Fläche liegt;
> dieser kann aber nicht immer im Zentrum sein, wenn da ein Stück fehlt.

Korrekt. Die Centroid-Methode hat aber den Vorteil, dass sie immer
funktioniert, selbst dann, wenn das Polygon gerade kaputt ist.
Es kommt halt auf den Anwendungsfall an.

Gruss

Sarah

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

Re: [Talk-de] postgresql (osmosis schema) liste von nodes -> Polygon?

Alexander Matheisen  wrote:

> Warum kann man nicht wie bisher mit osm2pgsql eine hstore DB updaten?

Weil es keinen Sinn ergibt wenn wir sowieso Spezialdatenbaken
erzeugen. Die osmosis Datenbank ist einfach universeller und hat
außerdem auch schon länger ebenfalls einen hstore.

Gruss

Sven

-- 
How to prevent Java from forking? Use a spoon.
(Found on http://slashdot.org)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] postgresql (osmosis schema) liste von nodes -> Polygon?


Alexander Matheisen wrote:
> 
> Warum kann man nicht wie bisher mit osm2pgsql eine hstore DB updaten?
Das mit osmosis erzeugte snapshot-schema enthält selbstverständlich auch
einen hstore.

Ausserdem haben "wir" keine Probleme damit - eventuell nur du?

Gruss
Walter

-
Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst 
sehen, dass da kein Wald ist.
--
View this message in context: 
http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6459514.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] postgresql (osmosis schema) liste von nodes -> Polygon?

st_centroid berechnet die Mittelpunkt des Polygons; dieser kann aber bei
bestimmten Formen des Polygons durchaus ausserhalb der Fläche liegen (z.B.
Bumerang oder U).

st_pointOnSurface garantiert, dass der Punkt innerhalb der Fläche liegt;
dieser kann aber nicht immer im Zentrum sein, wenn da ein Stück fehlt.


gruss
walter

p.s. das gilt übrigens für ALLE Datenbank-Schemata, die hier so benutzt
werden - auch das mit osm2pgsql erzeute. Wenn die Mapnik-Leute im Template
für das Rendern  den centroid gegen pointonsurface auswechseln würden, lägen
manche Ortsbezeichnungen nicht mehr auf fremden Stadtgebiet. (Eltville am
Rhein)

-
Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst 
sehen, dass da kein Wald ist.
--
View this message in context: 
http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6459492.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] postgresql (osmosis schema) liste von nodes -> Polygon?

ganz einfach:

weil die mit osm2pgsql erzeugte datenbank besser zum rendern geeignet ist
und die mit osmosis im snapshot-schema gepflegte dafür vielseitiger ist.

beide haben ihre vor- und nachteile.

gruss
walter


-
Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst 
sehen, dass da kein Wald ist.
--
View this message in context: 
http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6459444.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] postgresql (osmosis schema) liste von nodes -> Polygon?

Jetzt mal generell:
Warum kann man nicht wie bisher mit osm2pgsql eine hstore DB updaten?
Warum braucht man osmosis? Bei dem bisherigen Datenbankschema kann man
ja auch andere Tabellen herausfiltern und wir haben nicht die Probleme,
wie man dies oder jenes nun abfragt.


Alex


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

Re: [Talk-de] postgresql (osmosis schema) liste von nodes -> Polygon?

On Thu, Jun 09, 2011 at 06:48:54PM +, Sven Geggus wrote:
> Hallo zusammen,
> 
> vielleicht kann ja jemand von euch ein wenig helfen.
> 
> Ich versuche einen SQL Befehl zu basteln, der Mittelpunkt einer
> Fläche ausgibt (ST_PointOnSurface).
> 
> Dazu muss man wohl zuerst aus Punkten eine Fläche machen und dann mit
> hilfe von ST_PointOnSurface den Mittelpunkt der Fläche zu ermitteln.
> 
> 
> osmdb=>  select nodes from ways where id=99382824;
>   nodes   
> --
>  {1149487195,1149487106,1149487674,1149487557,1149487195}
> (1 Zeile)
> 
> Da fängt jetzt mein Problem schon an. "nodes" ist ein bigint[]
> 
> Wie mache ich jetzt ein select für alle diese nodes in der Liste?
> 
> Also folgendes hätte ich gerne:
> 
> * liste der nodes aus Tabelle ways
> * geometrien aller dieser nodes aus Tabelle nodes
> * Polygon aus disen Geometrien (ST_)
> * ST_PointOnSurface(Polygon)

SELECT ST_PointOnSurface(ST_MakePolygon(ST_MakeLine(n.geom))) 
FROM (SELECT unnest(nodes) 
FROM ways WHERE id = 99382824) as w, nodes n 
 WHERE w.unnest = n.id;

aber ich wuerde es eher damit versuchen (geht schneller):

SELECT ST_Centroid(ST_Collect(n.geom))
FROM (SELECT unnest(nodes) 
FROM ways WHERE id = 99382824) as w, nodes n 
 WHERE w.unnest = n.id;

Und vermutlich willst du auch noch in 900913 transformieren.

Sarah

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

Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)

2011-06-09 Diskussionsfäden Tobias Knerr

Am 09.06.2011 20:06, schrieb M∡rtin Koppenhoefer:
> Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier
> (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post
> zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch
> wenn man das vollständig in den Griff bekommen könnte durch
> eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen
> Namen und keine weiteren Informationen.

Hier hast du generell recht. Ein Freitext-Feld funktioniert für Dinge
wie operator nicht wirklich gut.

Ich hätte vor kurzem wahrscheinlich noch vehement widersprochen - und
für die aktuellen Werkzeuge hat die Vorsicht vor Relationen auch ihre
Berechtigung. Aber das muss ja nicht so bleiben. Daher: Kann man machen,
wenn man sich um die Bedienbarkeit kümmert.

> M.E. könnte OSM extrem dazugewinnen, wenn wir die "Struktur der Welt"
> auch im "nichträumlichen Bereich" in unserer Datenbank hätten. Wir
> könnten z.B. die Tätigkeitsfelder von Organisationen oder
> Geschäftsfelder von Firmen abbilden.

Ein semantisches Modell der Welt ist ein sehr ambitioniertes Ziel, und
geht mir persönlich im OSM-Kontext dann doch eher zu weit. Eine
eindeutige Grenze ist schwer anzugeben, aber je weiter sich etwas von
Geodaten entfernt, desto weniger sinnvoll finde ich eine Aufnahme in
OSM. Ich kann mir vorstellen, den Architekten eines Gebäudes
einzutragen. Dann aber auch noch den Stammbaum dieses Architekten
einzutragen, fände ich übertrieben.

Anhaltspunkt ist die Anzahl der Schritte/Mitgliedschafts-"Links", die
man gehen muss, bis man zu einem Objekt mit Geokoordinate kommt. Je mehr
es sind, desto weniger bietet sich eine Ablage in OSM an.

So schlecht finde ich deinen Vorstoß hinsichtlich semantischer
Verknüpfung dennoch nicht, denn so etwas wie eine Unternehmensrelation
wäre ein hervorragender Anknüpfungspunkt für externe Datenbanken. Von
operator-Freitext-Tags würde ich das nicht behaupten.

Tobias

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

Re: [Talk-de] Tagginghilfe innerstädtische Fußwege

wenn es _auf dem_ Gehweg ist, dann natürlich footway oder ähnliches.

Gruß Martin

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

Re: [Talk-de] Tagginghilfe innerstädtische Fußwege

Am 9. Juni 2011 20:29 schrieb Markus Straub :
> Hi,
>
> wie taggt ihr folgendes:
>
> Gässchen in einer Innenstadt (Altstadt) die keine offiziellen
> Fußgängerzonen, Wohnstraßen etc sind. Hier in Wien gibt es einige
> asphaltierte Gassen, ca 2m breit, die nicht von Fahrzeugen befahren werden
> können weil es keine Gehsteigabsenkung gibt und die Fläche außerdem von
> Gastgärten belegt ist.
>
> highway=pedestrian?
> highway=footway?
>
> Das selbe Frage stellt sich generell für größere Flächen die innerstädtisch
> klar dem Fußgänger gewidmet aber nicht als Fußgängerzone gekennzeichnet sind
> - quasi großflächige Aufweitung des Gehsteigs.


m.E. highway=service, service=alley, evtl. noch mit width. Mit dem
Motorrad könnte ich doch da durchfahren, wenn ich Dich richtig
verstehe?

Gruß Martin

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

[Talk-de] postgresql (osmosis schema) liste von nodes -> Polygon?

Hallo zusammen,

vielleicht kann ja jemand von euch ein wenig helfen.

Ich versuche einen SQL Befehl zu basteln, der Mittelpunkt einer
Fläche ausgibt (ST_PointOnSurface).

Dazu muss man wohl zuerst aus Punkten eine Fläche machen und dann mit
hilfe von ST_PointOnSurface den Mittelpunkt der Fläche zu ermitteln.


osmdb=>  select nodes from ways where id=99382824;
  nodes   
--
 {1149487195,1149487106,1149487674,1149487557,1149487195}
(1 Zeile)

Da fängt jetzt mein Problem schon an. "nodes" ist ein bigint[]

Wie mache ich jetzt ein select für alle diese nodes in der Liste?

Also folgendes hätte ich gerne:

* liste der nodes aus Tabelle ways
* geometrien aller dieser nodes aus Tabelle nodes
* Polygon aus disen Geometrien (ST_)
* ST_PointOnSurface(Polygon)

Gruss

Sven

-- 
"Dynamische IP-Nummern sind Security-Homöopathie."
(Kristian Köhntopp)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Problematik der Ortsnamenzusätze

2011-06-09 Diskussionsfäden Martin Trautmann

On 11-06-09 10:37, Walter Nordmann wrote:

> Was ist der Kern-Name von Wakendorf?
>> Wakendorf I
>> Wakendorf II
>> Wakendorf bei Henstedt-Ulzburg -> Wakendorf II
>> Wakendorf bei Wismar, Mecklenburg
>> Wakendorf, Holstein
> natürlich Wakendorf. alles andere sind Zusätze -> postfix

Danke dafür, dass du so bereitwillig in diese Falle getappt bist.

Wakendorf I und Wakendorf II würde ich doch sehr deutlich so von
einander unterscheiden wollen. Beides sind Gemeinden im Kreis Segeberg,
die nicht mal nebeneinander liegen.

Wikipedia-Zitat:

+++
Die Bezeichnung Wakendorf II wurde in preußischer Zeit eingeführt, um
den Ort von einer 20 Kilometer entfernten weiteren Gemeinde namens
Wakendorf zu unterscheiden. Hierbei handelte es sich um eine rein
kommunalpolitische Entscheidung ohne historisch gewachsene Bedeutung.

Eine Bürgerinitiative versuchte durch eine Unterschriftenaktion, die
Umbenennung des Ortes in Wakendorf an der Alster zu erreichen. Dieses
Begehren wurde von der Kommunalaufsicht des Kreises Segeberg als nicht
zulässig gewertet, da die formellen Richtlinien wie z. B. das
Geburtsdatum der Unterschreiber in den Unterschriftslisten nicht
aufgeführt wurde.

Die Gemeindevertretung hat am 22. Juni 2006 die Beibehaltung des Namens
Wakendorf II beschlossen.
+++
Wakendorf bei Henstedt-Ulzburg kenne ich als andere Bezeichnung dafür,
"Wakendorf an der Alster" ist für mich neu und wurde soeben meinen Daten
hinzugefügt.

> Was ist der Kernname bei St. Irgendwas?
> 
> "St. Irgendwas" - so wie der DR. Bestandteil des Namens ist

Mir fehlt offensichtlich die klare Schiene, wie du den Kernnamen
auswählst. Dass du mit dem Dr. auf dem Holzweg bist wurde ja schon geklärt.

St, (oder Sankt), Bad, Markt, Flecken sind auch feste
Namensbestandsteile, die mit ähnlicher Berechtigung genannt oder
weggelassen werden können.

Beachte übrigens im gleichen Kreis "Krems II" - das ist eine Gemeinde,
während Krems I nur ein kaum bedeutender Ortsteil von Leezen ist.

Schönen Gruß
Martin

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

Re: [Talk-de] Resorts => landuse=residental ??

2011-06-09 Diskussionsfäden Wolfgang

Hallo,
Am Donnerstag 09 Juni 2011 18:53:21 schrieb M∡rtin Koppenhoefer:
> Am 9. Juni 2011 18:43 schrieb Wolfgang :
> >> > Das sind nun Hotelanlagen (Resorts) im großen Stil - würdet Ihr diese
> >> > mit Landuse=residental erfassen ??
> >> 
> >> So lange ich nichts bessere finde, ja.
> > 
> > comercial würde auch passen. Hotels sind im weitesten Sinne eher mit
> > Bürogebäuden verwandt, häufig auch optisch.
> 
> Jein, m.E. passt residential besser. Typologisch sind Hotels klar eine
> eigene Klasse (wobei es natürlich auch da verschiedene
> Standarduntertypen gibt, z.B. Atriumhotel). Der Unterschied von Büros
> und Hotels ist schon sehr groß, angefangen von der Anzahl der Bäder /
> Steigstränge, über Geschosshöhen und Achsmaße, Nebenräume bis zu den
> Service-Angeboten. Hotels sind nachts meist belegt, Büros leer, etc.
> 

Ich habe ja nicht behauptet, Hotels und Büros sind fast das gleiche ;-)

Deine aufgezählten Unterschiede gelten gegenüber Wohnraum noch viel mehr: 
Anzahl der Bäder/Steigstränge, Geschosshöhen, Achsmaße, Nebenräume, Service-
Angebote. Nicht alle Büros sind nachts leer, und es soll auch den Büroschlaf 
geben ;-)

Gleichheit mit Wohnungen: Es wird übernachtet und gegessen.

Gleichheit mit Büros: Es wird kommerziell betrieben, die Leute (Personal) 
kommen zur Arbeit, es wird am Tage und nachts gearbeitet, es gibt Büroräume 
für die Verwaltung und für die Gäste, die dort häufig auch arbeiten, ...

Es gibt natürlich auch das Urlaubshotel, in dem die Gäste am Pool liegen. Aber 
auch hier wird gearbeitet, Geld umgesetzt, Dienst geleistet etc.

Gruß, Wolfgang

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

[Talk-de] Tagginghilfe innerstädtische Fußwege

2011-06-09 Diskussionsfäden Markus Straub


Hi,

wie taggt ihr folgendes:

Gässchen in einer Innenstadt (Altstadt) die keine offiziellen 
Fußgängerzonen, Wohnstraßen etc sind. Hier in Wien gibt es einige 
asphaltierte Gassen, ca 2m breit, die nicht von Fahrzeugen befahren 
werden können weil es keine Gehsteigabsenkung gibt und die Fläche 
außerdem von Gastgärten belegt ist.


highway=pedestrian?
highway=footway?

Das selbe Frage stellt sich generell für größere Flächen die 
innerstädtisch klar dem Fußgänger gewidmet aber nicht als Fußgängerzone 
gekennzeichnet sind - quasi großflächige Aufweitung des Gehsteigs.


Nachdem das Flächen sind bietet sich highway=pedestrian an finde ich.
Eure Meinungen?

LG,
Markus / evod

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

Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)

2011-06-09 Diskussionsfäden Claudius


Am 09.06.2011 20:06, M∡rtin Koppenhoefer:

M.E. könnte OSM extrem dazugewinnen, wenn wir die "Struktur der Welt"
auch im "nichträumlichen Bereich" in unserer Datenbank hätten.
(...)


Wir sollten uns da nicht übernehmen und versuchen einen auf 
Universaldatenbank. Das Wissen steckt schon in den Daten selbst und kann 
mittels Techniken des semantischen Webs ermittelt werden.
Einen vielversprechenden Ansatz liefert da schon das zwar schon 
fortgeschrittene, aber immer noch rudimentäre Mapping von 
http://linkedgeodata.org - Wenn man dort das Interlinking etwa zu 
DBPedia verbessert ist das schon kurz vor dem von dir beschriebenen Ziel.


Claudius


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

[Talk-de] Relationen für Betreiber (und evtl. für alles?)

Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon
länger durch den Kopf geht.

Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier
(URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post
zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch
wenn man das vollständig in den Griff bekommen könnte durch
eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen
Namen und keine weiteren Informationen.

M.E. könnte OSM extrem dazugewinnen, wenn wir die "Struktur der Welt"
auch im "nichträumlichen Bereich" in unserer Datenbank hätten. Wir
könnten z.B. die Tätigkeitsfelder von Organisationen oder
Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen:
welche Kraftwerke werden von EON betrieben, wo ist die
Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch
dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen
könnten vollständig abgebildet werden (Parlament, Regierungssitz,
Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur
"ungefähr", d.h. man verlässt sich auf gleiche Namen oder muss externe
Recherchen anstellen und unsere mit anderen Daten verknüpfen.

Im Prinzip ist solches Mappen derzeit schon möglich, da man auch
Relationen ohne Members machen kann, die z.B. eine Firma
repräsentieren könnten. Das Problem ist vor allem, wie man diese
Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges
db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn
es Interesse daran gibt, wäre das vielleicht lösbar.

Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte:
Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr
drin stehen)
http://www.openstreetmap.org/browse/relation/1618278

und eine Metro-Linie, die von der vg. Firma betrieben wird (die
Relation taucht hier mit der Rolle operator auf):
http://www.openstreetmap.org/browse/relation/207926

Kommentare?

Gruß Martin

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

Re: [Talk-de] Mapnik - Rendern von Dünen

2011-06-09 Diskussionsfäden Falk Zscheile

Am 9. Juni 2011 12:37 schrieb Chris66 :
> Am 09.06.2011 12:08, schrieb Jan Tappenbeck:
>
>> kann mir einer sagen wo ich Renderwünsche hinterlegen kann ?
>
> Auf 
>
> Komponente Mapnik wählen.
>
>> Hätte gerne das die Dünen auch dargestellt werden - natural=dune.
>
> Problem: Es gibt Sand- und GrasDünen, soll der Renderer Dünen
> also rötlich oder grünlich darstellen ?
>
> Sanddünen könnte man als natural=sand taggen, das wird auch
> schon gerendert.
>

Man kann sich am Schema für natural=wetland orientieren. Welche Art
von Bodenbedeckung im Wasser steht gibt man dann mit wetland=value an.

Für unseren Fall wäre das dann natural=dune, dune=value in diesem Fall
wohl dune=sand (beachte aber die weiteren Ausführungen weiter unten).
Das ist auch rudimentät so dokumentiert.[1]

Von Grasdünen habe ich allerdings noch nie etwas gehört. Oder meinst
du Stranddünen, wo so ein bisschen Strandhafer zwischen dem Sand
steht? Ansonsten bestehen Dünen meines Wissens nach immer aus Sand.
Erst wenn sie nicht mehr wandern bildet sich auf ihnen eine
geschlossene Pflanzendecke. Dann sind es zwar noch Dünen im
geologischen (?) Sinne, aber keine mehr im biologischen. Da müste man
sich also auch noch drüber einigen. Da wir aber das mappen, was wir
sehen, sollten wir bei ersterem -- den sichtbaren unbewachsenen --
bleiben. Einer bewachsenen Düne sieht nur ein Profi an, ob es mal eine
Düne war oder ob dort ein urzeitlicher Riese die Stiefel geleert hat.
Außerdem gibt es dann wieder Überschneidungen mit
natural=heath,grass,wood etc. Wir brauchen also eher Begriffe für
Stranddüne, Wüstendüne, etc.

Gruß, Falk

[1] http://wiki.openstreetmap.org/wiki/Tag:natural%3Ddune

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

Re: [Talk-de] Resorts => landuse=residental ??

Am 9. Juni 2011 18:43 schrieb Wolfgang :
>> > Das sind nun Hotelanlagen (Resorts) im großen Stil - würdet Ihr diese
>> > mit Landuse=residental erfassen ??
>>
>> So lange ich nichts bessere finde, ja.
>
> comercial würde auch passen. Hotels sind im weitesten Sinne eher mit
> Bürogebäuden verwandt, häufig auch optisch.


Jein, m.E. passt residential besser. Typologisch sind Hotels klar eine
eigene Klasse (wobei es natürlich auch da verschiedene
Standarduntertypen gibt, z.B. Atriumhotel). Der Unterschied von Büros
und Hotels ist schon sehr groß, angefangen von der Anzahl der Bäder /
Steigstränge, über Geschosshöhen und Achsmaße, Nebenräume bis zu den
Service-Angeboten. Hotels sind nachts meist belegt, Büros leer, etc.

Gruß Martin

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

Re: [Talk-de] Resorts => landuse=residental ??

2011-06-09 Diskussionsfäden Wolfgang

Hallo,
Am Donnerstag 09 Juni 2011 17:07:49 schrieb Garry:
> Am 09.06.2011 08:52, schrieb Jan Tappenbeck:
> >  hi !
> > 
> > ich weiß zuhause gibt es immer noch genug zu tun - aber gestern war
> > ich kurz in Ägypten und habe eine riesige Windkraftanlage erfaßt und
> > dabei sind mir Bebauungen am Suez aufgefallen (tolle Bilder im
> > übrigen) und da habe ich just4fun 2 erfaßt.
> > 
> > Das sind nun Hotelanlagen (Resorts) im großen Stil - würdet Ihr diese
> > mit Landuse=residental erfassen ??
> 
> So lange ich nichts bessere finde, ja.
> 

comercial würde auch passen. Hotels sind im weitesten Sinne eher mit 
Bürogebäuden verwandt, häufig auch optisch.

Gruß, Wolfgang

___
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 9. Juni 2011 17:23 schrieb Garry :
> Das Paradoxe ist dass er durch Androhung von Account-Sperren die
> Durchsetzung/Unterdrückung von Tags
> unterstützt...


jetzt bin ich doch neugierig geworden, um welche Tags gehts da?

Gruß Martin

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

Re: [Talk-de] Deichflächen

2011-06-09 Diskussionsfäden Heiko Jacobs


Am 06.06.2011 14:17, schrieb Claudius:

Am 06.06.2011 12:28, Jan Tappenbeck:

In der Regel sind die Führungslinien - oftmals Wege - als embankment=yes
getaggt. Leider wird hierfür ja wohl derzeit keine Signatur gerendert.


man_made=dyke


t@h-Karte rules, da werden embankment und dyke auch unterschiedlich
gerendert.


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

Re: [Talk-de] Omosis incrementeller update

On Thu, Jun 09, 2011 at 03:25:44PM +, Sven Geggus wrote:
> Alexander Matheisen  wrote:
> 
> > Der Fokus liegt jetzt eher auf dem Datenbankschema.
> 
> Saarland in eine lokale Postgis auf dem heimischen importieren und anschaun.
> 
> PostGIS Snapshot Schema mit hstore, nicht das alte "Simple Schema".
> 
> Da werden wir vermutlich auch nen Index brauchen.
> 
> Ich denke an tägliche updates und nachlaufende cronjobs, die Spezialtabellen
> erstellen. Da kann man dann auch mit Spatial Operations Schwerpunkte von
> Polygonen z.B. bei Gebäuden erzeugen.

Darf ich an dieser Stelle etwas Werbung für Osgende [1] machen? Das ist
das Framework hinter der Wanderkarte, das genau diesen Prozess etwas
vereinfachen soll. Die Idee dabei ist, dass man einen Planeten in einer
osmosis Datenbank hat und dann ein paar Zeilen Python-Code schreibt,
der beschreibt, wie OSM-Tags umgewandelt werden sollen. Und osgende
kümmert sich dann um Import und Update.

Das Hauptproblem ist, dass das ganze noch ziemlich in den Kinderschuhen
steckt. Es fehlt noch Dokumentation, mehr Tabellentemplates und vor allem 
ein kleines Tutorial.

Aber wenn du es dir ohnehin für eine Fahrradkarte angucken willst,
macht es Sinn, die gleiche Technik für die Brauereikarte zu verwenden. 

Gruss

Sarah

[1] http://dev.lonvia.de/trac/wiki/OsgendeFramework

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

Re: [Talk-de] Omosis incrementeller update

Alexander Matheisen  wrote:

> Der Fokus liegt jetzt eher auf dem Datenbankschema.

Saarland in eine lokale Postgis auf dem heimischen importieren und anschaun.

PostGIS Snapshot Schema mit hstore, nicht das alte "Simple Schema".

Da werden wir vermutlich auch nen Index brauchen.

Ich denke an tägliche updates und nachlaufende cronjobs, die Spezialtabellen
erstellen. Da kann man dann auch mit Spatial Operations Schwerpunkte von
Polygonen z.B. bei Gebäuden erzeugen.

Solange es keine generische Lösung für das POI Problem gibt halte ich das
erst mal für nen gangbaren Weg.

Gruss

Sven

-- 
"Those who do not understand Unix are condemned to reinvent it, poorly"
(Henry Spencer)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

___
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-06-09 Diskussionsfäden Garry


Am 09.06.2011 12:59, schrieb M∡rtin Koppenhoefer:

Am 8. Juni 2011 18:19 schrieb Garry:

Am 07.06.2011 16:42, schrieb Frederik Ramm:

anderen aufzudiktieren, wie sie ihre Arbeit machen sollen.

Das klingt aus Deinem Mund jetzt sehr paradox...


naja, wenn ich naturgemäß auch mit dem Rest Deiner Mail weitgehend
übereinstimme, hier widerspreche ich doch gern: Frederik ist
prinzipiell ziemlich liberal und laisser-faire-mäßig unterwegs, da ist
aus meiner Sicht nichts Paradoxes an seiner Aussage.
Das Paradoxe ist dass er durch Androhung von Account-Sperren die 
Durchsetzung/Unterdrückung von Tags

unterstützt...

Garry

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

Re: [Talk-de] Resorts => landuse=residental ??

2011-06-09 Diskussionsfäden Garry


Am 09.06.2011 08:52, schrieb Jan Tappenbeck:



 hi !

ich weiß zuhause gibt es immer noch genug zu tun - aber gestern war 
ich kurz in Ägypten und habe eine riesige Windkraftanlage erfaßt und 
dabei sind mir Bebauungen am Suez aufgefallen (tolle Bilder im 
übrigen) und da habe ich just4fun 2 erfaßt.


Das sind nun Hotelanlagen (Resorts) im großen Stil - würdet Ihr diese 
mit Landuse=residental erfassen ??

So lange ich nichts bessere finde, ja.

Garry

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

Re: [Talk-de] Omosis incrementeller update (was: OpenLinkMap outdated?)

On Thu, Jun 09, 2011 at 03:38:12PM +0200, Alexander Matheisen wrote:
> Am Donnerstag, den 09.06.2011, 08:12 + schrieb Sven Geggus:
> > Ah OK, d.h. ich kann einfach statt sowas:
> > 
> > osmosis --rri workingDirectory=$WDIR --simc --wxc update.osc
> > osm2pgsql ... update.osc
> > 
> > etwas in dieser Art:
> > osmosis --rri workingDirectory=$WDIR --simc --wpc ...
> > 
> > verwenden?
> 
> Genau.
> 
> Der Fokus liegt jetzt eher auf dem Datenbankschema. Viel Doku zu diesem
> Punkt hab ich noch nicht gefunden, aber ich suche noch fleißig...

Die beste Dokumentation dazu ist das Skript, dass die Tabellen erstellt:

http://trac.openstreetmap.org/browser/applications/utils/osmosis/trunk/package/script/pgsnapshot_schema_0.6.sql

Je nachdem, was du vor hast, lohnt es sich, noch Indices ueber die
tags-Spalten zu erstellen.

Ausserdem kann ich die optionale Action-Table-Erweiterungen empfehlen:

http://trac.openstreetmap.org/browser/applications/utils/osmosis/trunk/package/script/pgsnapshot_schema_0.6_action.sql

Damit erhältst du nach jedem Update eine Liste der geänderten Objekte.
Allerdings existiert die Tabelle nur temporär. Man kann nur innerhalb
der osmosisUpdate-Funktion sehen. Wenn man sie ausserhalb auch braucht,
einfach in eine andere Tabelle kopieren.

Es gibt auch noch Skripte für das automatische Erstellen von Linestrings
und BBoxen für Wege, aber das macht das Update langsam. In den
meisten Fällen dürfte es deshalb besser sein, dass danach manuell
zu machen für die Objekte, wo man es wirklich braucht.

Sarah

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

[Talk-de] grafische Auswertung der Ort für die es Wiki-Seiten gibt




 Hi !

gibt es irgendwo eine grafische Auswertung der Ort für die es 
Wiki-Seiten gibt ??


Gruß Jan .-)


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

Re: [Talk-de] Omosis incrementeller update (was: OpenLinkMap outdated?)

Am Donnerstag, den 09.06.2011, 08:12 + schrieb Sven Geggus:
> Sarah Hoffmann  wrote:
> 
> > Sicher. Task --write-pgsql-change 
> > 
> > http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--write-pgsql-change_.28--wpc.29
> 
> Ah OK, d.h. ich kann einfach statt sowas:
> 
> osmosis --rri workingDirectory=$WDIR --simc --wxc update.osc
> osm2pgsql ... update.osc
> 
> etwas in dieser Art:
> osmosis --rri workingDirectory=$WDIR --simc --wpc ...
> 
> verwenden?

Genau.

Der Fokus liegt jetzt eher auf dem Datenbankschema. Viel Doku zu diesem
Punkt hab ich noch nicht gefunden, aber ich suche noch fleißig...


Alex


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

Re: [Talk-de] Problematik der Ortsnamenzusätze

2011-06-09 Diskussionsfäden Dominik Wegerle


On 09.06.2011 13:28, Igor Podolskiy wrote:

Bodo,

On 08.06.2011 22:47, Bodo Meissner wrote:


Das erschwert das Zusammensetzen etwas, weil man einmal ein 
Leerzeichen einfügen muß und einmal nicht. Vermutlich lassen sich 
(sprachabhängig) Regeln definieren, bei welchen Zeichen das 
Leerzeichen entfällt.


Ich will übrigens gar nichts aufbrechen :) Im Gegenteil, ich bin mit 
"name=Limburg an der Lahn" vollkommen zufrieden.


Die Software-Entwickler wahrscheinlich nicht.
Die Trennung wäre nicht nur für den Renderer nützlich, sondern auch 
für einen Suchalgorithmus. So könnte der Anwender wählen, ob er das 
Suchmuster nur im "Kern" oder auch im Präfix oder Suffix suchen möchte.


vielleicht habe ich mich etwas missverständlich ausgedrückt, sorry. Du 
hast vollkommen recht, sowohl das Zusammensetzen als auch das Trennen 
ist schwierig bis nahezu unmöglich (im Fall der Übersetzung - 
maschinelle Übersetzung hat selbst für normalen Fließtext nur eher 
bescheidene Ergebnisse und wir reden hier von Eigennamen, die 
grundsätzlich aus einem Wörterbuch kommen).


Mein Vorschlag ist, das Zusammensetzen und das Trennen durch Software 
vollständig zu eliminieren, indem man immer in jedem einzelnen Tag 
einen vollständigen zusammenhängenden Namen einträgt.


Also zum Beispiel (gerade bei alt_name kann man wieder drüber 
streiten, allerdings käme das gerade einem Suchalgorithmus zu gute):


name=Frankfurt am Main
short_name=Frankfurt
official_name=Frankfurt am Main, Stadt # Kommt aus dem 
Gemeindeverzeichnis

alt_name=Frankfurt (Main);Frankfurt/Main;Frankfurt/M.
name:ru=Франкфурт-на-Майне
short_name:ru=Франкфурт

name=Hamburg
alt_name=Hansestadt Hamburg
official_name=Freie und Hansestadt Hamburg

Das hat für I18N den Vorteil, dass immer vollständige Namen übersetzt 
werden. Der Renderer kann sich dann den kürzesten Aussuchen, wenn er 
keinen Platz hat. Und ein Suchalgorithmus kannst du auch darüber 
laufen lassen, ohne irgendwie Preprocessing mit Präfixen und Suffixen 
zu betreiben.


Das ist alles doch schon in Key:name im Wiki erklärt und geregelt. 
name:prefix und name:suffix übrigens auch [1], ist eigentlich ganz 
überraschend, wofür das eigentlich mal gedacht war.


Da du auch "die Softwareentwickler" angesprochen hast: Ich bin auch 
einer ;) Also, hier die ungefilterte Entwicklersicht:


Als Entwickler will ich letzten Endes die Daten mindestens der ersten 
Normalform. Und wir diskutieren hier nichts anderes als was die 
korrekte erste Normalform für Ortsnamen ist (eigentlich für 
administrative Einheiten, aber sei's drum). Die einen sagen: wir 
normalisieren in drei Teile, Präfix, Kern, Suffix für irgendeine vage 
Definition von Kern, Präfix und Suffix. Ich sage: der Name ist schon 
eine Einheit in sich und braucht nicht weiter zerteilt zu werden. Wenn 
es mehrere Namen gibt, ist doch schön, sollen sie als mehrere Namen 
entsprechend ihrer Bedeutung bitte auch eingetragen werden. Aber ein 
Name ist zusammenhängend, in sich abgeschlossen und sollte im 
Idealfall von keiner Software irgendwie weiter transformiert werden, 
weil das spätestens bei mehreren Sprachen nicht mehr entscheidbar ist. 
Manchmal braucht man andere Trennzeichen. Manchmal ändert sich auch 
die Reihenfolge der Wörter bei der Übersetzung. Manchmal gibt es einen 
gänzlich anderen Namen. Manchmal gibt es zusätzlichen Präpositionen. 
Manchmal wird ein Teil des Namens dekliniert.


Mein Problem mit der Präfix-Kern-Suffix-Aufteilung ist auch, dass sie 
mehr oder weniger willkürlich und präsentationsorientiert ist. Alle 
Tags in Key:name haben auch eine eigene in der echten Welt relevante 
Bedeutung. Deswegen präferiere ich diese Variante.


Ich gehe davon aus, daß Du das in den meisten Fällen nach Gefühl 
richtig eintragen kannst und nur in Ausnahmefällen die Regeln lesen 
müßtest.
Danke für das Vertrauen :) Aber zwischen nur selten und gar nicht 
liegt auch ein Unterschied.


Bisher stelle ich mir die Entscheidung recht einfach vor: Welche 
Bezeichnung würde ich auf einer Karte erwarten, wenn der Platz knapp 
ist? Das wäre der Name. Alles davor ist Präfix, alles danach Suffix. 
Oder hast Du ein Beispiel für einen schwierigen Fall?
Martin Strutmann hat in seinen Beiträgen in diesem Thread 
dankenswerterweise eine ganze Reihe von Beispielen gebracht. Die 
Wakendorf-Serie ist zum Beispiel sehr interessant.


Außerdem ist der von dir geschilderte Gedankengang 
Renderer-orientiert. Kann man machen, aber das vernachlässigt wieder 
alle anderen Anwendungen. Außerdem: Print oder Web? Welcher Stil? 
Welcher Kartenzweck?


Mein Gedankengang ist: "Frankfurt am Main" ist ein zusammenhängender 
vollständiger Name, der kommt in einen Tag rein, Ende. "Frankfurt" ist 
eine gebräuchliche alternative Verkürzung, also kommt es in "alt_name" 
oder "short_name", Ende. Viel einfacher, als über Renderer, Stile und 
überhaupt Anwendungen nachzudenken.


Wohlgemerkt: ich habe nichts gegen alternative vollständige Namen 
(alt_name, old_name, name:alternative, name:official,

Re: [Talk-de] Problematik der Ortsnamenzusätze

Hi,

On 09.06.2011 10:06, Walter Nordmann wrote:

moin moin,

hier noch was extremes, auf das mich suncobalt vom Forum hingewiesen hat:

https://secure.wikimedia.org/wikipedia/de/wiki/Weil_der_Stadt#Name_der_Stadt

Ist übrigens so in osm drin:
http://www.openstreetmap.org/?minlon=8.86072372437&minlat=48.7401029968&maxlon=8.88072467804&maxlat=48.7601068115
Ja, Weil der Stadt ist echt ein großartiger Name, ist mir auch
aufgefallen, als ich nach Stuttgart umgezogen bin :) Das schönste ist,
es gibt noch einen Stadtbezirk hier in Stuttgart, welches Weilimdorf
heißt und ursprünglich mal "Weil im Dorf" hieß. Es besteht also die
Möglichkeit, dass Weil der Stadt in 200 Jahren "Weilderstadt" heißt ;)
Aber aktuell heißt die Stadt offiziell "Weil der Stadt, Stadt": einfach
zu [1] gehen und 08115050 in das untere Feld eingeben, das kommt der
Name in seiner vollen Schönheit ;) Das in OSM ist also vollkommen
korrekt. "Weil" oder "Weil, die Stadt" sagt hier auch keiner.

p.s. was machen wir denn mit dem profanen "Gemeinde Kleinkleckersdorf" ,"Amt
Bullerbü"? oder "xyz, Stadt"
Das sind doch nur wirlich keine erhaltenswürdige Bestandteile des Namens,
oder?
Ja, einerseits bin ich auch der Meinung, insbesondere bei Städten und
Gemeinden, da die Information ja in place=town/village/commune/city
steht. ", Stadt" ist dennoch ein beliebter Zusatz bei Städten im
Gemeindeverzeichnis, würde also in official_name=* gehören...

Andererseits ist bei "Universitätsstadt Garching bei München"
"Universitätsstadt" schon erhaltenswert, oder? Ich würde es dann als
alt_name machen oder so, aber ich will meine anderen Beiträge hier nicht
wiederholen.

Bei Ämtern bin ich mir etwas unsicher: das sind ja manchmal
Gemeindeverbände (admin_level=7) und da unterscheidet sich die
Bezeichnung manchmal schon und das kann momentan auch nicht anderweitig
modelliert werden. Kann ich aber jetzt nicht wirklich beurteilen, wie
oft das vorkommt, da ich mit admin_level=7 noch nicht Ich würde es (a)
immer erst einmal ins Gemeindeverzeichnis schauen und sonst irgendwie
recherchieren und (b) official_name, alt_name usw. verwenden und es
nicht löschen, wenn diese Bezeichnung nicht gänzlich falsch scheint. Ist
aber natürlich kein Dogma, nur meine 2 Cent dazu.

Viele Grüße
Igor

[1]
http://www.destatis.de/jetspeed/portal/cms/Sites/destatis/Internet/DE/Navigation/Statistiken/Regionales/GVOnlineAbfrage.psml

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

Re: [Talk-de] Problematik der Ortsnamenzusätze


On 09.06.2011 14:24, Walter Nordmann wrote:


Igor Podolskiy wrote:


P.S. Selbst in einer zusammenhängenden Diskussion über ein paar Tage
unter einer guten Handvoll Leuten reden wir schon von :suffix und
:postfix quer durcheinander. Und wie soll das dann in den Daten
konsistent bleiben? :)


sorry, in der Hitze des Gefechts komm ich auch schon mal durcheinander:
prefix und suffix natürlich - postfix hat sich da heimlich reingeschlichen.

Ist doch gar kein Problem :)

Grüße
Igor

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

Re: [Talk-de] Problematik der Ortsnamenzusätze


Igor Podolskiy wrote:
> 
> P.S. Selbst in einer zusammenhängenden Diskussion über ein paar Tage 
> unter einer guten Handvoll Leuten reden wir schon von :suffix und 
> :postfix quer durcheinander. Und wie soll das dann in den Daten 
> konsistent bleiben? :)
> 
sorry, in der Hitze des Gefechts komm ich auch schon mal durcheinander:
prefix und suffix natürlich - postfix hat sich da heimlich reingeschlichen.


-
Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst 
sehen, dass da kein Wald ist.
--
View this message in context: 
http://gis.638310.n2.nabble.com/Problematik-der-Ortsnamenzusatze-tp6445081p6457589.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] Problematik der Ortsnamenzusätze


Walter,


Was ist der Kern-Name von Wakendorf?

Wakendorf I
Wakendorf II
Wakendorf bei Henstedt-Ulzburg ->  Wakendorf II
Wakendorf bei Wismar, Mecklenburg
Wakendorf, Holstein

natürlich Wakendorf. alles andere sind Zusätze ->  postfix
uff, langsam, langsam :D Das sagt sich einfach so, aber es lohnt sich, 
genauer hinzuschauen. Bei Namen ist nichts "natürlich", allein schon 
weil sie künstlich vergeben werden...


Wakendorf I und Wakendorf II sind entweder Ortsteile der Gemeinde 
Wakendorf oder zwei etwas einfallslos diskriminierte Gemeinden (laut 
aktuellem Gemeindeverzeichnis des StBA ist bei Wakendorf das 
letztgenannte der Fall, aber das mit den nummerierten Ortsteilen kenne 
ich auch aus ein paar mecklenburgischen Gemeinden).


Wenn du da alles verpräfixt und versuffixt (oder verpostfixt?), zeigt 
dir die Software, die sich nur auf "Kernnamen" spezialisiert, 3x oder 2x 
"Wakendorf" an und du kannst gar nichts mehr unterscheiden. Ist das in 
deinem Sinne? Ich glaube nicht. "Wakendorf I" und "Wakendorf II" sind 
zusammenhängende, auch amtlich eingetragene, Namen. Sonst kannst du sie 
gar nicht unterscheiden, wenn du die Position einnimmst, dass Präfixe 
und Suffixe "unwichtig" sind, und diese Sichtweise wird aufkommen, 
machen wir uns nichts vor. Gerade im Szenario "Renderer und wenig Platz 
auf der Karte".


Im Fall von "Wakendorf bei Wismar, Mecklenburg" gehört m.E. auch nach 
aktuellen Richtlinien das ", Mecklenburg" ganz weg, ist ganz 
unmissverständlich dort hingeschrieben. Das "bei Wismar" ist so eine 
Sache: je nach Gebrauch und dem was im Gemeindeverzeichnis steht, ist 
das entweder name=* oder alt_name=* oder official_name=*. Aber auch das 
gehört zusammen und nicht zerteilt, nicht von der Software und auch 
nicht von Menschen, z.B.:


name=Wakendorf
official_name=Wakendorf bei Wismar


Was ist der Kernname bei St. Irgendwas?

"St. Irgendwas" - so wie der DR. Bestandteil des Namens ist
In der Sache hast du natürlich Recht, auch das gehört selbstverständlich 
zusammen.


Beim Doktor muss ich dir leider widersprechen, Doktor ist ein 
akademischer Grad, kein Namenszusatz und unterliegt nicht dem 
Namensrecht. Dass man es in den Ausweis eintragen lassen kann, ändert 
nichts daran. Ist ein verbreiteter Irrtum. Sorry.


Viele Grüße
Igor

P.S. Selbst in einer zusammenhängenden Diskussion über ein paar Tage 
unter einer guten Handvoll Leuten reden wir schon von :suffix und 
:postfix quer durcheinander. Und wie soll das dann in den Daten 
konsistent bleiben? :)


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

Re: [Talk-de] Mapnik - Rendern von Dünen

Am 9. Juni 2011 13:50 schrieb Jan Tappenbeck :
> Am 09.06.2011 12:37, schrieb Chris66:
>>
>> Am 09.06.2011 12:08, schrieb Jan Tappenbeck:
>>
>>> kann mir einer sagen wo ich Renderwünsche hinterlegen kann ?
>>
>> Auf
>
>
> HI !
>
> Mit welchem PWD logge ich denn da mich ein ?
>
> Es gibt ja zwei !


ich hoffe, die löschen nicht gleich alle Deine Daten und sperren den
Account, wenn Du es einmal falsch eingegeben hast...

Gruß Martin

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

Re: [Talk-de] Problematik der Ortsnamenzusätze

Am 8. Juni 2011 09:13 schrieb Walter Nordmann :
> Aus  diesem Grunde sollten Tags wie "name=Gemeinde Kleinkleckersdorf"
> einfach in name=Kleinkleckerdorf umgewandelt werden. Das gleiche für
> "Dortmund, Stadt".


Grundsätzlich gibt es ja immer die Möglichkeit, beides festzuhalten,
z.B. mit dem tag "official_name":
http://wiki.openstreetmap.org/wiki/Key:official_name

Ich bin mir nicht so sicher, ob der "richtige" Name z.B. des
Landkreises Zollernalbkreis "Zollernalb" ist. M.E. ist evtl. auch
"Landkreis Tübingen" der Name des Landkreises Tübingen, nicht
"Tübingen", dito für den "Regierungsbezirk Tübingen".

Anwendungen, die mit sowas Probleme haben, sind m.E. zu optimieren.

Gruß Martin

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

Re: [Talk-de] Mapnik - Rendern von Dünen


Am 09.06.2011 12:37, schrieb Chris66:

Am 09.06.2011 12:08, schrieb Jan Tappenbeck:


kann mir einer sagen wo ich Renderwünsche hinterlegen kann ?


Auf



HI !

Mit welchem PWD logge ich denn da mich ein ?

Es gibt ja zwei !

gruß Jan :-)


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

Re: [Talk-de] Nuklearkarte


Am 09.06.2011 08:42, schrieb Markus:

Gerhard hat eine schöne Nuklear-Karte für DE gemacht (als PDF)
http://wiki.openstreetmap.org/wiki/File:MapgenGermanyNuclear.pdf

Eine dynamische Version gibt es hier:
http://opendata.zeit.de/atomreaktoren/#/de/

Vielleicht hat ja jemand Lust, das weltweit zu kombinieren?



hi !

ich habe auch eine Karte die Windmühlen etc. beinhaltet - aber zur Zeit 
nicht upgedatet werden kann und etwas Pflege bedarf.


Aber gab es da nicht schon eine die auf dem Toolserver läuft ??

Gruß Jan :-)


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

Re: [Talk-de] Problematik der Ortsnamenzusätze


Bodo,

On 08.06.2011 22:47, Bodo Meissner wrote:


Das erschwert das Zusammensetzen etwas, weil man einmal ein Leerzeichen 
einfügen muß und einmal nicht. Vermutlich lassen sich (sprachabhängig) Regeln 
definieren, bei welchen Zeichen das Leerzeichen entfällt.


Ich will übrigens gar nichts aufbrechen :) Im Gegenteil, ich bin mit "name=Limburg 
an der Lahn" vollkommen zufrieden.


Die Software-Entwickler wahrscheinlich nicht.
Die Trennung wäre nicht nur für den Renderer nützlich, sondern auch für einen 
Suchalgorithmus. So könnte der Anwender wählen, ob er das Suchmuster nur im 
"Kern" oder auch im Präfix oder Suffix suchen möchte.


vielleicht habe ich mich etwas missverständlich ausgedrückt, sorry. Du 
hast vollkommen recht, sowohl das Zusammensetzen als auch das Trennen 
ist schwierig bis nahezu unmöglich (im Fall der Übersetzung - 
maschinelle Übersetzung hat selbst für normalen Fließtext nur eher 
bescheidene Ergebnisse und wir reden hier von Eigennamen, die 
grundsätzlich aus einem Wörterbuch kommen).


Mein Vorschlag ist, das Zusammensetzen und das Trennen durch Software 
vollständig zu eliminieren, indem man immer in jedem einzelnen Tag einen 
vollständigen zusammenhängenden Namen einträgt.


Also zum Beispiel (gerade bei alt_name kann man wieder drüber streiten, 
allerdings käme das gerade einem Suchalgorithmus zu gute):


name=Frankfurt am Main
short_name=Frankfurt
official_name=Frankfurt am Main, Stadt # Kommt aus dem Gemeindeverzeichnis
alt_name=Frankfurt (Main);Frankfurt/Main;Frankfurt/M.
name:ru=Франкфурт-на-Майне
short_name:ru=Франкфурт

name=Hamburg
alt_name=Hansestadt Hamburg
official_name=Freie und Hansestadt Hamburg

Das hat für I18N den Vorteil, dass immer vollständige Namen übersetzt 
werden. Der Renderer kann sich dann den kürzesten Aussuchen, wenn er 
keinen Platz hat. Und ein Suchalgorithmus kannst du auch darüber laufen 
lassen, ohne irgendwie Preprocessing mit Präfixen und Suffixen zu betreiben.


Das ist alles doch schon in Key:name im Wiki erklärt und geregelt. 
name:prefix und name:suffix übrigens auch [1], ist eigentlich ganz 
überraschend, wofür das eigentlich mal gedacht war.


Da du auch "die Softwareentwickler" angesprochen hast: Ich bin auch 
einer ;) Also, hier die ungefilterte Entwicklersicht:


Als Entwickler will ich letzten Endes die Daten mindestens der ersten 
Normalform. Und wir diskutieren hier nichts anderes als was die korrekte 
erste Normalform für Ortsnamen ist (eigentlich für administrative 
Einheiten, aber sei's drum). Die einen sagen: wir normalisieren in drei 
Teile, Präfix, Kern, Suffix für irgendeine vage Definition von Kern, 
Präfix und Suffix. Ich sage: der Name ist schon eine Einheit in sich und 
braucht nicht weiter zerteilt zu werden. Wenn es mehrere Namen gibt, ist 
doch schön, sollen sie als mehrere Namen entsprechend ihrer Bedeutung 
bitte auch eingetragen werden. Aber ein Name ist zusammenhängend, in 
sich abgeschlossen und sollte im Idealfall von keiner Software irgendwie 
weiter transformiert werden, weil das spätestens bei mehreren Sprachen 
nicht mehr entscheidbar ist. Manchmal braucht man andere Trennzeichen. 
Manchmal ändert sich auch die Reihenfolge der Wörter bei der 
Übersetzung. Manchmal gibt es einen gänzlich anderen Namen. Manchmal 
gibt es zusätzlichen Präpositionen. Manchmal wird ein Teil des Namens 
dekliniert.


Mein Problem mit der Präfix-Kern-Suffix-Aufteilung ist auch, dass sie 
mehr oder weniger willkürlich und präsentationsorientiert ist. Alle Tags 
in Key:name haben auch eine eigene in der echten Welt relevante 
Bedeutung. Deswegen präferiere ich diese Variante.



Ich gehe davon aus, daß Du das in den meisten Fällen nach Gefühl richtig 
eintragen kannst und nur in Ausnahmefällen die Regeln lesen müßtest.
Danke für das Vertrauen :) Aber zwischen nur selten und gar nicht liegt 
auch ein Unterschied.



Bisher stelle ich mir die Entscheidung recht einfach vor: Welche Bezeichnung 
würde ich auf einer Karte erwarten, wenn der Platz knapp ist? Das wäre der 
Name. Alles davor ist Präfix, alles danach Suffix. Oder hast Du ein Beispiel 
für einen schwierigen Fall?
Martin Strutmann hat in seinen Beiträgen in diesem Thread 
dankenswerterweise eine ganze Reihe von Beispielen gebracht. Die 
Wakendorf-Serie ist zum Beispiel sehr interessant.


Außerdem ist der von dir geschilderte Gedankengang Renderer-orientiert. 
Kann man machen, aber das vernachlässigt wieder alle anderen 
Anwendungen. Außerdem: Print oder Web? Welcher Stil? Welcher Kartenzweck?


Mein Gedankengang ist: "Frankfurt am Main" ist ein zusammenhängender 
vollständiger Name, der kommt in einen Tag rein, Ende. "Frankfurt" ist 
eine gebräuchliche alternative Verkürzung, also kommt es in "alt_name" 
oder "short_name", Ende. Viel einfacher, als über Renderer, Stile und 
überhaupt Anwendungen nachzudenken.



Wohlgemerkt: ich habe nichts gegen alternative vollständige Namen (alt_name, 
old_name, name:alternative, name:official, name:$YOUR_QUALIFIER, ...), nur 
Bedenken gegen

Re: [Talk-de] Nuklearkarte

2011-06-09 Diskussionsfäden Beni Buess

Hi

> Gerhard hat eine schöne Nuklear-Karte für DE gemacht (als PDF)
> http://wiki.openstreetmap.org/wiki/File:MapgenGermanyNuclear.pdf
> 
> Eine dynamische Version gibt es hier:
> http://opendata.zeit.de/atomreaktoren/#/de/
> 
> Vielleicht hat ja jemand Lust, das weltweit zu kombinieren?
> 
> Ergänzt um:
> - Forschungsreaktoren
> - Lehrreaktoren
> - Zwischenlager
> - potentielle Endlager
> - aktive Uranminen
> - geplanten Stillegungs-Terminen
> - erfolgten Stillegungs-Terminen
> - erlittenen GAUs, gestuft nach Schweregrad
> - ...
> 
> In z=2..8 mit hervorgehobenen Landesgrenzen, Ländernamen,
> und Namen der grossen Orte
> 
> Bei der aktuellen weltweiten Ausstiegsdebatte wäre das eine hilfreiche
> Visualisierung.

Eine Karte, welch die AKW darstellt wurde mal in den wöchentlichen OSM News 
verlinkt. (1)

(1) http://www.leretourdelautruche.com/map/nuke/

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

Re: [Talk-de] Mapnik - Rendern von Dünen

Am 9. Juni 2011 12:37 schrieb Chris66 :
> Am 09.06.2011 12:08, schrieb Jan Tappenbeck:
>> kann mir einer sagen wo ich Renderwünsche hinterlegen kann ?
> Auf 
> Komponente Mapnik wählen.
>> Hätte gerne das die Dünen auch dargestellt werden - natural=dune.
>
> Problem: Es gibt Sand- und GrasDünen, soll der Renderer Dünen
> also rötlich oder grünlich darstellen ?
>
> Sanddünen könnte man als natural=sand taggen, das wird auch
> schon gerendert.


natural=sand halte ich für Unsinn, wenn man irgendwann mal eine Logik
im Tagging von Grundelementen erzielen will.

M.E. könnte man Bodennutzung und Bedeckung so aufteilen:
landuse= Nutzung
landcover= Bodenbedeckung (manche würden da lieber surface verwenden,
was aber auch Probleme hat).
natural würde ich für geografische Features benutzen, also so was wie
Dünen, Strände, Gipfel, Höhlen, Klippen, Buchten, Pässe, ...

Im Großen und Ganzen ist das so auch in den Tags umgesetzt, ein paar
Ausreisser gibt es aber, und sand ist einer davon. Ich würde das
natural für die Düne verwenden, und den Sand in landcover (oder
notfalls/zusätzlich(?) in surface, wenn die komplette Oberfläche des
getaggten Polygons Sand ist).

Gruß Martin

___
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 8. Juni 2011 18:19 schrieb Garry :
> Am 07.06.2011 16:42, schrieb Frederik Ramm:
>> anderen aufzudiktieren, wie sie ihre Arbeit machen sollen.
> Das klingt aus Deinem Mund jetzt sehr paradox...


naja, wenn ich naturgemäß auch mit dem Rest Deiner Mail weitgehend
übereinstimme, hier widerspreche ich doch gern: Frederik ist
prinzipiell ziemlich liberal und laisser-faire-mäßig unterwegs, da ist
aus meiner Sicht nichts Paradoxes an seiner Aussage.

Gruß Martin

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

Re: [Talk-de] Mapnik - Rendern von Dünen

2011-06-09 Diskussionsfäden Chris66

Am 09.06.2011 12:08, schrieb Jan Tappenbeck:

> kann mir einer sagen wo ich Renderwünsche hinterlegen kann ?

Auf 

Komponente Mapnik wählen.

> Hätte gerne das die Dünen auch dargestellt werden - natural=dune.

Problem: Es gibt Sand- und GrasDünen, soll der Renderer Dünen
also rötlich oder grünlich darstellen ?

Sanddünen könnte man als natural=sand taggen, das wird auch
schon gerendert.

Chris


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

[Talk-de] Mapnik - Rendern von Dünen




 Hi !

kann mir einer sagen wo ich Renderwünsche hinterlegen kann ?

Hätte gerne das die Dünen auch dargestellt werden - natural=dune.

Gruß Jan :-)


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

[Talk-de] feuerwehr karte

2011-06-09 Diskussionsfäden Gary68

hi,

thema wurde hier und im forum diskutiert, daher:

first shot mit mapgen:

http://www.gary68.de/temp/huje.pdf

for what it's worth

gerhard


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

Re: [Talk-de] Problematik der Ortsnamenzusätze


Martin Trautmann wrote:
> 
> Und obendrein verwende ich für die Suche auch die mir unterkommenden
> Schreibvarianten wie Frankfurt a.M., Frankfurt a. Main (keine Ahnung,
> wer sich solchen Blödsinn ausdenkt, einen Buchstaben durch einen Punkt
> einzusparen), Frankfurt a.Main, Frankfurt / Main, Frankfurt/Main usw.

in OSM steht Frankfurt/Main als einziger Eintrag mit "name=Frankfurt am
Main, Stadt" drin. -noch-


Was ist der Kern-Name von Wakendorf?
> Wakendorf I
> Wakendorf II
> Wakendorf bei Henstedt-Ulzburg -> Wakendorf II
> Wakendorf bei Wismar, Mecklenburg
> Wakendorf, Holstein
natürlich Wakendorf. alles andere sind Zusätze -> postfix


Was ist der Kernname bei St. Irgendwas?

"St. Irgendwas" - so wie der DR. Bestandteil des Namens ist


Denkbar ist z.B. auch eine Suche, wo die Postleitzahl zur Eingrenzung
> mit herangezogen wird. Iterative, mehr oder weniger automatische Ansätze
> zur Eingrenzung der Ergebnisse sind wünschenswert.
Das ist bei uns Job von Nominatim und daher nicht "Thread-Relevant"

Gruss
Walter

-
Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst 
sehen, dass da kein Wald ist.
--
View this message in context: 
http://gis.638310.n2.nabble.com/Problematik-der-Ortsnamenzusatze-tp6445081p6457028.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] Nuklearkarte

2011-06-09 Diskussionsfäden Martin Czarkowski


Am 09.06.2011 08:42, schrieb Markus:


Eine dynamische Version gibt es hier:
http://opendata.zeit.de/atomreaktoren/#/de/

was hat denn diese Karte mit OSM zu tun?

Martin

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

Re: [Talk-de] Nuklearkarte

Markus  wrote:

> Eine dynamische Version gibt es hier:
> http://opendata.zeit.de/atomreaktoren/#/de/

Die auf Google Maps basiert...

Sven

-- 
Why are there so many Unix-haters-handbooks and not even one
Microsoft-Windows-haters handbook?
Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf!
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

[Talk-de] Lübecker Stammtisch - abweichender Termin




 Moin!

aus aktuellem Anlass wollte ich nur daraufhinweisen das HEUTE abweichend 
der Lübecker Stammtisch [1] stattfindet !!!


Gruß Jan :-)

[1] http://wiki.openstreetmap.org/wiki/L%C3%BCbecker_Mappertreffen


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

[Talk-de] Omosis incrementeller update (was: OpenLinkMap outdated?)

Sarah Hoffmann  wrote:

> Sicher. Task --write-pgsql-change 
> 
> http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--write-pgsql-change_.28--wpc.29

Ah OK, d.h. ich kann einfach statt sowas:

osmosis --rri workingDirectory=$WDIR --simc --wxc update.osc
osm2pgsql ... update.osc

etwas in dieser Art:
osmosis --rri workingDirectory=$WDIR --simc --wpc ...

verwenden?

Gruss

Sven

-- 
AMZN US won't let me buy MP3s b/c I have UK credit cards. Amazon UK won't   
let me buy MP3s b/c I'm in the US. P2P doesn't care. Go copyright!
(Cory Doctorow)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-de] Problematik der Ortsnamenzusätze