Re: [Talk-de] St.-ZickeZacke-Str.

[Manuel Reimer]

Fabian Schmidt  informatik.uni-leipzig.de> writes:
> Der Dr. wird auch da abgekürzt, wo Platz ist:
> http://www.studis-online.de/Studieren/Richtig_schreiben
/anrede_und_gruss.php

Mag ja sein. Dennoch finde ich es nicht praktikabel beim Übertragen in ein
Navi (zumindest mein Garmin im Auto hat Sprachausgabe) das "Dr." erst
automatisch nach "Doktor" übersetzen zu müssen. Ich will zumindest nicht,
dass mein Navi mir die Abkürzung vorliest. Und ein Navi ist eben kein Mensch
der bei "Dr." unterbewusst schon "Doktor" liest.

Name ist und bleibt eigentlich "Doktor" und nicht "Dr.". Das einzige
Argument für "Dr." wäre wohl "sieht auf der Karte unschön aus". Wobei das
zum einen Geschmackssache ist und zum Anderen ein typischer Fall von "Mappen
für den Renderer" wäre. Ein Fall, der möglicherweise auf Renderer-Seite
sogar gefixt werden könnte. Wenn man da leichter Einfluss hätte, könnte man
wohl manche Tagging-Diskussion im Keim ersticken...

Ich habe keine Ahnung was Mapnik kann, aber irgendwo wäre es schon reizvoll
mal einen Satz Tiles in ein paar Zoomstufen zu bauen bei denen, je nach
verfügbarem Platz, in mehreren Stufen automatisch abgekürzt wird. Also z.B.
im ersten Schritt "Sankt" durch "St.", "Doktor" durch "Dr.",  Wenn auch
das nicht reicht, dann "straße" durch "str.", "gasse" durch "g." und so
weiter...

Die Frage ist doch: Werden nun volle Namen getaggt und wenn nein: Welche
Abkürzungen sollen verwendet werden (und warum). Ich habe schon viele
Straßenschilder gesehen, auf denen "Straße" mit "Str." gekürzt war. Dennoch
trägt man in dem Fall "Straße" ein. Warum also gerade beim "Doktor" eine
Ausnahme machen?

Das mit den Straßen in meinem Umfeld werde ich bei Gelegenheit mal auf dem
Garmin simulieren und dann mal schauen was mir ansagt wird, wenn in die
betroffene Straße abgebogen werden soll. Sollte "Dee Err" angesagt werden,
dann ändere ich mal den Straßennamen unter Verweis auf das Wiki und darauf,
dass die Ansage vom Navi ansonsten falsch ist. Bleibt nur zu hoffen, dass da
kein Edit-War draus wird.

Gruß

Manuel


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

Re: [Talk-de] Hitler-Berg und Stalinstadt

[Holger Jeromin]

Angie schrieb am 06.02.2014 21:33:

> die Gemeinde Wackersberg einigt sich mit dem Riesen Google, dass die
> Weiterleitung vom ex Hitlerberg auf den Heigelkopf entfernt wird. Bei OSM ist
> das als old_name getaggt - soweit so richtig.

http://www.openstreetmap.org/node/414607685

ja, hatte ich nach einem Artikel in Heise als
old_name:1934-1945
getaggt. Ich bin nur überrascht, dass nominatim den bei "Hitlerberg"
findet. Hatte gehofft, dass das nicht tut, damit die arme Gemeinde nicht
auch noch OSM/Nominatim verklagt :-)

> Was ist aber z.B. mit ex Stalinstadt, seit 1961 Eisenhüttenstadt?
> Müsste da nicht auch ein old_name:1953-1961 Stalinstadt -Tag rein?
> Zumal die Stadt 1953 mit diesem Namen gegründet wurde.

Fänd ich ok.

> Oder wie weit sollten die historischen Namen bei OSM geführt werden?
> Chemnitz z.B. hat einige Namen gehabt
> --> http://de.wikipedia.org/wiki/Geschichte_der_Stadt_Chemnitz
> 
> Wie weit sollte also ein old_name-Tag zurück gehen?

Das würde ich nicht einschränken wollen. OSM wird ja allgemein immer
detaillierter, wieso nicht auch in der Dimension.

-- 
Grüße
Holger


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

Re: [Talk-de] Hitler-Berg und Stalinstadt

[Peter Körner]

Hi

wie's ausschaut ist nominatim schlauer als wir uns analysiert auch
mehrere old_name:*-Tags:


LG

Am 07.02.2014 10:45, schrieb Holger Jeromin:
> Angie schrieb am 06.02.2014 21:33:
> 
>> die Gemeinde Wackersberg einigt sich mit dem Riesen Google, dass die
>> Weiterleitung vom ex Hitlerberg auf den Heigelkopf entfernt wird. Bei OSM ist
>> das als old_name getaggt - soweit so richtig.
> 
> http://www.openstreetmap.org/node/414607685
> 
> ja, hatte ich nach einem Artikel in Heise als
> old_name:1934-1945
> getaggt. Ich bin nur überrascht, dass nominatim den bei "Hitlerberg"
> findet. Hatte gehofft, dass das nicht tut, damit die arme Gemeinde nicht
> auch noch OSM/Nominatim verklagt :-)
> 
>> Was ist aber z.B. mit ex Stalinstadt, seit 1961 Eisenhüttenstadt?
>> Müsste da nicht auch ein old_name:1953-1961 Stalinstadt -Tag rein?
>> Zumal die Stadt 1953 mit diesem Namen gegründet wurde.
> 
> Fänd ich ok.
> 
>> Oder wie weit sollten die historischen Namen bei OSM geführt werden?
>> Chemnitz z.B. hat einige Namen gehabt
>> --> http://de.wikipedia.org/wiki/Geschichte_der_Stadt_Chemnitz
>>
>> Wie weit sollte also ein old_name-Tag zurück gehen?
> 
> Das würde ich nicht einschränken wollen. OSM wird ja allgemein immer
> detaillierter, wieso nicht auch in der Dimension.
> 


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

