Re: [Talk-de] Energiequelle bei Elektrotankstellen

[Ulf Lamping]

Am 12.10.2010 23:55, schrieb C. Brause:

Am 12.10.2010 23:44, schrieb Ulf Lamping:

Wieso wird hier lang und breit drüber diskutiert, daß Elektrotankstellen
keine Tankstellen sind (z.B. ist ein Akku kein Tank!), und dann kommt
wenig später die nächste Träne und kommt mit der gleichen Geschichte
wieder an? Das macht echt keinen Spaß.

Man tankt keinen Strom und Strom ist kein fuel (=Brennstoff). Auch wenn
euch das die Werbefuzzies was anderes weismachen wollen.

Solange es sich nicht an einer landläufig als Tankstelle bezeichneten
Einrichtung zusätzlich angebrachten Steckdose handelt, sowas bitte als
amenity=charging_station taggen!!!

Gruß, ULFL



1)  Danke für die Träne 
2) Danke für das amenity charging_station. Das hatte ich gesucht. ICH
tagge kein fuel:electricity.

LG
Christian

P.S. dein Post wirkte etwas aggressiv auf mich...


Ja, so war auch in etwa mein Gemütszustand wie ich dein Posting gelesen 
hatte ;-)


Sorry, ich hab gerade nochmal:

http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel

gelesen und dort stand dann tatsächlich fuel:electricity=yes :-( Jetzt 
vermute ich mal, daß du "die Idee" daher hattest.


Ich hab mal den Versuch unternommen, den aktuellen Stand der 
Diskussionen dort kurz zu notieren, auf das wir die gleichen 
Diskussionen nicht in 2 Monaten wieder führen ...


Gruß, ULFL

P.S: Ich meine mich zu erinnern, das wir fuel:electricity=yes bei 
"normalen Tankstellen" beibehalten wollten (eher selten, bis nie?), wäre 
aber auch nicht beleidigt hier immer amenity=charging_station zu 
verwenden und fuel:electricity ganz zu streichen.


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

Re: [Talk-de] Relation - die nette Toilette

[Jochen Topf]

On Tue, Oct 12, 2010 at 11:23:02PM +0200, Jan Tappenbeck wrote:
>  In Lübeck gibt es einen Zusammenschluss "die nette Toilette" um Touris  
> das Erleichtern zu ermöglichen.
>
> Wen mehr interessiert:  
> http://www.entsorgung.luebeck.de/aktuelles/pressemeldungen/2010/neu_219.html

Warum nicht ein Tag "nette_toilette=yes" oder sowas? Wir haben ja auch nicht
alle Einbahnstraßen in einer Relation, oder?

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


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

Re: [Talk-de] Relation als Sammelobjekt

[Jochen Topf]

On Wed, Oct 13, 2010 at 12:01:07AM +0200, Frederik Ramm wrote:
> C. Brause wrote:
>> Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine  
>> Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne 
>> kurze Antwort geben (glaub ich aber nicht).
>
> Mapper tun das oft, weil sie dadurch - vorausgesetzt, sie kennen die  
> Relations-ID - sehr leicht saemtliche dieser Objekte herunterladen  
> koennen (mit der /relation/xxx/full-Abfrage). Das ist komfortabler, als  
> sich die betr. Objekte anhand der Tags herauszusuchen.
>
> Allerdings sind Relationen dafuer eigentlich nicht gedacht  
> (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories 
> ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all  
> ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen  
> (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features).

Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu
entfernen, ein nützlicheres zu schaffen, das dann alle verwenden?

Offensichtlich gibt es hier ja eine Anforderung der User. Sie wollen alle
Features eines bestimmten Typs leicht finden. Das kann man durch den Trick
mit der Relation machen. Oder man benutzt die XAPI. Zumindest solange es nur
um einen einzigen Tag geht, macht die XAPI das ja ganz brav. Und bei der
XAPI kann ich auch eine Bbox angeben, was man bei dem Weg über die Relation
nicht kann.

Schwieriger wird es bei geographisch geschachtelten Relationen: Alle
Stolpersteine in Bayern oder sowas. Hier ist in der Relation nicht nur der
Tag kodiert, sondern eine geographische Information. Und zwar eine, die
derzeit sehr schwierig aus der Datenbank zu bekommen ist. Die Alternative
ist derzeit, eine eigene Datenbank aufzusetzen mit einem Mirror der Daten,
die Grenze von Bayern zusammenzusetzen und dann auszuschneiden. Klar, das
das kaum jemand hinbekommt.

Vielleicht gibt es noch andere Gründe, warum manche Leute, die Relationen
gerne haben. Falls ja, dann sagt Bescheid.

Die Gegner der Relationen für diese Zwecke sagen: Informationen in Tags sind
leichter zu Verarbeiten und Pflegen als Relationen zu machen, die gerade für
Anfänger schwer zu verstehen sind. Wird so eine Relation ausversehen gelöscht,
ist das Geschrei groß. Und die Verarbeitung mag zwar einfacher sein für den
Gelgenheitsuser, der nur die Relation als XML runterlädt und damit was macht,
aber datenbanktechnisch ist es ein Riesenaufwand, weil wir Abhängigkeiten
zwischen verschiedenen Objekten haben. Wird z.B. ein Node gelöscht, der in
der Relation ist, muss man diese auch immer mit anfassen.

Dahinter steckt aber noch ein ganz anderes Problem, verschiedene Ansichten, die
so meist nicht formuliert werden, weil beide Seiten sie für selbstverständlich
halten und garnicht sehen, dass ihre Weltbilder hier auseinanderlaufen:

Der "durchschnittliche Mapper", der nur gelegentlich mit den Daten ein bischen
was basteln will (z.B. eine Karte aller Stolpersteine in Bayern), erwartet, dass
ihm die OSM-Datenbank diese Daten auf einfache Weise rausrückt. Der "Hacker"
oder Informatiker hingegen sieht, dass es sehr aufwändig ist für eine zentrale
Datenbank die Informationen in all den Formen zur Verfügung zu stellen, die die
verschiedenen Leute brauchen. Er geht also davon aus, dass die zentrale
Datenbank nur zum Editieren da ist und alle anderen Formen der Nutzung aus
einer Kopie der Datenbank heraus erfolgen, die für die jeweilige spezielle
Nutzung optimiert ist. Aber natürlich können die wenigsten eine solche
spezielle Datenbank aufsetzen. Der Mapper wird also die pragmatische Lösung
wählen (also z.B. Relationen anlegen). Und bei OSM ist die pragmatische
Lösung *immer* die richtige Lösung, so ist unser Projekt groß geworden, das
gehört eigentlich zu unserer Kultur. Wir wollen keine theoretisch gute Lösung,
die aber nicht umsetzbar ist, wir wollen die pragmatische Lösung.

Dummerweise ist aber natürlich die Welt komplex und die pragmatischen Lösungen
können und werden zu neuen Problemen führen. Aber wenn man die pragmatische
Lösung für falsch hält, dann gibt es in unserem Projekt eigentlich nur eine
Möglichkeit dem zu entgegnen, nämlich in dem man eine *noch pragmatischere*
Lösung schafft, nicht in dem man die pragmatische Lösung verbietet oder
verhindert.

Wir haben hier also eine Schwierigkeit. Beide Seiten haben vernünftige
Argumente, die aus ihrer Sicht Sinn machen. Wir sollten überlegen, was man
machen kann, um hier einen Schritt weiter zu kommen, statt immer wieder
alte Argumente zu wiederholen.

Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und
weiter auszubauen.

Ein anderer wäre es, etwas zu schaffen, was ich mal "virtuelle Relationen"
nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach
innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber
vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen
helfen kann.

Ich bin sicher, wenn wir genauer darüber nach

[Talk-de] libosm

[Hanno Hecker]

Hi zusammen,

ich hab aus dem pbf2osm [1] eine kleine Schnittstelle gebaut, die auch 
pbf-Support hat. Die momentane Version gibt's hier [2]. 

Was fehlt ist noch jede Menge Doku :) ... der XML-Teil hinkt etwas
hinter dem pbf-Teil hinterher, ist daher mit Vorsicht zu geniessen...

Ein paar kleine Beispiele, was man damit machen kann sind auch dabei:
 - osm2gpx - .osm-XML in's GPX-Format konvertieren 
 - osmpbf2osm  - quasi pbf2osm 
 - osm-extract - extrahieren von relations, ways, nodes oder
 tags(/value), user und/oder bounding box
 - waydupes- wie der name schon sagt... Im Gegensatz zu Garys
 waydupes.pl [3] findet dieses hier auch überlappende
 Teilstücke

Feedback, Bugs, ... an mich 

Hanno

[1] 
[2]

[3] 

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

Re: [Talk-de] Relation als Sammelobjekt

[Christian H. Bruhn]

am Dienstag, 12. Oktober 2010 um 23:58 schrieb C. Brause:

> Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine
> Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne
> kurze Antwort geben (glaub ich aber nicht).

Also bei den Stolpersteinen schwanke ich auch ein wenig. Man kann
immerhin so argumentieren, daß diese Steine ein Gesamtkunstwerk eines
Künstlers darstellen.

Christian


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

Re: [Talk-de] Relation - die nette Toilette

[Peter Wendorff]

 On 13.10.2010 06:57, Jan Tappenbeck wrote:

... und wie sieht die Alternative für die "nette Toilettte" ???

Gruß Jan :-)