Re: [Talk-de] Hitler-Berg und Stalinstadt

[Martin Koppenhoefer]

> Am 06/feb/2014 um 21:33 schrieb Angie :
> 
> Bei OSM ist
> das als old_name getaggt - soweit so richtig.


+1


> Was ist aber z.B. mit ex Stalinstadt, seit 1961 Eisenhüttenstadt?
> Müsste da nicht auch ein old_name:1953-1961 Stalinstadt -Tag rein?


m.E. ja


> 
> Oder wie weit sollten die historischen Namen bei OSM geführt werden?


prinzipiell beliebig, sofern die Quellen das hergeben und es Mapper gibt, die 
das eintragen 

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

Re: [Talk-de] Luftbild-Versatz - Schachtdeckel

[Markus]

Liebe OSMer,

Schachtdeckel (Gulli-Deckel)
- haben einen eindeutigen Mittelpunkt
- sind im Luftbild gut zu erkennen
- sind in besiedelten Gebieten verbreitet

Wenn man also eine genaue Koordinate hat,
sind solche Schachtdeckel gut geeignet
für die Georeferenzierung von Luftbildern.

_Tagging-Schema_

Vorschläge zum "taggen" waren:

man_made=survey_point (281'532)
http://wiki.openstreetmap.org/wiki/DE:Tag:man_made=survey_point
ist aber ursprünglich für (amtl.) Vermessungspunkte gedacht (TP, HP)

Für Gulli-Deckel:
manhole=* (17'701)
http://wiki.openstreetmap.org/wiki/DE:Key=manhole
http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_GPS-Gerät_prüfen#Vermessungspunkte_in_OSM

Zum "Verankern":
coordinates_lat = 12.3456789
coordinates_lon = 12.3456789
coordinates_system = WGS84
Wird das schon irgendwo verwendet?

lat/lon in Kombination (2,6 Mio)
latitude/longitude (5080)
lat/lon (966)

Für solche "Verankerungs-Koordinaten"
sollten wir uns auf ein System einigen...

Gruss, Markus

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

Re: [Talk-de] Hitler-Berg und Stalinstadt

[Caronna]

Am 07.02.2014 10:55, schrieb Martin Koppenhoefer:


>
> Oder wie weit sollten die historischen Namen bei OSM geführt werden?


prinzipiell beliebig, sofern die Quellen das hergeben und es Mapper gibt, die 
das eintragen



auch zeitlich?
da käme oft ne ganze Menge zusammen... und wenn dann noch die 
ausländischen dazukommen.


Grüße aus der Eifel
Steffen



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

Re: [Talk-de] Hitler-Berg und Stalinstadt

[Peter Körner]

Hi

Am 07.02.2014 12:07, schrieb Caronna:
> Am 07.02.2014 10:55, schrieb Martin Koppenhoefer:

> auch zeitlich?
> da käme oft ne ganze Menge zusammen... und wenn dann noch die
> ausländischen dazukommen.

*leicht ironisch*
das wäre ja fast so viel, wie wenn man alle dorfstraßen in der ganzen
welt erfassen würde. oh - wait.

Genau darum geht's ja bei OSM. Wenn ein Ort oder ein Objekt eine lange
Geschichte und es leute gibt, denen das wichtig ist, gibt's kein grund
das nicht zu erfassen.

Lg


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

Re: [Talk-de] Hitler-Berg und Stalinstadt

[Caronna]

Am 07.02.2014 12:13, schrieb Peter Körner:

Genau darum geht's ja bei OSM. Wenn ein Ort oder ein Objekt eine lange
Geschichte und es leute gibt, denen das wichtig ist, gibt's kein grund
das nicht zu erfassen.


ich wohne ja hier fast im Dreiländereck... wenn ich mir überlege wie 
viele Namen Aachen in NL, B, F hat...und das sind die heutigen Namen

Sinnvoll isses auf jeden Fall zumindest diese einzupflegen

Grüße aus der Eifel
Steffen

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

Re: [Talk-de] St.-ZickeZacke-Str.

[jotpe]

Am 7. Februar 2014 09:49 schrieb Manuel Reimer :

> Die Frage ist doch: Werden nun volle Namen getaggt und wenn nein: Welche
> Abkürzungen sollen verwendet werden (und warum). Ich habe schon viele
> Straßenschilder gesehen, auf denen "Straße" mit "Str." gekürzt war. Dennoch
> trägt man in dem Fall "Straße" ein. Warum also gerade beim "Doktor" eine
> Ausnahme machen?
>


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

Re: [Talk-de] Luftbild-Versatz - Schachtdeckel

[Frederik Ramm]

Hallo,

On 02/07/14 11:33, Markus wrote:
> Zum "Verankern":
> coordinates_lat = 12.3456789
> coordinates_lon = 12.3456789

Ich verstehe noch nicht, in welcher Situation sich dieser Gulli in
unseren Daten an einer anderen Position als dieser befinden sollte?

Bye
Frederik


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

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

Re: [Talk-de] Luftbild-Versatz - Schachtdeckel

[chris66]

Moin,

> Für Gulli-Deckel:
> manhole=* (17'701)
> http://wiki.openstreetmap.org/wiki/DE:Key=manhole
> http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_GPS-Gerät_prüfen#Vermessungspunkte_in_OSM
> 
> 
> Zum "Verankern":
> coordinates_lat = 12.3456789
> coordinates_lon = 12.3456789
> coordinates_system = WGS84

Es fehlt noch der Zeitpunkt der Verankerung, da die Koordinaten ja mit
der irren Geschwindigkeit von 2 cm pro Jahr Richtung Nordost wandern
in Europa. :)

Chris




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

[Talk-de] RadioOSM: OSMDE027 Zusammengeklebende Flächen

[mazdermind]

Hallo liebe OpenStreetMapper,
die neuste Folge von RadioOSM - OSMDE027 Zusammengeklebende Flächen - ist 
verfügbar und sollte in Kürze in euren Podcatchern auftauchen.
Natürlich könnt ihr diese Folge auch in unserem Blog hören: 
http://ift.tt/1d2bM4G
Dort findet ihr auch Links zu allen Themen, über die wir gespochen haben.
Viel Spaß damit und Liebe Grüße,
euer RadioOSM Team
- Andi, Marc und Peter
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Mapnik Administration blockt QLandkarteGT

[hike39]

Hallo zusammen,
ich nutze für die Planung meiner Wanderungen QLandkarteGT. Tolles
Produkt, das die ganze Zeit wunderbar funktioniert hat. Nun mußte ich
gestern feststellen, dass die OSM Kacheln nicht mehr angezeigt werden.

In dem Forum von QLandkarteGT mußte ich dann feststellen, dass ich nicht
der einzige bin, der dies festgestellt hat. Eine Nachfrage ergab dann
den Hinweis, dass die Mapnik Administration das Abrufen der Tiles durch
QLandkarteGt abblockt.

Christoph Bledl schrieb:
> But the strength they (the mapnik tile administrators) enforce their
> policy. qlandkartegt, at least in some versions, is currently blocked
> there.
> ...
> My longer statement not everybody agrees with can be found here:


Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert werden?

Gruß
hike39

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Sven Geggus]

hike39  wrote:

> Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
> OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert
> werden?

Das Problem ist nicht die Onlinenutzung, das Problem ist der Massenhafte
Kacheldownload, dennd er zerstört das Konzept des on demand rendering.

Ich verwende für meine Tourenplanung (Fahrrad und Wandern) das Programm
Viking. Das lädt wie ein Browser Kacheln nur on Demand runter. Sowas darf
IMO nicht geblockt werden.

Als Admin von tile.openstreetmap.de ist mir aber insbesondere "locus" auch
schon negativ aufgefallen. da werden tiles nicht nur on demand geladen
sondern massenhaft untergeladen.

Gruss

Sven

-- 
Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das
Verbindungsgebrüll. (aus einer Ebay fishing Mail)

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

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Sven Geggus]