http://wiki.openstreetmap.org/wiki/Key:network

nur kurze idee...

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

Re: [Talk-de] rolli-parking mit nummer

[Walter Nordmann]

danke jan,
bin ich echt nicht drauf gekommen. ich kenne "rollatoren" - diese kleinen
wägelchen, die man vor sich herschiebt - aber auf rollstuhl bin ich nicht
gekommen.
gruss
walter

-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/rolli-parking-mit-nummer-tp5628601p5629923.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] Energiequelle bei Elektrotankstellen

[Ulf Lamping]

Am 12.10.2010 23:55, schrieb C. Brause:

2) Danke für das amenity charging_station. Das hatte ich gesucht. ICH
tagge kein fuel:electricity.


amenity=charging_station habe ich gerade in die Presets und Mappaint vom 
JOSM eingebaut.


Ab morgen in latest zu finden unter: Vorlagen/Transport/Auto/Charging 
Station (bzw. wohl Stromtankstelle, wenn es übersetzt worden ist) - bzw. 
zu sehen auf JOSMs "Karte".


Gruß, ULFL

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

Re: [Talk-de] Relation als Sammelobjekt

[Frederik Ramm]

Hallo,

Jochen Topf wrote:

Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu
entfernen, ein nützlicheres zu schaffen, das dann alle verwenden?


Die beste Idee waere gewesen, dieses Feature gar nicht erst anzubieten, 
denn dann haette sich laengst irgendjemand etwas gescheites ausgedacht; 
solange es die Moeglichkeit des kompletten Relationsdownloads gibt, 
werden die Leute weiterhin den Weg des geringsten Widerstandes gehen.


Daher sehe ich die Entfernung dieses Features als einen sinnvollen 
ersten Schritt zur vernuenftigen Loesung des Problems; eine vernuenftige 
Loesung des Problems wird nicht stattfinden, solange es das Feature gibt.



Der Mapper wird also die pragmatische Lösung
wählen (also z.B. Relationen anlegen). Und bei OSM ist die pragmatische
Lösung *immer* die richtige Lösung, so ist unser Projekt groß geworden, das
gehört eigentlich zu unserer Kultur. 


Meiner Ansicht nach war es ein Versehen, dass dieser .../full-Download 
jemals angeboten wurde. Es gibt sehr viele Dinge, die man als 
"pragmatisch" bezeichnen koennte (z.B.: "anstatt einen Bot alle 
highway=residentail in highway=residential umsetzen zu lassen, machen 
wir doch einfach ein UPDATE-Statement auf der Datenbank"), und die "der 
Mapper" unter Garantie sofort einsetzen wuerde, wenn man es anboete; wir 
bieten es aber nicht an.


Dem Pragmatismus sind also immer, auch in OSM, Grenzen gesetzt, und ich 
denke, dass diese Grenze hier korrigiert werden muss.



Dummerweise ist aber natürlich die Welt komplex und die pragmatischen Lösungen
können und werden zu neuen Problemen führen. Aber wenn man die pragmatische
Lösung für falsch hält, dann gibt es in unserem Projekt eigentlich nur eine
Möglichkeit dem zu entgegnen, nämlich in dem man eine *noch pragmatischere*
Lösung schafft


Das ist in dieser Allgemeinheit falsch (s.o. mit den Bots).


Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und
weiter auszubauen.


Oder OSM halt einfach naeher zu den Usern bringen - ein kleines 
Klickibuti-Interface auf Osmosis oben drauf, "welche Daten haetten Sie 
denn heute gern...", dann soll sich das Ding von irgendwo her Bayern 
oder Luebeck laden und raussuchen, was der User will...


Bye
Frederik


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

Re: [Talk-de] Relation - die nette Toilette

[aighes]

Peter Wendorff wrote:
> 
> http://wiki.openstreetmap.org/wiki/Key:network
> 
> nur kurze idee...
> 

Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein.
nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut
ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die
Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich
ist. Letzteres sollte also auf jeden Fall mit eingetragen werden.

aighes
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5629980.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] Relation als Sammelobjekt

[Stefan Dettenhofer (StefanDausR)]

 Hallo,

man sollte m.E. unterscheiden zwischen geordneten Relationen, bei denen 
es auf die Reihenfolge der Elemente und ggf. auf die Rolle der Elemente 
ankommt und den sog. "Sammelrelationen" (oder "virtuelle Relationen" 
oder "Gruppen"), die diese Eigenschaften nicht benötigen!



Am 13.10.2010 09:22, schrieb Jochen Topf:


Ein anderer wäre es, etwas zu schaffen, was ich mal "virtuelle Relationen"
nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach
innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber
vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen
helfen kann.



Also ich könnte mir vorstellen, z.B. nur mit einem hierarchisch 
gegliederten Tag ("group") zu arbeiten, also so wie es mal für "is_in" 
vorgeschlagen wurde:


Also z.B. so:
group=Stolpersteine
oder mit geografischer Komponente
group=Stolpersteine/DE/Bayern/München

Will man alle haben, so kann man sie mit "Stolpersteine*" selektieren, 
braucht man nur die in Bayern, dann eben "Stolpersteine/DE/Bayern*"



Alternativ könnte man natürlich auch so arbeiten
group=Stolpersteine
group:country=DE
group:district=Bayern
group:city=München

finde ich aber nicht so gut, denn dann ist die Gefahr größer, dass Tags 
fehlen.



Eine dritte Variante wäre diese:
group:Stolpersteine=yes
oder mit Lage
group:Stolpersteine=DE/Bayern/München


Das wäre eigentlich mein Favorit, denn so ist klar, dass ein Element 
auch mehreren "Gruppen" angehören könnte.




Der Vorteil der "Gruppen" (="virtuelle Relationen") liegt auf der Hand: 
Man muss nur das Tag pflegen und nicht noch eine Relation


Gruß,
Stefan


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

Re: [Talk-de] Relation als Sammelobjekt

[René Falk]

Am 13.10.2010 00:01, schrieb Frederik Ramm:

> Allerdings sind Relationen dafuer eigentlich nicht gedacht
> (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories
> ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all
> ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen
> (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features).

Wird lustig wenn hier mal die Überland-Buslinien erfasst werden. Da sind
dann Riesendownloads des Gebiets vorprogrammiert, wenn man die Relation
nicht mehr einzeln runterladen kann. Will man das?

Grüße

René

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

Re: [Talk-de] Relation als Sammelobjekt

[aighes]

Hallo Frederik,

meiner Meinung nach ist das der falsche Weg. Bei Routen ist dies bspw. die
einzige sinvolle Möglichkeit an die Daten zu kommen. Es ist großer
Schwachsinn, dass ich mir für einen einfachen gpx-Track eines Radfernweges
Deutschland als Extract herunterladen muss.

Besser wäre, wie du schon sagst, ein kleines Klickibunti-Programm als GUI
für den API-Aufruf.

aighes


-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630023.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] Relation - die nette Toilette

[Jochen Topf]

On Wed, Oct 13, 2010 at 01:17:39AM -0700, aighes wrote:
> Peter Wendorff wrote:
> > 
> > http://wiki.openstreetmap.org/wiki/Key:network
> > 
> > nur kurze idee...
> > 
> 
> Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein.
> nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut
> ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die
> Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich
> ist. Letzteres sollte also auf jeden Fall mit eingetragen werden.

Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man sie
vielleicht überhaupt nicht bei OSM eintragen. :-)

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


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

Re: [Talk-de] Relation als Sammelobjekt

[Jochen Topf]

On Wed, Oct 13, 2010 at 10:19:32AM +0200, Stefan Dettenhofer (StefanDausR) 
wrote:
> Am 13.10.2010 09:22, schrieb Jochen Topf:
> 
> >Ein anderer wäre es, etwas zu schaffen, was ich mal "virtuelle Relationen"
> >nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach
> >innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber
> >vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen
> >helfen kann.
> >
> 
> Also ich könnte mir vorstellen, z.B. nur mit einem hierarchisch
> gegliederten Tag ("group") zu arbeiten, also so wie es mal für
> "is_in" vorgeschlagen wurde:
> 
> Also z.B. so:
> group=Stolpersteine
> oder mit geografischer Komponente
> group=Stolpersteine/DE/Bayern/München
> 
> Will man alle haben, so kann man sie mit "Stolpersteine*"
> selektieren, braucht man nur die in Bayern, dann eben
> "Stolpersteine/DE/Bayern*"
> 
> 
> Alternativ könnte man natürlich auch so arbeiten
> group=Stolpersteine
> group:country=DE
> group:district=Bayern
> group:city=München
> 
> finde ich aber nicht so gut, denn dann ist die Gefahr größer, dass
> Tags fehlen.
> 
> 
> Eine dritte Variante wäre diese:
> group:Stolpersteine=yes
> oder mit Lage
> group:Stolpersteine=DE/Bayern/München
> 
> 
> Das wäre eigentlich mein Favorit, denn so ist klar, dass ein Element
> auch mehreren "Gruppen" angehören könnte.
> 
> 
> 
> Der Vorteil der "Gruppen" (="virtuelle Relationen") liegt auf der
> Hand: Man muss nur das Tag pflegen und nicht noch eine Relation

Was genau bringen diese "Gruppen" jetzt gegenüber normalen Tags? Das ist
doch jetzt nichts anderes, ob man 
  group:Stolpersteine=DE/Bayern/München
tagged oder
  stolpersteine=yes
  is_in=DE, Bayer, München
oder?

Im Gegenteil, hier werden zwei Konzepte vermischt: Nämlich Geographie
und Tags. Bei is_in ist wenigstens die Geographie noch getrennt von dem,
um was es sich hier handelt.

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


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

Re: [Talk-de] Relation als Sammelobjekt

[Peter Wendorff]

 On 13.10.2010 07:03, Jan Tappenbeck wrote:

Am 13.10.2010 01:06, schrieb Walter Nordmann:



C. Brause wrote:

...ich möchte Jans neu gestarteten Thread nicht kapern, daher neu:

sorry, ich habs gerade gemacht (das kapern) :(
bevor ich deinen beitrag gelesen hab.

die darstellung von frederik ist ja wohl klar.
ich hatte selber mal solche "gruppen-relationen" für rettungspunkte, 
da mir

das ganze damals nicht so klar war; aber die sind schon lange draußen.
gruss
walter
das ganze ist eine "relativ" hartnäckige sache.


-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg



hi !

aber wie wollt Ihr dann die Möglichkeit haben alle Stolpersteine für 
einen Bereich oder eines Thema (Stolpersteine in xyz) , was wiederum 
eine Untermenge (alle Stolpersteine) darstellt.


Mann könnte aber Daten über ein Rechteck ermitteln - aber in engen / 
verschachtelten Siedlungsgebieten ist das nur schwer möglich.


Die API läßt keinen Download für eine unregelmäßige Form zu !
Einerseits ist das für API 0.7 vorgeschlagen, auch Polygone als 
Bounding-box zu erlauben,

andererseits ist die API keine direkte Anwendungsschnittstelle.

Anwendungsentwickler sollten sich einfach endlich dran gewöhnen, dass 
ein Postprocessing der API-Antwort der Regelfall ist, und nicht eine 
Ausnahme für exotische Anwendungen.


Gruß
Peter

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

Re: [Talk-de] Relation - die nette Toilette

[René Falk]

Am 13.10.2010 10:35, schrieb Jochen Topf:

>> Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein.
>> nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut
>> ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die
>> Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich
>> ist. Letzteres sollte also auf jeden Fall mit eingetragen werden.
> 
> Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man sie
> vielleicht überhaupt nicht bei OSM eintragen. :-)

Bei nette Toilette geht es darum bereits bestehende Toiletten der
Gastronomie in öffentliche Toiletten zu wandeln. Ein nette_toilette=yes
an ein Restaurant geklebt, wäre daher vielleicht nicht schlecht.

Grüße

René

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

Re: [Talk-de] Fahrrad-Access-Karte überarbeitet

[Steffen Wolf]

Hi Thomas Ineichen,

> Hallo Steffen,

>> Cool. Ein Wunsch: Ich wuerde surface=cobblestone etwas niedriger
>> einordnen.

> Beim Kopfsteinpflaster war ich mir auch unsicher, wo ich es einordnen  
> soll; gerade bei Regen gibt es viele solcher Strassen, die dann  
> unangenehm zu befahren sind. Trotzdem gehört es nicht in die 'weisse'  
> Kategorie.. wahrscheinlich ändere ich das zu schwarz gestrichelt o.ä.

Kommt eigentlich auf das Kopfsteinpflaster an. Wenn es einigermassen
eben ist, dann stimm ich dir zu. Wenn es aber von Stein zu Stein
Hoehenunterschiede von 5cm gibt, dann ist's wenigstens weiss, wenn nicht
schon rot.

>> Schaust du auch nach smoothness? Oder beruecksichtigst du
>> surface=concrete_plates? Oder surface=paving_stones:20 usw.?

> Nein und nein. :)

:-)

> @smoothness
> Ich könnte mir  höchstens vorstellen, dass gewisse surface-Werte die
> schwarzen Linien  zu gestrichelten Linien abwerten (ähnlich wie
> cobblestone) - oder hast  Du eine gute Visualisierungs-Idee?

Grau? Also Mischfarben zwischen den drei gewaehlten Farben, je nach
Auspraegung mal mehr die eine, mal mehr die andere. Macht das aber auch
nicht uebersichtlicher, wenn erstmal 100 Abstufungen eingetragen sind.

> @surface:
> Ich habe mich vorerst auf die 15 häufigsten Werte beschränkt:
> http://toolserver.org/~ti/surface.txt

> BTW: wäre surface=paving_stone, paving_stone:dimension=20x20 nicht  
> besser?

Ein neuer Tag? Vielleicht, ich hab's so von der Wiki-Seite:
 http://wiki.openstreetmap.org/wiki/Key:surface

>> Mit Bezug auf den Semikolon-Thread: Kommst du mit surface=grass;ground
>> und so klar?

> Nein - ich glaube, das ist hier aber auch nicht so einfach.

Wenn du irgendwie XAPI oder Datenbank abfragst mit Select * where
surface=key, dann nicht. Wenn du aber irgendwann den vollstaendigen Weg
sowieso in die Hand nimmst, dann kannst du s/;.*// anwenden und nur den
ersten Eintrag parsen.

>> Hmm, bicycle:hour_on und hour_off fiele mir noch ein, aber das wird wohl
>> etwas zu weit fuehren.

> DAS hingegen wäre schon wieder einfacher - einfach als String  
> dranpappen. Wäre ein Versuch wert, mit Beschriftungen habe ich bisher  
> noch nie gearbeitet..

Beschriftungen wuerde ich vermeiden wollen. Ich haett's als halbes oder
ganzes Verbot gewertet. Wenn du willst: Stricheln mit entsprechender
Laenge der Striche und Luecken ;-)


Eins fiel mir noch auf: Die bicycle=permissive werden nicht dargestellt.
In der Legende steht bicycle=permessive, vielleicht ist der Tippfehler
auch im Programmcode?

stw
-- 
Zwei kleine UNIX Zeilen,
Waren noch geblieben.
Die eine war schon reichlich alt
Und kam von System Sieben.

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

Re: [Talk-de] rolli-parking mit nummer

[Peter Wendorff]

 Hi.
Rolli-Parkplatz ist der eine Punkt - sollte m.E. eingetragen werden 
(amenity=parking; parking=surface; surface=asphalt; (o.ä.) 
capacity:disabled=n)
Rolli-Parkplatz für bestimmte Nummern unterscheidet sich aber IMHO nicht 
von einem "normalen Privatparkplatz", abgesehen davon, dass er breiter ist.


Oder meinst Du eine Konstruktion, die ich nicht kenne?

Gruß
Peter

On 12.10.2010 23:12, Jan Tappenbeck wrote:

 hi !

es gibt Rolli-Parkplätze die für bestimmte Nummern reserviert sind.

Tagt Ihr diese auch und wenn wie ?

Gruß Jan :-)

___
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] Energiequelle bei Elektrotankstellen

[Stefan Dettenhofer (StefanDausR)]

 Am 13.10.2010 10:02, schrieb Ulf Lamping:

Am 12.10.2010 23:55, schrieb C. Brause:

2) Danke für das amenity charging_station. Das hatte ich gesucht. ICH
tagge kein fuel:electricity.


amenity=charging_station habe ich gerade in die Presets und Mappaint 
vom JOSM eingebaut.


Ab morgen in latest zu finden unter: Vorlagen/Transport/Auto/Charging 
Station (bzw. wohl Stromtankstelle, wenn es übersetzt worden ist) - 
bzw. zu sehen auf JOSMs "Karte".





Dann wird sich das wohl hoffentlich bald ändern:

"fuel:electricity=yes" gibt es in diesen Kombinationen
61-mal mit "amenity=fuel"
7-mal mit "amenity=parking"

Die Ladesäule existiert erst
8-mal mit "amenity=charging_station"





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

Re: [Talk-de] Relation als Sammelobjekt

[André Joost]

Am 13.10.10 10:06, schrieb Frederik Ramm:

Hallo,

Jochen Topf wrote:

Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu
entfernen, ein nützlicheres zu schaffen, das dann alle verwenden?


Die beste Idee waere gewesen, dieses Feature gar nicht erst anzubieten,
denn dann haette sich laengst irgendjemand etwas gescheites ausgedacht;
solange es die Moeglichkeit des kompletten Relationsdownloads gibt,
werden die Leute weiterhin den Weg des geringsten Widerstandes gehen.



Dann nenn doch mal funktionierende Alternativen. Xapi lädt keine 
komplette Relation runter, osmosis kann keine komplette Relation 
ausschneiden, openlayers braucht zur grafischen Darstellung einer 
Relation den /full-Download.


Um nur mal die wichtigsten Anwendugen zu nennen.

Gruß,
André Joost


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

Re: [Talk-de] Relation als Sammelobjekt

[Peter Körner]