Alexander Lehner  wrote:

> @Sven: Worin besteht das Problem des On-Demand Rendering bei 
> Massendownloads? Da kenne ich den Mechanismus dahinter zu wenig.
> Ist das bei openstreetmap.org genauso?

Tirex und renderd machen das so. osm.org verwendet AFAIK letzteren.

> 
> Die Datenmenge kann es wahrscheinlich nicht sein, das sind 100-400MB, die 
> laedt man sich einmal im Vierteljahr runter und gut ists.

Wie der Name schon sagt wird nicht alles gerendert und im Dateisystem
abgelegt. Insbesodnere bei den hohen Zoomleveln, bei denen sowieso 90% der
Erdoberfläche blau sind wird nur gerendert wenn sich jemand das wirklich
anschaut.

Wenn die Leute jetzt Programme anwerfen, die einfach bis Zoomlevel 19 runter
alles absaugen muss ein großer Teild er Kacheln erst gerendert werden.

Gruss

Sven

-- 
Der "normale Bürger" ist nicht an der TU Dresden und schreibt auch
nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion)

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

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[pmsg]

Hallo,
ich benutze für meine Mapping-Aktionen "MyTrails" und lade gerne auf
einmal 300 bis max 1000 Tiles für Offlinenutzung herunter. Das tue ich
vielleicht max. 2-3 pro Woche.  Mobilfunk ist mir normalerweise zu
unzuverlässig, langsam und teuer.
Möglicherweise ist das schon ein Verstoß gegen die Tile usage policy
[1]. Ich könnte:

1) Ein eigener Tile-Server betreiben. Das kommt für mich aufgrund des
Aufwandes zur Zeit nicht in Frage.
2) Abo-Lösung von GeoFabrik bezahlen. Ich bin dazu geneigt, aber die
kleinste Variante ist mir schon zu "kommerziell". Die kleinste
Variante kostet 500 EURO/Jahr (12*35 EURO*1,19) im Voraus und erlaubt 100.000
Tiles pro Monat. Das ist 2-4 Mal mehr als ich realistisch brauche und
auch ca. 2-4 Mal mehr als ich bereit bin zu bezahlen.
3) ... ?

Welche alternative Möglichkeiten habe ich?

Viele Grüße,
pmsg

PS: Die deutsche und englische Fassung von [1] widersprechen sich
bezüglich der höchsten Zoomstufe (16/17), die on Demand gerendert
wird.


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

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Peter Wendorff]

Hallo Alex,

Ja, das ist bei osm.org letztlich genauso.

Kacheln in detaillierteren Zoomstufen werden auf Abruf gerendert. Also:
Wenn Du da hinsurfst, wird die Kachel in die Render-Queue reingeschoben,
die Software erzeugt ein Bild und das wird ausgeliefert.
Ja, da wird auch was gespeichert und bei erneutem Abruf direkt wieder
ausgeliefert, aber vieles kommt eben durchaus direkt (Abwägung zwischen
Speicherplatz und Rechenlast).

Wenn Du im Browser surfst, hast Du einen begrenzten Bildschirm.
Selbst bei einer HD-Auflösung von 1920x1080 und einer Karte im Vollbild
sind das gerademal rund 8*4=32 Kacheln, die du gleichzeitig sehen kannst.
Mit wildem verschieben des Kartenausschnitts wirds etwas mehr, aber das
hält sich im Rahmen.

Wenn Du jetzt aber Deutschland siehst und die Software läd z.B. bis z17
alle Kacheln, die "dahinterliegen" mit runter, sind das exponentiell
mehr Kacheln (mit jedem zoomlevel vervierfacht sich ja die Anzahl, und
das überlastet natürlich auf Dauer die Server.

Software, die das tut, wird deshalb blockiert, wenn sie dadurch den
Serverbetrieb stört oder zu stören droht; und auf Serverseite sind dabei
auch "gute" von "schlechten" Nutzern einer Software nicht zu
unterscheiden - es wäre also technisch nicht möglich, die App X nur für
Funktion Y zu blockieren, Funktion Z aber zuzulassen.

Die Daten sind frei, und wer eine solche Funktionalität anbieten will,
soll entweder einen Renderer in die Software einbauen oder sich irgendwo
einkaufen, was Serverlast für Download und Rendering angeht.

Du meinst nun, die vorgerenderten Kacheln wären besser als das, was du
lokal auf dem Smartphone erzeugst, und lädst die Kacheln auch noch
selbst runter: Nichts spräche dagegen, wenn du dir stattdessen die Daten
runterladen und die Kacheln lokal am Desktop rendern würdest, um sie
dann aufs Smartphone zu ziehen, und es spricht auch nichts dagegen, wenn
z.B. QLandkarte genau das unterstützen würde.

Gruß
Peter

Am 07.02.2014 16:15, schrieb Alexander Lehner:
> 
> 
> On Fri, 7 Feb 2014, Sven Geggus wrote:
> 
>> hike39  wrote:
>>
>>> Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
>>> OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert
>>> werden?
>>
>> Das Problem ist nicht die Onlinenutzung, das Problem ist der Massenhafte
>> Kacheldownload, dennd er zerstört das Konzept des on demand rendering.
>>
>> Ich verwende für meine Tourenplanung (Fahrrad und Wandern) das Programm
>> Viking. Das lädt wie ein Browser Kacheln nur on Demand runter. Sowas darf
>> IMO nicht geblockt werden.
>>
>> Als Admin von tile.openstreetmap.de ist mir aber insbesondere "locus"
>> auch
>> schon negativ aufgefallen. da werden tiles nicht nur on demand geladen
>> sondern massenhaft untergeladen.
> 
> tangoGPS bzw. foxtrotGPS machen das ebenfalls so (Region auswaehlen,
> angeben bis zu welcher Zoomstufe man tiles runterladen will).
> 
> Ich nutze diese Programme sehr gern auf meinem 'Smartphone', weil die
> fertig gerenderten Karten einfach schoener sind als die lokal gerenderten.
> Zu Hause die Kacheln runterladen und beim Mountainbiken im Wald, wo's
> kein UMTS gibt, hat man die Karten parat. Ist schon nett.
> 
> @Sven: Worin besteht das Problem des On-Demand Rendering bei
> Massendownloads? Da kenne ich den Mechanismus dahinter zu wenig.
> Ist das bei openstreetmap.org genauso?
> 
> Die Datenmenge kann es wahrscheinlich nicht sein, das sind 100-400MB,
> die laedt man sich einmal im Vierteljahr runter und gut ists.
> 
> A.
> 
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Alexander Lehner]

On Fri, 7 Feb 2014, Peter Wendorff wrote:


Kacheln in detaillierteren Zoomstufen werden auf Abruf gerendert. Also:
Wenn Du da hinsurfst, wird die Kachel in die Render-Queue reingeschoben,
die Software erzeugt ein Bild und das wird ausgeliefert.
Ja, da wird auch was gespeichert und bei erneutem Abruf direkt wieder
ausgeliefert, aber vieles kommt eben durchaus direkt (Abwägung zwischen
Speicherplatz und Rechenlast).


OK, danke fuer die Beschreibung. Das erklaert auch, warum nach Edits das 
Ergebnis praktisch immer sofort sichtbar ist ;)



[...]
Du meinst nun, die vorgerenderten Kacheln wären besser als das, was du
lokal auf dem Smartphone erzeugst, und lädst die Kacheln auch noch
selbst runter: Nichts spräche dagegen, wenn du dir stattdessen die Daten
runterladen und die Kacheln lokal am Desktop rendern würdest, um sie
dann aufs Smartphone zu ziehen, [...]


Ich habe tatsaechlich einen eigenen mapnik Renderer am Laufen, und 
zumindest fuer Bayern funktioniert der auch _halbwegs_.
Wer das selber schon mal probiert hat, weiss vielleicht in etwa, mit 
welchen Problemen man da zu tun bekommt. Einfach ist anders...



Aber OK, ich habe das Problem verstanden und werde nun vorbildlicherweise 
vermeiden, exponezielle Tilemengen herunterzuladen 8>



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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Carsten Schwede]

Hallo,

ich kann überhaupt nicht verstehen, warum so viele offenbar QLandkarteGT 
mit den Onlinekacheln verwenden. Das Programm ist in erster Linie dafür 
entworfen worden mit den Kartenpaketen für Garmingeräte zu arbeiten. Die 
einfachste und von Onlinequellen unabhängige Methode ist eines der 
Pakete zu nutzen und in QLandkarte zu integrieren. Der Vorteil ist auch 
noch, daß man eigentlich noch ein paar Möglichkeiten mehr hat zu planen, 
da die Kartenelemente dann "magnetisch" sind, und man Route anhand der 
Wege und Straßen legen kann ohne jede Biegung mitzumachen. (Die 
entstehen dann automatisch)
QLandkarte ist typfile-fähig, das heißt man kann sich ziemlich einfach 
auch den Kartenstil ändern. Man kann sogar Karten von externen 
Datenträgern -> z.B. auf dem Garmingerät temporär einbinden und anzeigen 
lassen, natürlich nur die unverschlüsselten Karten. Geht sogar schneller 
als mit Basecamp selbst.