Am 13.10.2010 09:22, schrieb Jochen Topf:

Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und
weiter auszubauen.
Bzw. mal neu und schön zu implementieren. Wenn es z.B. eine verlässliche 
und stabile Möglichkeit gäbe (dies bitte als API 0.7 Vorschlag 
verstehen), die einzelnen Elemente über ihre Tags anzusehen:



für den Tag historic=stolpersteine

würde bald keiner mehr die Relation nutzen, da dieser Link
 - einfacher zu merken / zu identifizieren
 - immer aktuell
 - unkaputtbar

ist.

Leider ist derzeit der Weg über die XAPI aber so unattraktiv, das ihn 
nur sehr wenige Leute gehen wollen.


Nehmt den Leuten nicht die Möglichkeit (->relation-full-requiest) 
sondern gebt ihnen besser Möglichkeiten, damit sie von den alten 
ablassen. *)


Lg



Ein anderer wäre es, etwas zu schaffen, was ich mal "virtuelle Relationen"
nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach
innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber
vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen
helfen kann.

Ich bin sicher, wenn wir genauer darüber nachdenken, was wir eigentlich machen
bzw. machen wollen, welche Probleme die verschiedenen Leute, versuchen zu
lösen, dann werden wir auch einer Lösung näher kommen.

Jochen




*) Klingt irgendwie wir ein Bibel-Zitat, ists aber nicht ^^

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

Re: [Talk-de] Relation als Sammelobjekt

[Walter Nordmann]

"ganz einfach" - api vergessen und was "richtiges" verwenden.

die api ist 99% tag-bezogen. da muss alles aus tags herausgezogen werden,
was irgendwie geht. 
tags sind dafür da, um zu beschreiben, WAS für ein objekt es ist aber nicht
dafür, WO es ist. 
von einigen ausnahmen abgesehen (is_in, addr:*), die aber nur aus der not
heraus geschaffen wurden.

die wesentlich bessere information sind diese beiden kleinen werte lat und
lon. damit läßt sich das aus osm herauskitzeln, was WIRKLICH
interessant/wichtig ist. 

in dem speziellen fall der stolpersteine benutz man halt die grenzen der
interessanten bereiche (stadt, kreis, ...) soweit sie vorhanden sind.
und wenn jetzt einer ankommt und meint "die sind aber nicht alle drin", dem
kann ich nur raten, dagegen was zu tun.

gruss
walter

so, jetzt hol ich mir nen kaffee und bin dann wieder "lieb" ;)


-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630202.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] Relation als Sammelobjekt

[Markus]

Hallo Peter,


Polygone als Bounding-box erlauben


Das würde vieles erleichtern!
Damit könnten viele geografische Bezüge abbgebildet werden.

Zusätzlich braucht man aber m.E. noch irgendein ein System für normale 
"relationale" / hierarchische Bezüge (Kategorien):

z.B. für alle Stolpersteine, alle netten Toiletten, etc)

Die Idee von Frederik, für solche Abfragen eine besondere DB anzubieten, 
in der mit einer GUI simpel alle denkbaren Kombinationen von Werten und 
Schlüsseln (auch geschachtelt) und kombiniert mit einem Grenz-Polygon 
abgefragt werden können finde ich genial!


Gruss, Markus

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

Re: [Talk-de] Relation - die nette Toilette

[Walter Nordmann]

nen tag halt, da es eine "eigenschaft" eines objektes (hier lokal, pub,
restaurant, ...) ist.
kann jeder verwenden, der nen stadtplan machen will.
musst halt nur dafür sorgen, dass er sich rumspricht.

-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630224.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] Relation - die nette Toilette

[Walter Nordmann]

René Falk wrote:
> 
> Bei nette Toilette geht es darum bereits bestehende Toiletten der
> Gastronomie in öffentliche Toiletten zu wandeln. Ein nette_toilette=yes
> an ein Restaurant geklebt, wäre daher vielleicht nicht schlecht.
wenn ich mich recht entsinne, sind die toiletten in gaststätten prinzipiell
öffentlich - da darf jeder rein, der mal "muß". sonst bekommt der wirt
ärger.
allerdings senkt so ein wirklich netter aufkleber, den es bei uns auch gibt,
doch erheblich die hemmschwelle.


-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630239.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] Relation als Sammelobjekt

[M∡rtin Koppenhoefer]

Am 13. Oktober 2010 11:36 schrieb Markus :
> Zusätzlich braucht man aber m.E. noch irgendein ein System für normale
> "relationale" / hierarchische Bezüge (Kategorien):
> z.B. für alle Stolpersteine, alle netten Toiletten, etc)


das sind keine hierarchischen Bezüge m.E., und das System gibt es von
Anfang an, es heisst: Tag (k/v).

Ich kann allen raten, die sich wie Jan sowieso Tag und Nacht mit OSM
beschäftigen, schaut Euch mal Postgres/Postgis an. Mit der Anleitung
von Richard (oder einer anderen je nach System, gibts alles im Wiki)
installiert man das Teil in ner viertel Stunde, dann noch mal ein
bisschen fürs Einlesen der Daten, und schwuppdiwupp macht man die
tollsten Abfragen, anfangs durch Abändern von Beispielen, und
irgendwann auch "freihand". Wenn man nett fragt schreibt einem
vielleicht auch hier auf der Liste jemand ein Beispielquery (im
ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist
hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen,
nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im
Zweifel auch nicht immer, was da im Hintergrund passiert.

Gruß Martin

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

Re: [Talk-de] Relation - die nette Toilette

[aighes]

Hallo,

Jochen123 wrote:
> 
> Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man
> sie
> vielleicht überhaupt nicht bei OSM eintragen. :-) 

Nicht unbedingt, bzw. es hängt davon ab wie man öffentlich zugänglich
definiert. Es gibt viele Toiletten, die zwar prinzipiell jeder nutzen
könnte, aber bspw. nur Gäste einer Einrichtung legal nutzen dürfen. Bspw.
Tankstellen, wo man sich einen Schlüssel holen muss. Das sollte man schon
eintragen, aber mit einem entsprechenden access-Tag.


Walter Nordmann wrote:
> 
> wenn ich mich recht entsinne, sind die toiletten in gaststätten
> prinzipiell öffentlich - da darf jeder rein, der mal "muß". sonst bekommt
> der wirt ärger.
> allerdings senkt so ein wirklich netter aufkleber, den es bei uns auch
> gibt, doch erheblich die hemmschwelle.
Nein, der "Betreiber" hat weiterhin Hausrecht und kann den Besuch seiner
Einrichtung einschränken. Siehe bspw. Türsteher an Discos. Die Betreiber
müssen nur für ihre Gäste eine Toilette vorhalten, wenn sie eine gewisse
Geschäftsfläche haben.

aighes
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630290.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] Energiequelle bei Elektrotankstellen

[C. Brause]

Am 13.10.2010 01:33, schrieb Michael Kugelmann:

Am 12.10.2010 23:55, schrieb C. Brause:

P.S. dein Post wirkte etwas aggressiv auf mich...

Ach, nur so als Randbemerkung: innerhalb der letzten 4 Wochen gab es
auch überhaupt keine Monster-Diskussion zum Theman...


Monster-Diskussion hin oder her: Ohne halbwegs deutliches Ergebnis ist 
die nicht durch.
Jetzt ist klar, dass Befürworter der alleinstehenden E-Säulen 
amenity=charging_station taggen (sollten). Ich war vorher auch für 
alleinstehend, aber das Tag war mir unklar. Das hat sich dank Ulf aber 
erledigt. Danke





Grüße,
Michael. (auch erfreut, dass manche Themen nach ewiger Diskussion
regelmäßig wieder auftauchen)

PS: man könnte ja mal wieder mit highway = Footway vs. Cycleway vs.
Footway anfagen. D&R ;-]



Könnte man machen, solange noch kein annähernder Konsens gefunden wurde. 
Nervt zwar, aber WENN dann mal was rauskommt, wäre es echt wichtig. Da 
gehts nicht vorwärts. Ebenso Spur-Tagging. Aber lassen wird das lieber. 
Ich hab oben bekommen, was ich wollte ;-)


LG
Christian

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

Re: [Talk-de] Relation als Sammelobjekt

[C. Brause]

Am 13.10.2010 09:28, schrieb Christian H. Bruhn:

am Dienstag, 12. Oktober 2010 um 23:58 schrieb C. Brause:


Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine
Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne
kurze Antwort geben (glaub ich aber nicht).


Also bei den Stolpersteinen schwanke ich auch ein wenig. Man kann
immerhin so argumentieren, daß diese Steine ein Gesamtkunstwerk eines
Künstlers darstellen.

Christian


Bei dem Argument reicht ja etwas wie "Künstler=Stolpersteinmacher" oder 
sowas. Aber inzwischen wurden ja einige größere Probleme angesprochen. 
Da gibt es wohl noch mehr.
Trotzdem möchte ich, wenn ich einen Stolperstein sehe, den einfach 
eintragen und nicht noch die irgendwelche Relationen raussuchen und 
hoffen, dass ich die richtige erwische. Das kann dann zur Not auch der 
machen, der die auswerten möchte. (Zur Not dann lokal mit 
runtergeladenen Daten)


LG
Christian

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

Re: [Talk-de] Relation als Sammelobjekt