Meines Wissens ist es übrigens genau "ein" Entwickler, der das Programm 
entwickelt. Steht auch im "Über..." Splashscreen. :-)



--
Viele Grüße
Carsten

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

Re: [Talk-de] Luftbild-Versatz - Schachtdeckel

[christian.pietz...@googlemail.com]

Ich verstehe noch nicht, in welcher Situation sich dieser Gulli in
> unseren Daten an einer anderen Position als dieser befinden sollte?
>
> Es geht ja darum, die Gullis als Referenzpunkte zu nutzen. Da es aber sein
kann, dass jemand die Gullis verschiebt (weil er zum Beispiel den
Luftbildversatz nicht beachtet hat), muss man ja wissen wo der Gulli
wirklich ist. (Um ihn zum Beispiel automatisch wieder zurück verschieben zu
können)

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Alexander Lehner]

On Fri, 7 Feb 2014, Sven Geggus wrote:


hike39  wrote:


Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert
werden?


Das Problem ist nicht die Onlinenutzung, das Problem ist der Massenhafte
Kacheldownload, dennd er zerstört das Konzept des on demand rendering.

Ich verwende für meine Tourenplanung (Fahrrad und Wandern) das Programm
Viking. Das lädt wie ein Browser Kacheln nur on Demand runter. Sowas darf
IMO nicht geblockt werden.

Als Admin von tile.openstreetmap.de ist mir aber insbesondere "locus" auch
schon negativ aufgefallen. da werden tiles nicht nur on demand geladen
sondern massenhaft untergeladen.


tangoGPS bzw. foxtrotGPS machen das ebenfalls so (Region auswaehlen, 
angeben bis zu welcher Zoomstufe man tiles runterladen will).


Ich nutze diese Programme sehr gern auf meinem 'Smartphone', weil die 
fertig gerenderten Karten einfach schoener sind als die lokal gerenderten.
Zu Hause die Kacheln runterladen und beim Mountainbiken im Wald, wo's kein 
UMTS gibt, hat man die Karten parat. Ist schon nett.


@Sven: Worin besteht das Problem des On-Demand Rendering bei 
Massendownloads? Da kenne ich den Mechanismus dahinter zu wenig.

Ist das bei openstreetmap.org genauso?

Die Datenmenge kann es wahrscheinlich nicht sein, das sind 100-400MB, die 
laedt man sich einmal im Vierteljahr runter und gut ists.


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo hike39,

Am 07.02.2014 15:01, schrieb hike39:
> Hallo zusammen, ich nutze für die Planung meiner Wanderungen
> QLandkarteGT. Tolles Produkt, das die ganze Zeit wunderbar
> funktioniert hat. Nun mußte ich gestern feststellen, dass die OSM
> Kacheln nicht mehr angezeigt werden.
> 
> In dem Forum von QLandkarteGT mußte ich dann feststellen, dass ich
> nicht der einzige bin, der dies festgestellt hat. Eine Nachfrage
> ergab dann den Hinweis, dass die Mapnik Administration das Abrufen
> der Tiles durch QLandkarteGt abblockt.

Warum nutzt du nicht Offline-Karten in QLandkarteGT? QLandkarteGT kann
Karten im Garmin-Format lesen. Manche Anbieter von Garmin-Karten
bieten ihre Karten gleich in einem QLandkarteGT-kompatiblen Format an,
z.B.

Freizeitkarte: http://freizeitkarte-osm.de/de/
OpenMTBmap, Velomap: http://openmtbmap.org/de/tutorials/qlandkartegt/

> Christoph Bledl schrieb:
>> But the strength they (the mapnik tile administrators) enforce
>> their policy. qlandkartegt, at least in some versions, is
>> currently blocked there. ... My longer statement not everybody
>> agrees with can be found here:
> 
> 
> Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen,
> dass OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch
> blockiert werden?

Bei OsmAnd ist die Nutzung von Offline-Karten IMHO üblich.

Viele Grüße

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS9Sa7AAoJEB87G9rMCMyIk+oQAKrMX9h3odtawiv6UDmmd9fJ
mpLJQBVQlU2QAqnkgeloUK8YPhu1ClTz4ZtJIT4ZVevRz7UuHrBKrMffTSSG1mAn
4hE1Hivh45Q1GD269Hdt3kyp83mS3Tj2QauGa9BXlulejnT2ok0B+ylj1n+EmHSv
+wnbtx1Y++bmg5zwfcDIocANN4QW1+tSBjzXmqiG8T0sOc8TjZyCOC9rPuyauzZL
/dlSZQPokFt4h6TAe7NLdKdVAZNHy3SF6CXlvgg1eoqIZBHU1BBvWYOFuM3YJ/W5
AxmU0UF3LidFt2byEmNr8A8sgAxAftETXqzJEkzDUjM/Hg3a6G345Rf1xqP8MYLA
NZbMB9TqTJm6+DGVGJm5FuK8Z3zIRgKW8k8kJIUmNh8BTs0bgI9x7B4/AFvN9swp
nX5rMypfWBBbLgp3vckevdUe/5/R3iLbj8KR0M3CsaXP+AGc4VXwbgK8Iefg8H4Q
VMehN7x9z96gjxinEnpCCqmZulxUP88b554bEb7uoDWTxnFkGcavFiGn5KsyfFVO
pMPwUrwi2IygbpWLQp82WkB85nbhasABobII6hzksG0/RN5HJU1MuC2vbkLpDHyO
pAFDcaqdpuelbYwDzjxZSvJc95GwEcvlfiiW6gQ5gnfdCn7l3kAffRizTgpiqN9i
pOENJPVRgSYje20X/OGU
=jK8I
-END PGP SIGNATURE-

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Sarah Hoffmann]