[Walter Nordmann]

{quote]Wenn man nett fragt schreibt einem
vielleicht auch hier auf der Liste jemand ein Beispielquery (im
ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist
hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen,
nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im
Zweifel auch nicht immer, was da im Hintergrund passiert.
hi, es hat zwar keiner gefragt, aber so sieht das aus:

gis=> select id 
gis-> from nodes left join relation_members
gis-> on id = member_id
gis-> where member_id is null
gis-> and nodes.tags @> 'memorial:type=>stolperstein'
gis-> ;

und dann kommen 27 sst. raus, die NICHT in irgendeiner relation drin sind.
(meine auch)

für die profis: hstore im neuen osmosis simple schema 0.37, - nicht
osm2psql, aber da gehts ähnlich.

gruss
walter


-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630573.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] Relation als Sammelobjekt

[Peter Wendorff]

 Hi
Ich denke auch, die (Re)implementation der XAPI innerhalb der API wäre 
der richtige Weg.

Die XAPI ist unheimlich praktisch - aber meistens überlastet.
Wie oft brauche ich z.B. alle Bushaltestellen in gegebener BBox? XAPI -> 
einfach möglich; API -> bbox insgesamt laden :(


Die Sammelrelationen bieten da nunmal abhilfe, das macht sie praktisch.

Ein Verbot, Relationen müssten aber unterschiedliche Rollen für ihre 
Elemente haben oder so (was dem vorbeugen könnte), halte ich auch für blöd.
Die Abfrage nach gemeinsamen Tags dagegen ist IMHO eine sehr gute 
Möglichkeit.


Das ist vermutlich ziemlich aufwändig, auch das ist richtig; aber ich 
denke, es lohnt sich, das in Angriff zu nehmen.


Wenn dann noch propagiert wird, wie weniger anfällig Sammlungen über 
diese Abfragen für Schäden und Unvollständigkeit sind, sollte sich das 
auch rumsprechen, dass es sinnvoll verwendbar ist.


Gruß
Peter

On 13.10.2010 11:18, Peter Körner wrote:

Am 13.10.2010 09:22, schrieb Jochen Topf:

Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und
weiter auszubauen.
Bzw. mal neu und schön zu implementieren. Wenn es z.B. eine 
verlässliche und stabile Möglichkeit gäbe (dies bitte als API 0.7 
Vorschlag verstehen), die einzelnen Elemente über ihre Tags anzusehen:



für den Tag historic=stolpersteine

würde bald keiner mehr die Relation nutzen, da dieser Link
 - einfacher zu merken / zu identifizieren
 - immer aktuell
 - unkaputtbar

ist.

Leider ist derzeit der Weg über die XAPI aber so unattraktiv, das ihn 
nur sehr wenige Leute gehen wollen.


Nehmt den Leuten nicht die Möglichkeit (->relation-full-requiest) 
sondern gebt ihnen besser Möglichkeiten, damit sie von den alten 
ablassen. *)


Lg



Ein anderer wäre es, etwas zu schaffen, was ich mal "virtuelle 
Relationen"
nenne. Also etwas, das nach außen so aus sieht wie eine Relation, 
aber nach
innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, 
aber

vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen
helfen kann.

Ich bin sicher, wenn wir genauer darüber nachdenken, was wir 
eigentlich machen
bzw. machen wollen, welche Probleme die verschiedenen Leute, 
versuchen zu

lösen, dann werden wir auch einer Lösung näher kommen.

Jochen




*) Klingt irgendwie wir ein Bibel-Zitat, ists aber nicht ^^

___
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] rolli-parking mit nummer

[M∡rtin Koppenhoefer]

Am 13. Oktober 2010 08:39 schrieb Holger s...@der :
> Hallo Jan,
> ich würde die Behindertenparkplätze nicht erfassen, da es sich hier um
> personenbezogene Parkplätze handelt. Diesen Parkplatz darf nur die Person
> benutzen, die den Parkausweis mit der Nummer besitzt, die auf dem Schild
> steht. Daher ist der Behindertenparkplatz für den Rest der Welt
> uninteressant.


uninteressant fürs Parken schon, es ist AFAIK quasi ein
Privatparkplatz, daher m.E. access=private. Wenn Du die Nummer auch
eintragen willst (ggf. ein Datenschutzproblem?) dann am einfachsten
als description, sonst (wenn man das systematisch vorhat) halt was
erfinden.

Gruß Martin

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

Re: [Talk-de] rolli-parking mit nummer

[Peter Wendorff]

 On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote:

uninteressant fürs Parken schon, es ist AFAIK quasi ein
Privatparkplatz, daher m.E. access=private. Wenn Du die Nummer auch
eintragen willst (ggf. ein Datenschutzproblem?) dann am einfachsten
als description, sonst (wenn man das systematisch vorhat) halt was
erfinden.

Ich würde die Nummer definitiv nicht eintragen.
Die Datenschutz-Problematik sollten wir IMHO nicht unnötig ausreizen.
Wen interessiert diese Nummer (legal und sinnvoll), außer dem Inhaber 
selbst?


Natürlich könnte man tolle Jux-Programme machen, die die Parkplätze 
namentlich anzeigen - aber ist das sinnvoll?

Ist es nützlich?
Ist nicht die Gefahr groß, dass Datenschützer und entsprechende Kritiker 
- zu Recht, wie ich finde - hier ein geöffnetes Fass sehen?


Den Namen eines Arztes an der Arztpraxis, den Namen eines Rechtsanwalts 
- das ist interessant für die Suche nach einem entsprechenden Kontakt.
Der Inhaber eines Parkplatzes interessiert aber nur, wenn ich einen 
Anschlag plane oder meinem Chef böswillig den Platz wegnehmen will.


Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert 
für die OSM, und sollte deshalb tunlichst vermieden werden.


Gruß
Peter

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

Re: [Talk-de] rolli-parking mit nummer

[C. Brause]

Am 13.10.2010 10:57, schrieb Peter Wendorff:

Hi.
Rolli-Parkplatz ist der eine Punkt - sollte m.E. eingetragen werden
(amenity=parking; parking=surface; surface=asphalt; (o.ä.)
capacity:disabled=n)
Rolli-Parkplatz für bestimmte Nummern unterscheidet sich aber IMHO nicht
von einem "normalen Privatparkplatz", abgesehen davon, dass er breiter ist.

Oder meinst Du eine Konstruktion, die ich nicht kenne?

Gruß
Peter

On 12.10.2010 23:12, Jan Tappenbeck wrote:

hi !

es gibt Rolli-Parkplätze die für bestimmte Nummern reserviert sind.

Tagt Ihr diese auch und wenn wie ?

Gruß Jan :-)



Hi,
was ist parking=surface?

LG
Christian

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

Re: [Talk-de] Relation - die nette Toilette

[Walter Nordmann]

na ja, war mir halt nicht so sicher - aber die sache mit der disco (ich
"müsste" mal kurz rein ...)  leuchtet mir ein.

-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630824.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] rolli-parking mit nummer

[Chris66]

Am 13.10.2010 15:00, schrieb C. Brause:

> was ist parking=surface?

Eine nähere Beschreibung des Parkplatztyps
(Parkhaus / Tiefgarage / "Normaler" Parkplatz auf der Erdoberfläche)



Christian


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

Re: [Talk-de] Relation - die nette Toilette

[M∡rtin Koppenhoefer]

Am 13. Oktober 2010 08:36 schrieb Jochen Topf :
> Wir haben ja auch nicht
> alle Einbahnstraßen in einer Relation, oder?


gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine
Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn
das ein Knüller wird, könnte man es auch für die ganze Welt machen)
anzulegen.

Ein paar Infos zu Einbahnstraßen ist hier zusammengetragen:
http://www.gutefrage.net/tag/einbahnstrasse/1

sobald ich fertig bin lade ich das hoch und gebe hier Bescheid, was
die einzelnen Relationen-IDs sind.

Gruß Martin

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

Re: [Talk-de] rolli-parking mit nummer

[M∡rtin Koppenhoefer]

Am 13. Oktober 2010 14:47 schrieb Peter Wendorff :
>  On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote:

> Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert für
> die OSM, und sollte deshalb tunlichst vermieden werden.


M.E. ist ein Datum dann personenbezogen, wenn man es einer Person
zuordnen kann. Das ist bei einer Ausweisnummer nur für die Behörden
gegeben.

Gruß Martin

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

Re: [Talk-de] rolli-parking mit nummer

[Peter Wendorff]

 On 13.10.2010 15:17, M∡rtin Koppenhoefer wrote:

Am 13. Oktober 2010 14:47 schrieb Peter Wendorff:

  On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote:
Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert für
die OSM, und sollte deshalb tunlichst vermieden werden.


M.E. ist ein Datum dann personenbezogen, wenn man es einer Person
zuordnen kann. Das ist bei einer Ausweisnummer nur für die Behörden
gegeben.

Dann spinnen wir uns ein übliches Beispiel zusammen:
Der Parkplatz vor einer Arztpraxis hat Kennzeichenspezifische Stellplätze.
OSM zeigt den Namen der Ärzte an, die Stellplätze haben Kfz-Kennzeichen.