On Fri, Feb 07, 2014 at 03:01:58PM +0100, hike39 wrote:
> ich nutze für die Planung meiner Wanderungen QLandkarteGT. Tolles
> Produkt, das die ganze Zeit wunderbar funktioniert hat. Nun mußte ich
> gestern feststellen, dass die OSM Kacheln nicht mehr angezeigt werden.
> 
> In dem Forum von QLandkarteGT mußte ich dann feststellen, dass ich nicht
> der einzige bin, der dies festgestellt hat. Eine Nachfrage ergab dann
> den Hinweis, dass die Mapnik Administration das Abrufen der Tiles durch
> QLandkarteGt abblockt.
> 
> Christoph Bledl schrieb:
> > But the strength they (the mapnik tile administrators) enforce their
> > policy. qlandkartegt, at least in some versions, is currently blocked
> > there.
> > ...
> > My longer statement not everybody agrees with can be found here:
> 

Wie diese Mail richtig beschreibt, wurde nicht QLandkarteGT speziell
geblockt, sondern alle Requests, die keinen oder einen gefakten
User-Agent geliefert haben. Diese Requests stammen hauptsächlich
von Tile-Scrapern und machen einen grossen Teil der Last aus.
Nötig geworden war das Sperren, weil die Server wegen Hardware-Problemen
nicht die volle Last fahren konnten und der Service aber für die
Website erhalten bleiben sollte. QLandkarteGT war da wohl eher
Kolleteralschaden, an dem es aber selbst schuld war, weil es sich
eben nicht an die Nutzungsbedingungen gehalten und einen vernüftigen
User-Agent geschickt hat. 

Wirklich traurig ist, das die Entwickler von QLandkarteQT
es vorziehen, die Situation zu verschlimmern, indem sie von einem
etwas wengier gefakten zu einem mehr gefakten User-Agent wechseln. 
An deiner Stelle würde ich mich nach einer Alternative umsehen.

> Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
> OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert werden?

Das kann durchaus passieren. Die Kapazität der OSM-Server ist nun 
mal begrenzt und obwohl sich die Admins bemühen, das beste aus
der bestehenden Hardware herauszuholen, gibt es einfach Grenzen.
Das massenhafte Herunterladen von Tiles für die Offline-Nutzung 
wurde noch nie gerne gesehen, weil es eine Menge unnötige Last
erzeugt, und sollte es wieder zu Engpässen auf dem Server kommen,
müssen weitere Scraper damit rechnen, gesperrt zu werden.

Zum Glück bieten ja wenigstens einige der Apps gute Offline-Vektordaten
an, mit denen man böse Überraschungen verhindern kann.

Gruss

Sarah

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

[Talk-de] Wie mapped man eine lange Steinreihe ...

[Bernhard Weiskopf]

… wie zum Beispiel 

http://www.panoramio.com/photo/38961921 

oder 

http://www.panoramio.com/photo/38962124

 

barrier = ?

 

Gruß Bernhard

 

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

Re: [Talk-de] Wie mapped man eine lange Steinreihe ...

[Falk Zscheile]

2014-02-07 Bernhard Weiskopf :
> ... wie zum Beispiel
>
> http://www.panoramio.com/photo/38961921
>
> oder
>
> http://www.panoramio.com/photo/38962124
>
>
>
> barrier = ?
>
>
Das Probelem ist nicht neu, möglicherweise aber immer noch ungelöst.
Du scheinst ja etwas zu suchen, dass eine (historische) Panzersperre
beschreibt ...:

https://www.mail-archive.com/talk-de@openstreetmap.org/msg78182.html

Gruß Falk

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

Re: [Talk-de] Wie mapped man eine lange Steinreihe ...

[Bernhard Weiskopf]

Danke für die Info, aber für echte Panzersperren sind die Steine zu klein,
da irrt der Fotograf in Panoramio wahrscheinlich. Das sind eher Hindernisse
für Kraftfahrzeuge, sie stehen im Wald in der Nähe einer ehemaligen Kaserne
in Mannheim-Käfertal. Sie stehen mehr oder weniger weit von Straßen und
Waldwegen entfernt.

Gerade die etwas abseits stehenden Steinreihen (sie sind mehrerer 100 m
lang) könnten man gut als Orientierungshilfe nehmen, wenn man nicht auf
Wegen durch den Wald geht und manche Wege existieren inzwischen auch nicht
mehr.

http://goo.gl/maps/iz9Q2 zeigt eine andere Reihe in der Nähe mit gleich
großen Steinen neben einer Landstraße. Die gleichen Steine wurden auch als
einzelne Sperrsteine gesetzt beim Abbau einer Bahnlinie, damit keine
Kraftfahrzeuge auf der Trasse in den Wald fahren. Die Steine wurden
schätzungsweise um 1930 bis 1960 errichtet.

Bernhard

> Von: Falk Zscheile [mailto:falk.zsche...@gmail.com]
> Gesendet: Freitag, 7. Februar 2014 20:29
> An: Openstreetmap allgemeines in Deutsch
> Betreff: Re: [Talk-de] Wie mapped man eine lange Steinreihe ...
> 
> 2014-02-07 Bernhard Weiskopf :
> > ... wie zum Beispiel
> > http://www.panoramio.com/photo/38961921
> > oder
> > http://www.panoramio.com/photo/38962124
> >
> > barrier = ?
> >
> Das Probelem ist nicht neu, möglicherweise aber immer noch ungelöst.
> Du scheinst ja etwas zu suchen, dass eine (historische) Panzersperre
> beschreibt ...:
> 
> https://www.mail-archive.com/talk-
> d...@openstreetmap.org/msg78182.html
> 
> Gruß Falk





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

Re: [Talk-de] Wie mapped man eine lange Steinreihe ...

[Falk Zscheile]

Dann versuche es doch mal mit barrier=block, dass scheint dem Ganzen
am nächsten zu kommen.

Gruß Falk

Am 7. Februar 2014 20:52 schrieb Bernhard Weiskopf :
> Danke für die Info, aber für echte Panzersperren sind die Steine zu klein,
> da irrt der Fotograf in Panoramio wahrscheinlich. Das sind eher Hindernisse
> für Kraftfahrzeuge, sie stehen im Wald in der Nähe einer ehemaligen Kaserne
> in Mannheim-Käfertal. Sie stehen mehr oder weniger weit von Straßen und
> Waldwegen entfernt.
>
> Gerade die etwas abseits stehenden Steinreihen (sie sind mehrerer 100 m
> lang) könnten man gut als Orientierungshilfe nehmen, wenn man nicht auf
> Wegen durch den Wald geht und manche Wege existieren inzwischen auch nicht
> mehr.
>
> http://goo.gl/maps/iz9Q2 zeigt eine andere Reihe in der Nähe mit gleich
> großen Steinen neben einer Landstraße. Die gleichen Steine wurden auch als
> einzelne Sperrsteine gesetzt beim Abbau einer Bahnlinie, damit keine
> Kraftfahrzeuge auf der Trasse in den Wald fahren. Die Steine wurden
> schätzungsweise um 1930 bis 1960 errichtet.
>
> Bernhard
>
>> Von: Falk Zscheile [mailto:falk.zsche...@gmail.com]
>> Gesendet: Freitag, 7. Februar 2014 20:29
>> An: Openstreetmap allgemeines in Deutsch
>> Betreff: Re: [Talk-de] Wie mapped man eine lange Steinreihe ...
>>
>> 2014-02-07 Bernhard Weiskopf :
>> > ... wie zum Beispiel
>> > http://www.panoramio.com/photo/38961921
>> > oder
>> > http://www.panoramio.com/photo/38962124
>> >
>> > barrier = ?
>> >
>> Das Probelem ist nicht neu, möglicherweise aber immer noch ungelöst.
>> Du scheinst ja etwas zu suchen, dass eine (historische) Panzersperre
>> beschreibt ...:
>>
>> https://www.mail-archive.com/talk-
>> d...@openstreetmap.org/msg78182.html
>>
>> Gruß Falk
>
>
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] Wie mapped man eine lange Steinreihe ...

[rgx]

Am 07.02.2014 23:19, schrieb Falk Zscheile:
> Dann versuche es doch mal mit barrier=block, dass scheint dem Ganzen
> am nächsten zu kommen.

Wäre als Attribut für einen Linienzug (way) nicht die Mehrzahl besser?

Es gibt ja auch z.B.

building=garage vs. landuse=garages
natural=tree vs. natural=tree_row

Das müsste aber erst als Antrag vorgeschlagen werden...
Aber schauen wir doch mal auf

http://wiki.openstreetmap.org/wiki/DE:Key:barrier

Anders als bollard (ginge zur Not vielleicht auch mit bollard:type?)
ist v=block nur für Punktobjekte (nodes) vorgesehen:

Es gibt laut Statistik aber auch 1500 Fälle für linienhafte Objekte
(ways). [1]

Diese interessanten Vorschläge von 2012 helfen dir sicher auch nicht
weiter (es sei denn du möchtest nun selbst einen Vorschlag machen):

http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types
http://wiki.openstreetmap.org/wiki/Proposed_features/Stone_Wall


Auch die fence-Typen decken diesen Fall nicht ab:
http://wiki.openstreetmap.org/wiki/Proposed_features/Fence_attributes

Neu gebräuchliche Barrierentypen werden unter
http://taginfo.openstreetmap.org/keys/?key=barrier#values
aufgeführt und tw. erläutert:

Am Ende würde ich auch
[1] http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dblock
nehmen...

Gruß
Ralf
-- 
PGP/GnuPG: pub 1024D/E6DE0971

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

Re: [Talk-de] Luftbild-Versatz

[rgx]

Hallo, die rege Diskussion freut mich, vor allem,
dass mein Vorschlag mit den unverrückbaren Referenzpunkten so
viel Resonanz erntet...

Am 28.01.2014 12:15, schrieb Caronna:
> Landvermessungspunkte? Stimmen zu 100% (fallls es 100% überhaupt in
> diesem Bereich gibt, schließlich wandert auch die Erdkruste)
> Triangulationspunkte gibt es überall, und nur die sind verläßlich -
> sollten also eingetragen werden (gibts dafür ein Tag?)

Das wäre schon einmal eine Maßnahme, jedoch sind die im Gelände
selten und vermutlich kaum sichtbar. Dann könnten wir noch
das Gradnetz als virtuelles Raster mappen.

Schon jetzt gibt JOSM ja eine Warnung, wenn ich versehentlich
ganze Straßenzüge verschiebe (Du hast eine große Zahl an
Punkten zu verschieben versucht - ist das dein Ernst?, oder so).

Ebenso dachte ich an wichtige Knotenpunkte (daher Kreuzungen), die
eine Warnung erzeugen, wenn sie um sagen wir mehr als N Meter
verschoben werden, wobei N die vorgeschlagene Genauigkeit ist,
die als Attribut angegeben werden müsste.

Also etwa so
fixed=yes
fixed:radius=5  // darf max. um 5 Meter verschobenwerden, sonst
wird eine Warnung ausgespuckt.

Oder
approved=yes   // Lage wurde bestätigt
precision=5