Ich kriege dann vielleicht keine 1:1-Zuordnung, wer welchen Parkplatz 
und welches Nummernschild hat; ich kann aber schon ganz gut einschränken.


Gruß
Peter

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

Re: [Talk-de] Relation als Sammelobjekt

[M∡rtin Koppenhoefer]

Am 13. Oktober 2010 13:45 schrieb Peter Wendorff :
> Ich denke auch, die (Re)implementation der XAPI innerhalb der API wäre der
> richtige Weg.
> Die XAPI ist unheimlich praktisch - aber meistens überlastet.


wenn wir gerade bei "wünsch-Dir-was" sind: ich würde eine Methode gut
finden, um eine lokale db über Diffs synchron zu halten, aber nicht
für den kompletten planet, sondern deutlich kleinere Einheiten wie
z.B. einzelne Länder / Staaten (was man mit einem normalen bis
schwachen PC noch handlen kann). Evtl. könnte man das auch auf lokaler
Seite beim Einspielen der Diffs filtern (nur was innerhalb einer
gewissen BB oder Polygon ist)? Oder kann man nicht jetzt schon die
planet-diffs auf eine Extrakt-Datenbank einspielen und dann was
ausserhalb liegt wieder rausschmeissen?

Gruß Martin

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

Re: [Talk-de] rolli-parking mit nummer

[M∡rtin Koppenhoefer]

Am 13. Oktober 2010 16:21 schrieb Peter Wendorff :
>  On 13.10.2010 15:17, M∡rtin Koppenhoefer wrote:
>>
>> Am 13. Oktober 2010 14:47 schrieb Peter
>> Wendorff:
>>>
>>>  On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote:
>>> Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert
>>> für
>>> die OSM, und sollte deshalb tunlichst vermieden werden.
>>
>> M.E. ist ein Datum dann personenbezogen, wenn man es einer Person
>> zuordnen kann. Das ist bei einer Ausweisnummer nur für die Behörden
>> gegeben.
>
> Dann spinnen wir uns ein übliches Beispiel zusammen:
> Der Parkplatz vor einer Arztpraxis hat Kennzeichenspezifische Stellplätze.
> OSM zeigt den Namen der Ärzte an, die Stellplätze haben Kfz-Kennzeichen.
>
> Ich kriege dann vielleicht keine 1:1-Zuordnung, wer welchen Parkplatz und
> welches Nummernschild hat; ich kann aber schon ganz gut einschränken.


Die Frage war hier nach Parkplätzen für eingeschränkt Mobile, nicht
nach Autonummern, erstere haben gelegentlich ein Zusatzschild der Art
"nur für den Träger des Ausweises Nr. 543543543" (Wortlaut habe ich
gerade nicht parat). Das sind nur dann personenbezogene Daten, wenn
man sie auf eine Person bezieht.

Gruß Martin

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

Re: [Talk-de] Relation als Sammelobjekt

[Jan Tappenbeck]

Am 13.10.2010 11:50, schrieb M∡rtin Koppenhoefer:

Am 13. Oktober 2010 11:36 schrieb Markus:

Zusätzlich braucht man aber m.E. noch irgendein ein System für normale
"relationale" / hierarchische Bezüge (Kategorien):
z.B. für alle Stolpersteine, alle netten Toiletten, etc)



das sind keine hierarchischen Bezüge m.E., und das System gibt es von
Anfang an, es heisst: Tag (k/v).

Ich kann allen raten, die sich wie Jan sowieso Tag und Nacht mit OSM
beschäftigen, schaut Euch mal Postgres/Postgis an. Mit der Anleitung
von Richard (oder einer anderen je nach System, gibts alles im Wiki)
installiert man das Teil in ner viertel Stunde, dann noch mal ein
bisschen fürs Einlesen der Daten, und schwuppdiwupp macht man die
tollsten Abfragen, anfangs durch Abändern von Beispielen, und
irgendwann auch "freihand". Wenn man nett fragt schreibt einem
vielleicht auch hier auf der Liste jemand ein Beispielquery (im
ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist
hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen,
nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im
Zweifel auch nicht immer, was da im Hintergrund passiert.

Gruß Martin

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


HI !
das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber 
wenn ich nur mal kleine anwendungen machen will dann ist das mit der api 
besser.


wenn mir z.b. nur ein netbook zur verfügung steht dann wäre das mit der 
db wohl etwas hoch gegriffen.


ich für meinen teil komme so wie es jetzt ist gut aus. für die 
stolpersteine brauche ich 1 min, für die tankstellen etwas länger. es 
werden sowieso nur die aktuellen themen (PoiM) und kleinigkeiten täglich 
upgedatet - die anderen karten 7/14-tägig und dafür baue ich keine db 
auf. außerdem kann man bei der api auch mal eben von unterwegs ein 
update fahren.


ansonsten siehe ich für karten in größeren ordnungen (garmin) ein 
osm-file von der geofabrik.


nochmal zu (k/v)... wenn sich jeder ein tag für irgendetwas ausedenkt 
dann ist der wildwuchs nicht weit - bei den tankstellen gab es schon 
über 250! tags. dann schon lieber relationen.


gruß Jan :-)


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

Re: [Talk-de] Relation als Sammelobjekt

[M∡rtin Koppenhoefer]

Am 13. Oktober 2010 17:30 schrieb Jan Tappenbeck :

> das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber wenn
> ich nur mal kleine anwendungen machen will dann ist das mit der api besser.


mag sein, für den Durchschnittsanwender gilt das sicher, für Dich
persönlich m.E. eher nicht, wenn ich mir so ansehe, wieviele OSM
Projekte Du betreibst.

> wenn mir z.b. nur ein netbook zur verfügung steht dann wäre das mit der db
> wohl etwas hoch gegriffen.


Ich habe Postgis/Mapnik auf einem Asus 1001p installiert (1,6Ghz Intel
Atom, 1GB RAM, 160GB HD, 249,-EUR vor fast nem Jahr). Ist überhaupt
kein Problem, habe ganz Italien drin, dauerte vielleicht ne halbe
Stunde oder Stunde das Importieren, aber man muss ja nicht
ununterbrochen zusehen ;-)

Die Installation inkl. Kompilieren von Mapnik hat 2-3 Stunden
gedauert, und das, obwohl ich praktisch keine Ahnung habe. Versuchen
könntest Du es mal, sieh aber zu, dass Du wirklich alle Komponenten
jeweils in der vorgeschlagenen Version verwendest, sonst gibts überall
Probleme.

Gruß Martin

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

Re: [Talk-de] Relation - die nette Toilette

[Jan Tappenbeck]

Am 13.10.2010 10:50, schrieb René Falk:

Am 13.10.2010 10:35, schrieb Jochen Topf:


Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein.
nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut
ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die
Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich
ist. Letzteres sollte also auf jeden Fall mit eingetragen werden.


Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man sie
vielleicht überhaupt nicht bei OSM eintragen. :-)


Bei nette Toilette geht es darum bereits bestehende Toiletten der
Gastronomie in öffentliche Toiletten zu wandeln. Ein nette_toilette=yes
an ein Restaurant geklebt, wäre daher vielleicht nicht schlecht.


so sind diese auch gekennzeichnet !

gruß jan :-)



Grüße

René




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

Re: [Talk-de] Relation als Sammelobjekt

[Jan Tappenbeck]

Am 13.10.2010 17:41, schrieb M∡rtin Koppenhoefer:

Am 13. Oktober 2010 17:30 schrieb Jan Tappenbeck:


das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber wenn
ich nur mal kleine anwendungen machen will dann ist das mit der api besser.



mag sein, für den Durchschnittsanwender gilt das sicher, für Dich
persönlich m.E. eher nicht, wenn ich mir so ansehe, wieviele OSM
Projekte Du betreibst.


wenn mir z.b. nur ein netbook zur verfügung steht dann wäre das mit der db
wohl etwas hoch gegriffen.



Ich habe Postgis/Mapnik auf einem Asus 1001p installiert (1,6Ghz Intel
Atom, 1GB RAM, 160GB HD, 249,-EUR vor fast nem Jahr). Ist überhaupt
kein Problem, habe ganz Italien drin, dauerte vielleicht ne halbe
Stunde oder Stunde das Importieren, aber man muss ja nicht
ununterbrochen zusehen ;-)


hi !

pro import ???  und das ggf. täglich ???

gruß Jan :-)


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

Re: [Talk-de] libosm

[andre]

Hallo Hanno,

schön das du das pbf2osm in C geschrieben hast. Habe versucht, das zu 
übersetzen, aber leider scheiter ich an dem protobuf pfad in dem Makefile.


Das Gleiche gilt für libosm. Was für programme benötige ich dafür und 
welchen pfad muss ich einstellen?

Ich benutze Ubuntu Linux.

mfg
Andre

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

Re: [Talk-de] Relation als Sammelobjekt

[Steffen]

--- Original Nachricht ---
Absender: Frederik Ramm
Datum: 13.10.2010 00:01

Mapper tun das oft, weil sie dadurch - vorausgesetzt, sie
kennen die Relations-ID - sehr leicht saemtliche dieser
Objekte herunterladen koennen (mit der
/relation/xxx/full-Abfrage). Das ist komfortabler, als sich
die betr. Objekte anhand der Tags herauszusuchen.