Dass beliebige Wegpunkte sich hierfür nicht eignen folgt nach meiner
Erfahrung daraus, dass nach und nach bislang recht eckige
Straßenverläufe mit der Zeit geglättet werden, indem neue Wegpunkte
eingefügt werden. Dabei kann es durchaus passieren, dass Punkte
einer Landstraße um mehrere Dekameter wandern, was semantisch keinen
Unterschied macht. Solange Straßen aber als einfache Streckenzüge
(ohne Trasse oder Spuren usw.) gemappt werden, sind m.E. Kreuzungen
bis auf 5-10 Meter eindeutig.

Aber möglicherweise ist es einfacher, die Satellitenbilder zu
entzerren und deren geschätzte Genauigkeit sozusagen auf dem
Amaturenbrett (bzw. im Display) z.B. als Farbbalken deutlich
anzuzeigen...

Gute Nacht
Ralf


-- 
PGP/GnuPG: pub 1024D/E6DE0971

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

Re: [Talk-de] Luftbild-Versatz

[rgx]

Am 30.01.2014 07:41, schrieb christian.pietz...@googlemail.com:
> Vielleicht stören sich die Leute einfach am Wort gesperrt.

Hallo: Besser also: fixiert (fixed), bestätigt (approved)?

> Die Problematik betrifft jedoch nicht nur Vermessungspunkt. Wichtig sehe
> ich das zum Beispiel auch beim indoor-mapping (bitte kein Diskussion, ob
> sinnvoll oder nicht xD). Wenn ich ein Gebäude mit Räumen und allem drum und
> dran habe, wäre es gut, wenn man das alles gemeinsam "verankern" (das ist
> ein gutes Wort) kann.

Das hört sich eher nach "gruppieren" an (vgl. Vektorzeichenprogramme).
Ich denke, das ist illusorisch für JOSM.

Ciao
Ralf
-- 
PGP/GnuPG: pub 1024D/E6DE0971

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

Re: [Talk-de] Luftbild-Versatz - Schachtdeckel

[rgx]

Am 07.02.2014 14:47, schrieb chris66:
> Es fehlt noch der Zeitpunkt der Verankerung, da die Koordinaten ja mit
> der irren Geschwindigkeit von 2 cm pro Jahr Richtung Nordost wandern
> in Europa.

Die Koordinaten als zusätzliches Tag wären redundant.
Genau hier würde das Fixieren (oder Pinnen) greifen:

User A ist sich sicher und tagged zusätzlich: fixed=yes (oder
pinned=yes) ggf. unter der Auflage, die Quelle für diese
Information angeben zu müssen (und dass nicht mehr als N fixierte
Punkte je Änderungssatz hochgeladen werden dürfen).

Wenn nun User B den Gullideckel verschieben will, erhält er eine
Nachfrage (Punkt fixiert, sicher?). Falls er dann bestätigt,
wird das fixed (pinned) - Tag entfernt.

Ein weitere Vorteil ist, dass man gezielt nach bewegten
Fixpunkten suchen könnte.

Gullideckel sind demnach eine gute Sache - allerdings frage ich
mich, ob diese als Bestandteil der Straßenlinie gemappt werden
sollen - oder mal rechts mal links (z.B. bei kreuzenden
Kanälen, bei denen natürlich in Wirklichkeit die Deckel von
der einen Straßenseite zur anderen verlaufen)

Viele Grüße
Ralf

-- 
PGP/GnuPG: pub 1024D/E6DE0971

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

[Frederik Ramm]

Hi,

On 07.02.2014 16:23, pmsg wrote:
> 1) Ein eigener Tile-Server betreiben. Das kommt für mich aufgrund des
> Aufwandes zur Zeit nicht in Frage.

Wenn Du mit Linux oder Windows unterwegs bist, dann kannst Du auch
"Maperitive" benutzen. Solange der Bereich, für den Du dich
interessierst, nicht so gross ist, ist das ziemlich einfach: An die
gewünschte Stelle zoomen, Daten von Overpass runterladen,
Tile-Generierung anschalten (von Zoom X bis Zoom Y), und schon hast Du
ein Verzeichnis voller Tiles. Das ist dann nicht 100% der OSM-Stil, aber
eine gute Näherung.

Maperitive hat halt die Einschränkung, dass immer alle Daten in RAM
gehalten werden. Die nächstgrößere Lösung heißt dann TileMill mit
Original-OSM-Style und einer PostGIS-Datenbank - das ist immer noch
simpler als der "eigene Tile-Server", und es gibt auch da eine
Exportmöglichkeit für Tiles, aber den Datenbank-Installations-Aufwand
hast Du halt schon.

Bye
Frederik

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

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

Re: [Talk-de] St.-ZickeZacke-Str.

[rgx]

Am 07.02.2014 09:49, schrieb Manuel Reimer:
> Mag ja sein. Dennoch finde ich es nicht praktikabel beim Übertragen in ein
> Navi (zumindest mein Garmin im Auto hat Sprachausgabe) das "Dr." erst
> automatisch nach "Doktor" übersetzen zu müssen. Ich will zumindest nicht,
> dass mein Navi mir die Abkürzung vorliest. Und ein Navi ist eben kein Mensch
> der bei "Dr." unterbewusst schon "Doktor" liest.

Das ist für mich ein Gegenargument, Dr. auszuschreiben: Denn wenn es nur
um Phonetik geht, bräuchte das ein eigenes Tag, in dem dann z.B.
"Haustormäuschenstraße" als "Haus-Tor-Mäus-chen-Shtrasse" (phonetisch)
steht, damit mein billiges Navi nie wieder so etwas wie "Hauschtormau-
SchensTraBe" von sich gibt...

Straße würde ich auf jeden Fall ausschreiben. Wie werden Straßennamen
die mit Dr. oder St. beginnen in alphabetischen Straßenverzeichnissen
einsortiert? Unter Dok../San..? Oder unter Dr./St.?

-1

-- 
PGP/GnuPG: pub 1024D/E6DE0971

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