Allerdings sind Relationen dafuer eigentlich nicht gedacht
(http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories
). Daher habe ich vorgeschlagen, die Moeglichkeit, eine
Relation und all ihre Mitglieder herunterzuladen, fuer API
0.7 zu entfernen
(http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features).


JOSM nutzt diese Möglichkeit ja auch. Da können die 
Programmierer, von JOSM, dies ja schonmal versuchen anders 
umzusetzen.


Was ist eigentlich so schlimm an dieser Abfrage-Möglichkeit?

Gruß Steffen

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

Re: [Talk-de] rolli-parking mit nummer

[Walter Nordmann]

M∡rtin Koppenhoefer wrote:
> 
> Die Frage war hier nach Parkplätzen für eingeschränkt Mobile, nicht
> nach Autonummern, erstere haben gelegentlich ein Zusatzschild der Art
> "nur für den Träger des Ausweises Nr. 543543543" (Wortlaut habe ich
> gerade nicht parat). Das sind nur dann personenbezogene Daten, wenn
> man sie auf eine Person bezieht.
> 
ich frage mich, warum sollte die nummer in osm rein? ich sehe absolut keinen
grund dafür.
ok, die info, dass es sich um einen RESERVIERTEN platz handelt "hier
parkplatz aber nicht für dich !!! " ist ok, aber wofür die kennzeichnung?

gruss
walter


-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/rolli-parking-mit-nummer-tp5628601p5632515.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] Relation - die nette Toilette

[Michael Kugelmann]

 Am 13.10.2010 10:17, schrieb aighes:
nette_toilette=yes wäre schon besser. 


bite nicht: nicht für jeden Eigennamen eine eigene Tag-Hierarchie, sonst 
haben wir bald einen unüberschaubaren Wildwuchs. Wenn dann von mir aus 
"Operator=Nette Toilette" oder so etwas. Aber bitte nicht Eigennamen auf 
der Key-Seite, sondern nur auf der Wert-Seite!



Grüße,
Michael.



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

Re: [Talk-de] Relation - die nette Toilette

[Michael Kugelmann]

 Am 13.10.2010 15:14, schrieb M∡rtin Koppenhoefer:

gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine
Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn
das ein Knüller wird, könnte man es auch für die ganze Welt machen)
anzulegen.

Dazu eine Ziztat su dem Tread: am 12.10.2010 23:50, schrieb Ulf Lamping:


Bitte folgendes lesen:

http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories 



... und von dieser Idee Abstand nehmen. 

+1


Grüße,
Michael.  (Kopfschütteln, oder wo steht der Smiley?)


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

Re: [Talk-de] TüV Reinland Breitbandatlas basiert au f OSM-Daten

[Tirkon]

derandi  wrote:

>http://www.zukunft-breitband.de/BBA/Navigation/Breitbandatlas/breitbandsuche.html
>
>Interessant ist das ein Ministerium des Bundes die Daten nutzt. ;)

Immerhin haben wir eine Person in der Community, die dort tätig ist
und auf dem letzten bundesdeutschen OSM Treffen im Rahmen der Fossgis
2010 einen Vortrag gehalten hat.


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

Re: [Talk-de] Relation als Sammelobjekt

[Walter Nordmann]

M∡rtin Koppenhoefer wrote:
> 
> 
> schwachen PC noch handlen kann). Evtl. könnte man das auch auf lokaler
> Seite beim Einspielen der Diffs filtern (nur was innerhalb einer
> gewissen BB oder Polygon ist)? Oder kann man nicht jetzt schon die
> planet-diffs auf eine Extrakt-Datenbank einspielen und dann was
> ausserhalb liegt wieder rausschmeissen?
> 
ich hab früher einfach ne bbox in das osm2pgsql-script eingebaut. 
dort wo osmosis den job macht. dennoch kamen viele daten in die db.

bei der - für mich besseren - osmosis/simple geht das ja nicht, da osmosos
das mit diff-files nicht zuläßt. da wird die db bald riesig, auch wenn man
nur z.b. mit castrop-rauxel angefangen hat. irgendwann sind die osterinseln
auch drin gewesen.

inzwischen schmeiss ich sehr viele daten einfach raus, die zu weit draussen
liegen. zuletzt mussten 28 mio nodes dran glauben.
das verfahren für osm2pgsql ist im ansatz hier beschrieben:
http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase
ich musste das aber erheblich an die osmosis/simple 0.37 anpassen, weil die
datenstruktur total anders ist.
das prinzip ist bei beiden ganz einfach: 
schritt 1: alle nodes raus, die weg sollen
schritt 2: alle ways raus, die keine nodes (mehr) haben
schritt 3: alle relationen raus, die (jetzt) leer sind (keine nodes UND
keine ways).

dazu hab ich mir dann noch ne relativ große bbox definiert, damit ich in den
grenzgebieten nichts verliere

das ganze per chron: a) import des diffs b) cleanup

gruss
walter


-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5632642.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] rolli-parking mit nummer

[Stefan Keller]

Hallo

Bitte beachtet, dass das aktuelle Konzept von 'Parkplatz' ein
Parkplatz-Areal meint. Daher auch der optionale Zusatz-Tag
capacity=number für die Anzahl der verfügbaren Parkplätze eines Areals
(vgl. http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking).

Ich meine, dass persönliche Parkplätze (ob Areal oder Einzel) nicht
interessant sind für OSM, ähnlich wie private. Auf jeden Fall kann
m.E. eine solche Nummer nur an Einzelparkplätze hinzugefügt werden
(auch wenn das amenity=parking als Node zulassen würde).

Einzelparkplätze sollten *nicht* mit "amenity=parking" getaggt werden.
Der aktuelle Vorschlag ist "parking_space=normal|woman|disabled|yes"
(vgl. die Diskussion hier:
http://www.mail-archive.com/talk-de@openstreetmap.org/msg75425.html
!).

LG, S.


Am 13. Oktober 2010 22:11 schrieb Walter Nordmann :
>
>
> M∡rtin Koppenhoefer wrote:
>>
>> Die Frage war hier nach Parkplätzen für eingeschränkt Mobile, nicht
>> nach Autonummern, erstere haben gelegentlich ein Zusatzschild der Art
>> "nur für den Träger des Ausweises Nr. 543543543" (Wortlaut habe ich
>> gerade nicht parat). Das sind nur dann personenbezogene Daten, wenn
>> man sie auf eine Person bezieht.
>>
> ich frage mich, warum sollte die nummer in osm rein? ich sehe absolut keinen
> grund dafür.
> ok, die info, dass es sich um einen RESERVIERTEN platz handelt "hier
> parkplatz aber nicht für dich !!! " ist ok, aber wofür die kennzeichnung?
>
> gruss
> walter
>
>
> -
> Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
> hinein. - Ingo Insterburg
> --
> View this message in context: 
> http://gis.638310.n2.nabble.com/rolli-parking-mit-nummer-tp5628601p5632515.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
>

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

Re: [Talk-de] Relation - die nette Toilette

[Wolfgang]

Hallo,
Am Mittwoch 13 Oktober 2010 15:14:46 schrieb M∡rtin Koppenhoefer:
> Am 13. Oktober 2010 08:36 schrieb Jochen Topf :
> > Wir haben ja auch nicht
> > alle Einbahnstraßen in einer Relation, oder?
> 
> gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine
> Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn
> das ein Knüller wird, könnte man es auch für die ganze Welt machen)
> anzulegen.
> 
> Ein paar Infos zu Einbahnstraßen ist hier zusammengetragen:
> http://www.gutefrage.net/tag/einbahnstrasse/1
> 
> sobald ich fertig bin lade ich das hoch und gebe hier Bescheid, was
> die einzelnen Relationen-IDs sind.
> 

Klasse Idee!

Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt!

Gruß, Wolfgang

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

Re: [Talk-de] Relation - die nette Toilette

[Michael Bemmerl]

Wolfgang schrieb:
> Hallo,
> Am Mittwoch 13 Oktober 2010 15:14:46 schrieb M∡rtin Koppenhoefer:
>> Am 13. Oktober 2010 08:36 schrieb Jochen Topf :
>>> Wir haben ja auch nicht
>>> alle Einbahnstraßen in einer Relation, oder?
>> gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine
>> Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn
>> das ein Knüller wird, könnte man es auch für die ganze Welt machen)
>> anzulegen.
> 
> Klasse Idee!
> 
> Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt!

Warum nicht gleich 'ne Relation aller Nodes, Ways und Relationen? Da
können wir uns dann endlich diese großen planet-files sparen! ;-)

Grüße,
Michi



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

Re: [Talk-de] Relation als Sammelobjekt

[Tobias Knerr]

Am 13.10.2010 21:37, schrieb Steffen:
>> Daher habe ich vorgeschlagen, die Moeglichkeit, eine
>> Relation und all ihre Mitglieder herunterzuladen, fuer API
>> 0.7 zu entfernen
>> (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features).
[...]
> Was ist eigentlich so schlimm an dieser Abfrage-Möglichkeit?

Das Problem ist wohl nicht die Abfragemöglichkeit an sich, sondern dass
die API hier momentan Relationen gegenüber anderen Möglichkeiten der
"Gruppierung" bevorzugt - dass es also für Relations-Mitglieder eine
Abfragemöglichkeit direkt in der API gibt, aber für z.B. Objekte mit
gleichen Tags oder Objekte innerhalb einer Grenze derzeit keine ebenso
komfortable Anfrage existiert.

Hätten Mapper die Disziplin, Relationen trotzdem nur dort zu verwenden,
wo sie angebracht sind, wäre das ja kein Problem. Aber diese technische
"Wettbewerbsverzerrung" wird eben zunehmend als Anlass genommen, Dinge,
für die etwa Tags oder Grenzen eigentlich die bessere Lösung wären,
stattdessen oder zusätzlich mit Relationen einzutragen.

Tobias Knerr

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

Re: [Talk-de] Relation - die nette Toilette

[Tobias Knerr]

Am 14.10.2010 00:24, schrieb Michael Bemmerl:
> Wolfgang schrieb:
>> Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt!
> 
> Warum nicht gleich 'ne Relation aller Nodes, Ways und Relationen? Da
> können wir uns dann endlich diese großen planet-files sparen! ;-)

Oh, prima. Ich mache eine Relation aller Relationen, die sich nicht
selbst enthalten. ;-)

Tobias Knerr

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

Re: [Talk-de] Fahrrad-Access-Karte überarbeitet

[Thomas Ineichen]

Hallo Heiko,

am Dienstag, 12. Oktober 2010 um 21:48 schrieben Sie:

> Am 11.10.2010 12:01, schrieb Thomas Ineichen:
>> Weiss für verfestigte/bearbeitete Oberflächen

> Mir fällt gerade auf, dass weiß etwas suboptimal kommt ...
> Gelb vielleicht besser?
> Ansonsten hübsch ;-)

Die  weissen Striche ohne Access-Umrandung sind eigentlich ungewolltes
Nebenprodukt, daher müssen sie gar nicht sichtbar sein.. ;-)

> Ginge noch Osmarender als weitere wählbare Hintergrundkarte?
> In den besseren Zoomstufen sind Feld-/Rad-/Gehwege darin nicht
> nur dünne Striche, sondern breit, so dass man evtl. den Basisweg
> besser erkennen könnte.

Ist integriert. Zusätzlich kann man auch meinen Layer aufhellen (20%),
so dass die dahinterliegende Karte besser durchscheint.


Gruss,
Thomas



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

Re: [Talk-de] Relation - die nette Toilette

[Johann H. Addicks]

Am 13.10.2010 15:14, schrieb M∡rtin Koppenhoefer:


Ein paar Infos zu Einbahnstraßen ist hier zusammengetragen:


Ich hoffe eigentlich immer anständig, dass Toiletten Einbahnstraßen (für 
die Fäkalien) sind.


-jha-


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

Re: [Talk-de] Relation - die nette Toilette

[Johann H. Addicks]

Am 13.10.2010 18:07, schrieb Jan Tappenbeck:

Bei nette Toilette geht es darum bereits bestehende Toiletten der
Gastronomie in öffentliche Toiletten zu wandeln.



so sind diese auch gekennzeichnet !


Interessanter wird hier das Öffnungszeiten-Mapping.
Denn was hilft eine angeblich öffentliche Toilette, wenn das umgebende 
Geschäft z.B. Montag Ruhetag hat oder oder in der zweiten Januarwoche 
Betriebsferien macht.


-jha-


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

[Talk-de] Ampel-Tagging (Re: Relation - die nette Toilette)

[Johann H. Addicks]

Am 14.10.2010 00:09, schrieb Wolfgang:



Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt!


Welches Tagging-Schema gilt denn für die Lackierung der Masten und Farbe 
von Auslegerarm, Signalgeberkammer, Sonnenschute? Dazu gibt's dann noch 
die Kontrastblenden in schwarz mit weißem Rand und weiss mit schwarzem 
Rand, eckig, rund etc.pp.


Die von Dir angesprochenen grünen Ampeln kenne ich jedoch nur aus Italien:
http://www.info-lsa.de/images/Ampelbilder/EUR/Italien_Rom_FGrt.jpg

-jha-


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

Re: [Talk-de] Fahrrad-Access-Karte überarbeitet

[Thomas Ineichen]

Hallo Steffen,

> Kommt eigentlich auf das Kopfsteinpflaster an. Wenn es einigermassen
> eben ist, dann stimm ich dir zu. Wenn es aber von Stein zu Stein
> Hoehenunterschiede von 5cm gibt, dann ist's wenigstens weiss, wenn nicht
> schon rot.

Wahrscheinlich bin ich hier in der Schweiz einfach zu verwöhnt. Leider
haben  von  den  67'143  cobblestone-highways  nur  gerade  1'444 eine
Smoothness-Angabe:
http://toolserver.org/~ti/cobblestone.txt

Ich  bastle  gerade  an  einer  anderen Anwendung, bei der Oberflächen
wichtiger  sind,  ev.  fallen von dort ein paar Code-Schnipsel ab. Bis
dahin werde ich cobblestone auf schwarz/weiss ändern.


> Grau? Also Mischfarben zwischen den drei gewaehlten Farben, je nach
> Auspraegung mal mehr die eine, mal mehr die andere. Macht das aber auch
> nicht uebersichtlicher, wenn erstmal 100 Abstufungen eingetragen sind.

Und  dann  gibt's  dafür  die Diskussionen, ob ein gravel-Weg mit good
heller  oder  dunkler  sein  sollte  als  ein compacted-Weg mit inter-
mediate :->

SELECT smoothness, surface, count
WHERE tags ? 'surface'
GROUP BY smoothness, surface
http://toolserver.org/~ti/smoothness_surface.txt


> Wenn du irgendwie XAPI oder Datenbank abfragst mit Select * where
> surface=key, dann nicht. Wenn du aber irgendwann den vollstaendigen Weg
> sowieso in die Hand nimmst, dann kannst du s/;.*// anwenden und nur den
> ersten Eintrag parsen.

Wenn,  dann  möchte ich aber den 'schlechtesten' der Tags erkennen, um
den Weg entsprechend hell einzufärben. Soviel Qualität muss sein. ;-)


> Beschriftungen wuerde ich vermeiden wollen. Ich haett's als halbes oder
> ganzes Verbot gewertet. Wenn du willst: Stricheln mit entsprechender
> Laenge der Striche und Luecken ;-)

Wir  hatten vorgestern am Zürcher Stammtisch eine Präsentation/Diskus-
sion mit dem Chef von OCAD[1], einer Kartographie-Software - Fazit: In
schönen und ansprechenden Karten steckt verdammt viel Arbeit..

> Eins fiel mir noch auf: Die bicycle=permissive werden nicht dargestellt.
> In der Legende steht bicycle=permessive, vielleicht ist der Tippfehler
> auch im Programmcode?

Das  schreibe ich ständig falsch, obwohl ich eigentlich weiss, dass es
von 'permission' kommt.. :-/

Der  Stil ist aktualisiert und stellt jetzt auch Motorfahrzeug-Verbote
in  hellblau  dar. Die Caching-Strategie von Tirex sorgt aber offenbar
dafür, dass die Kacheln nicht sofort neu gerendert werden..


Gruss,
Thomas

[1] http://ocad.ch/


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

Re: [Talk-de] Relation - die nette Toilette -ver... mich selber

[Jan Tappenbeck]

Am 14.10.2010 00:47, schrieb Tobias Knerr:

Am 14.10.2010 00:24, schrieb Michael Bemmerl:

Wolfgang schrieb:

Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt!


Warum nicht gleich 'ne Relation aller Nodes, Ways und Relationen? Da
können wir uns dann endlich diese großen planet-files sparen! ;-)


Oh, prima. Ich mache eine Relation aller Relationen, die sich nicht
selbst enthalten. ;-)

Tobias Knerr

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


ich wußte nicht das mapper so humorvoll und einfallsreich sind ...!


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

Re: [Talk-de] Relation als Sammelobjekt

[André Joost]

Am 13.10.10 17:30, schrieb Jan Tappenbeck:



HI !
das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber
wenn ich nur mal kleine anwendungen machen will dann ist das mit der api
besser.



Prinzipiell ist die api ja für das Editieren zuständig.
Für Anwendungen wäre die xapi ausreichend, wenn es dort entsprechende 
Funktionalitäten geben würde. Leider ist die xapi in einer obskuren 
Sprache geschrieben, an die sich niemand rantraut :-(

Von der Verfügbarkeit der Server mal abgesehen...

Gruß,
André Joost






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

Re: [Talk-de] Relation - die nette Toilette -ver... mich selber

[Walter Nordmann]

moin moin,

ja so ab und zu muss mal auch mal die luft rauslassen. 
die ganze (frei-)zeit durch die pampa schleichen -  mit stahlstiefeln durch
das dickicht kriechen, weil ja zur zeit die pilze aus dem boden schießen -
sich mit netten nachbarn unterhalten, die schon wieder den film aus der
kamera haben wollen und den nicht finden können, 
und schon wieder ist der eimer mit lila farbe leer, mit dem die pois vor ort
markiert werden, so wie es in einem nordkoreanischen wiki drin steht, ...

das kann schon stressig sein.

lg
walter



-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5633929.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