On 01.09.2011 08:19, Michael Kugelmann wrote:
On 31.08.2011 10:44, Nick Whitelegg wrote:
I would go so far as to say, don't delete *anything* until legally
you absolutely have to.
I would like to somehow modyfy this statement: we should replace the
data not delete it! So please remap the
On 07.08.2011 22:30, Joerg Fischer wrote:
Chris66 wrote:
ich mach das so, dass ich die Option --link-pois-to-ways nutze und im
polygon-file shop=* auf Gebäude umsetze:
shop=* [0x13 resolution 24]
Und das funktioniert _wenn Du vorher die Gebäude via
--delete-tags-file gelöscht hast_? Das
On 11.07.2011 13:48, M∡rtin Koppenhoefer wrote:
2011/7/9 Felix Hartmannextremecar...@gmail.com:
As we're
still under CCBYSA 2.0, people can use it to trace rivers and trails to OSM
:-)
while the data is still distributed under cc-by-ca you cannot enter
data any more in cc-by-sa only
http://www.topopirineos.blogspot.com/
This map is using Openstreetmap Data for main roads, but lots of other
stuff too. Attribution is not really given correctly, but somehow a bit.
As we're still under CCBYSA 2.0, people can use it to trace rivers and
trails to OSM :-)
or might we
Aus genau den Gründen, ist class:bicycle einfach besser. Das kannst ja
genauso als Netzwerk aufbauen, noch dazu als intelligentes Netwerk, dass
sich ergibt...
On 28.05.2011 21:05, Friedrich Volkmann wrote:
On 05/28/11 18:10, Markus Straub wrote:
ich würde gerne wissen was ihr vom Taggen von
On 25.05.2011 12:07, Garry wrote:
Am 24.05.2011 17:40, schrieb Torsten Leistikow:
Garry schrieb am 24.05.2011 17:09:
In die eine Richtung ist es eine Detailverbesserung, in die andere
würde
sicher nicht nur ich es als Vandalismus
ansehen...
In beiden Richtungen wird Information zerstoert,
On 24.05.2011 10:07, Wolfgang wrote:
Hallo,
Am Montag 23 Mai 2011 19:16:16 schrieb Bjørn Bäuchle:
Oder soll man die Trasse taggen? Dafür könnte man dann vlt
landuse=railway_corridor benutzen. Fang gerne an damit, und wenn sich
das durchsetzt, spricht ja nichts dagegen, dass die Renderer bei
On 23.05.2011 12:43, M∡rtin Koppenhoefer wrote:
Am 23. Mai 2011 02:26 schrieb Felix Hartmannextremecar...@gmail.com:
Ich bin mir sicher, dass es einfacher wäre, die abstrakteren Level
up-to-date zu halten. Fakt ist derzeit kann man aus OSM Daten keine
vernünftige Weltkarte rendern. Auf
On 22.05.2011 22:47, Bjørn Bäuchle wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Thorsten,
Am 22.05.2011 19:01, schrieb Torsten Leistikow:
Ich habe ja auch nichts gegen die Detail-Erfassung, aber warum konnte
dafuer nicht ein neues Tag genommen werden? Ein Gleis ist nun mal was
-- Weil etwa eine Zugverbindung nicht alle Gleise benutzt, sondern
wie genereller Verkehr, nur bestimmte Gleise der Bahnstrecke
(Bahnstrecke gleich die Zusammenfassung aller Einzelgleise). Sprich
nur weil man Sachen einzeln mappt, wird es nicht korrekter. Karten
sind Abstrakte der
Naja, die Daten stehen unter CCBY 3.0.
Sprich mit der neuen odbl Lizenz samt Terms nicht vereinbar. Wer sich
entscheidet denen eh nicht zuzustimmen, der kann sie natürlich benutzen
On 17.05.2011 13:49, Andreas Trawoeger wrote:
Auf zum gemeinsamen Datenschmökern :-)
cu andreas
Schön wäre es wohl, schnell eine Lösung für das Multilane-Problem zu
finden und in den Editors Relationen noch benutzerfreundlicher (Newbies)
zu machen. Nebenbei könnten wir ja noch das Area-Problem lösen.;)
Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und
dann alle Lanes
On 05.05.2011 16:54, M∡rtin Koppenhoefer wrote:
Am 5. Mai 2011 16:29 schrieb Felix Hartmannextremecar...@gmail.com:
Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und dann
alle Lanes (egal ob jetzt Bordstein oder Fahrradweg) mit relativer
Entfernung dazu. Bei Kreuzungen dann
On 05.05.2011 18:29, M∡rtin Koppenhoefer wrote:
Am 5. Mai 2011 18:20 schrieb Felix Hartmannextremecar...@gmail.com:
On 05.05.2011 16:54, M∡rtin Koppenhoefer wrote:
Am 5. Mai 2011 16:29 schrieb Felix Hartmannextremecar...@gmail.com:
Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu
On 05.05.2011 20:00, M∡rtin Koppenhoefer wrote:
Am 5. Mai 2011 19:05 schrieb Felix Hartmannextremecar...@gmail.com:
Doch es reicht um die Form abzubilden. Es braucht nur die enstprechenden
Tags dafür. Straßen, Krezungen, und Bordsteine haben es an sich vom Menschen
am Reißbrett geplant zu
Why not setup a Wave server, using google Wave software. It's open
source, and really efficient for real time as well as non real time
communication. Alternative a google server could be used, but then it is
just like other proprietary tools (though based on opensource software).
Unterscheidung, von daher ist ein in Deutschland nicht angebracht.
Sie unterscheiden sich durch die An- bzw. Abwesenheit der Straße.
Mit dem Argument unterscheiden sich Wanderwege mit immer wieder
lockerem
Sandboden und geteerte Wanderwege durch den Belag und sollten dann
nicht
beide mit dem
On 04.05.2011 14:24, Georg Feddern wrote:
Moin,
Felix Hartmann schrieb:
Und du verlierst durch den eigenständigen Weg, die Information, dass
der Weg entlang einer stark befahrenen Straße geht, außer du legst
nun für jeden Bordstein, eine Relation zur Straße.
nun, diese Eigenschaft ließe
On 04.05.2011 16:01, Peter Wendorff wrote:
Am 04.05.2011 12:58, schrieb Felix Hartmann:
Unterscheidung, von daher ist ein in Deutschland nicht angebracht.
Sie unterscheiden sich durch die An- bzw. Abwesenheit der Straße.
Mit dem Argument unterscheiden sich Wanderwege mit immer wieder
On 04.05.2011 16:20, Peter Wendorff wrote:
Am 04.05.2011 15:45, schrieb Felix Hartmann:
und bei jeder Querstraße Ampeln sind, die die Geschwindigkeit
mindern (bzw fehlen uns halt Möglichkeiten, Grüne Wellen zu
taggen - im Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für
Fußgänger
On 04.05.2011 16:33, Peter Wendorff wrote:
Am 04.05.2011 16:13, schrieb Felix Hartmann:
Was hilft es, Abgase ausschließen zu können, wenn die Mülldeponie
stattdessen stinkt?
Solange du das also nicht auch noch an den Fußweg pappen willst
(Achtung, Mülldeponie in der Nähe!), hast du damit
On 04.05.2011 11:14, m5st wrote:
Hallo!
Ich habe jetzt eine Auswertung gemacht um die plan.at-Mapper etwas
anzuspornen. Ausgewertet werden folgende tags:
*note=imported from plan.at
*fixme=check import
*at:maxspeed
Ausgwertet wird das Geofabrik-Extrakt.
Die derzeitige Statstik:
Datum:
On 03.05.2011 10:09, Thomas Davie wrote:
On 3 May 2011, at 08:57, Jaak Laineste wrote:
Hello,
It looks like trivial suggestion, but could not find any past
discussions with quick search.
Is there good reason to add addr:country, addr:county, addr:city and
other regional tags to all the
The biggest problem we have is that were not important enough and too
cluttered to attract in map adverts yet.
I think in the long run, it's not about adverts around the map, but ads
in the map (of course the database should be advert free). Als our maps
are still mainly for looking at,
On 04.05.2011 00:05, Henning Scholland wrote:
Am 03.05.2011 23:37, schrieb Felix Hartmann:
On 03.05.2011 23:27, Minko wrote:
Yes, that is also a good alternative, 0x01 as a transparent line and
on top either
0x10f01 or 0x10f02
you cannot make a line transparent by omitting it from
Genau das sage ich ja. Daher will ich keine odbl. Ausserdem gehts wie
gesagt gar nicht um Garmin, sondern um Vektorkarten im allgemeinen.
Und hier versagt die odbl kläglich, weil nicht klar ist was eine
Datenbank ist, bzw was Vektorkarten sind.
Ich hab doch aber gerade auf ca. 100 Zeilen
On 30.04.2011 10:48, Simon Poole wrote:
Die Regel ist eigentlich klar: Produced Work ausser es wurde zum
Zwecke gemacht die Bestimmungen in der ODbL zur Datenbank zu umgehen.
Da das bei einer Garminkarte eigentlich nicht so ist (sprich Geometrie
hat man, den Rest eigentlich nur grob,
On 30.04.2011 15:51, Henning Scholland wrote:
Am 30.04.2011 14:11, schrieb M∡rtin Koppenhoefer:
Am 30. April 2011 13:41 schrieb Henning Schollando...@aighes.de:
WIe bereits in der anderen Mail angedeutet kann man mit etwas
Bilderkennung
und Rechenpower auch aus einem jpg die Daten wieder
On 30.04.2011 15:59, Henning Scholland wrote:
Am 30.04.2011 14:52, schrieb Frederik Ramm:
Das ist von der Logik her nicht ganz leicht zu begreifen, weil man
immer denkt: Wenn die DVD erstmal ihr Share-Alike verloren hat, dann
kann das ja nicht wieder zurueckkommen. Kann es aber doch. Das ist
On 30.04.2011 16:57, Bodo Meissner wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 30.04.2011 01:22, schrieb Felix Hartmann:
Das würde mit CCBYSA und dem DRM verbot durchs Share Alike halt anders aussehen.
Glaube ich nicht.
Ich könnte das übersehen haben, weil die vollständigen
On 29.04.2011 12:32, Ulf Lamping wrote:
Am 21.04.2011 09:59, schrieb Frederik Ramm:
Hallo Kai,
On 04/21/11 04:23, Kai Krueger wrote:
Mit ODbL muss ich nun mir ueberlegen ist es ein Produced Work oder
nicht?
Wenn es eine Datenbank ist, ist es eine Datenbank, und ansonsten ist es
ein
On 29.04.2011 19:32, Frederik Ramm wrote:
Hallo,
Felix Hartmann wrote:
Also auf, damit dass kein Einzelfall bleiben muss, sondern Regel
wird, helft alle kräftig mit und spammt die odbl Ablehner zu. An die
CCBYSA 2.0 halten sich die odbler ja eh schon länger nicht mehr.:-*
Ich hatte Dich
On 29.04.2011 20:42, Frederik Ramm wrote:
Hi,
Henning Scholland wrote:
Kann man es denn irgendwo Schwarz auf Weiß lesen, dass eine
Garmin-Karte keine Datenbank im Sinne der Lizenz ist?
Nein - weder, dass sie keine ist, noch dass sie eine ist. Ich hatte ja
gesagt, dass das noch so ein
On 29.04.2011 22:34, Simon Poole wrote:
Am 29.04.2011 21:57, schrieb Felix Hartmann:
Es geht hier aber um viel mehr, als nur Garmin Karten. Wenn es keine
Datenbank ist, bedeutet dass, auf allen GPS/Smartphones etc. können
kostenpflichtige, und nicht weiterbreitbare Vektorkarten angeboten
On 29.04.2011 23:31, Frederik Ramm wrote:
Hallo,
Felix Hartmann wrote:
Das ist leider nicht besonders hilfreich. Ich denke, der Fall
Garmin-Karte muss da noch genauer diskutiert werden. Ich neige
eigentlich eher zu der Interpretation, das eine Garmin-Karte keine
Datenbank im Sinne der ODbL
On 18.04.2011 13:54, Heiko Jacobs wrote:
Am 18.04.2011 11:47, schrieb M∡rtin Koppenhoefer:
Andererseits ist das wohl ein Spezialtag der Pufferküsser, wo man
evtl. davon ausgehen kann, dass das nur von Leuten verwendet wird, die
die rechtliche Definition kennen. Ob das so ist, könnte man z.B.
On 18.04.2011 17:56, M∡rtin Koppenhoefer wrote:
Am 18. April 2011 17:35 schrieb Felix Hartmannextremecar...@gmail.com:
Wobei
am besten wäre es, wenn man klar definiert dass man Relationen benutzt, und
die Relation immer nur auf EIN (möglichst mittiges) Gleis legt (falls die
Gleise seperat
On 18.04.2011 18:00, Heiko Jacobs wrote:
Am 18.04.2011 17:35, schrieb Felix Hartmann:
On 18.04.2011 13:54, Heiko Jacobs wrote:
Die reale Verkehrsbedeutung abseits der amtlichen Einteilung in Haupt-
und Nebenbahn kann man anders viel besser erfassen als über usage.
Linien als Relationen zu
BTW. Es gibt ein European Agreement on Main International Railway Lines
(AGC) Das wäre ein guter Anhaltspunkt (wenngleich etwas von der
falschen Zugangsseite, da hier auf die Infrastruktur, und nicht die
tatsächliche Benutzung abgezielt wird - aber prinzipiell wird ja nichts
auf 300km/h
On 18.04.2011 18:36, M∡rtin Koppenhoefer wrote:
Am 18. April 2011 18:18 schrieb Felix Hartmannextremecar...@gmail.com:
Das sehe ich anders. Dann bräuchte es eben halt auch die Information, dass
man ein Gleis wegschmeißen kann. Das Problem von Fahrspuren, usw ist dass
Verdrängung nur bei
On 18.04.2011 20:25, M∡rtin Koppenhoefer wrote:
Am 18. April 2011 18:44 schrieb Felix Hartmannextremecar...@gmail.com:
Es geht nicht drum, dass die Gleise weggeschmissen werden. Sondern das in
den Daten steht, was man weglassen kann weil es ab einer bestimmten
Auflösung nicht mehr
Der Grund, warum man (ich) das bisher nicht braucht, ist dass sich das
beim Rendern von lowzoom sowieso von selbst löst (Überlagerung durch
die Überhöhung). Klar, man rendert auch viel, was man eigentlich nicht
sieht (könnte Rechenzeit und Strom sparen). Je nachdem, wie lange Du
den Datensatz
Irgendwie kommen mehr und mehr User drauf, die meinen usage=main würde
auch etwa für Schnellbahnstrecken (etwa die kaum benutzte Ostlinie in
Wien) gelten. Ich hab das im Wiki mal geändert, wäre aber eigentlich für
eine bessere Aufteilung wie nur usage=main // usage=branch. Ich denke
usage=main
On 16.04.2011 17:44, Heiko Jacobs wrote:
Am 16.04.2011 15:29, schrieb Felix Hartmann:
Irgendwie kommen mehr und mehr User drauf, die meinen usage=main
würde auch etwa für Schnellbahnstrecken (etwa die kaum benutzte
Ostlinie in Wien) gelten. Ich hab das im Wiki mal
geändert, wäre aber
On 26.03.2011 18:01, Stefan Hirschmann wrote:
wolfbert wrote:
Hallo Boris,
finde ich gut (Treffen), persönlich kommt man da besser voran, finde
ich.
Eigentlich reduziert sich das Ganze auf zwei Fragen:
1. Wollen wir eine solche Initiative jetzt starten?
Bitte eine Sache beachten:
Alle
Also ich sehe auch absolut keinen Bedarf für einen bicycle:trekking oder
was auch immer Tag.
Der Grund warum es mtb:scale sowie mtb:scale:uphill gibt, ist das
Mtbiken einfach keiner anderen Fortbewegungsart direkt entspricht, und
es eben Wege gibt, wo ein Wanderer nur auf allen 4en
Das ganze sollte area:highway=residential heißen, anstelle
higwhay=residential area=yes.
Ist nicht komplizierter, und würde für weniger Fehler sorgen. Und vor
allem wäre dann jedem klar, dass Routing auf area:highway nicht stattfindet.
___
Couldn't agree more to it. Imports kill community and scare novices away.
Austria two years ago was actually one of the best mapped countries for
the density of population. Much better in general than Germany or other
countries. Since we began importing plan.at community stopped to grow
and
On 21.02.2011 00:47, Daniel Sabo wrote:
On Feb 20, 2011, at 3:16 PM, Felix Hartmann wrote:
Couldn't agree more to it. Imports kill community and scare novices away.
...
Most important things for OSM are good aerial photos coupled with large community. Worst
are imports. The United States
On 14.02.2011 18:35, Andreas Tille wrote:
Ich halte eine Information an leicht zu findender Stelle für angemessen,
wenn ein Dienst der früher mal zur Verfügung stand für längere ( 2
Wochen) Zeit / unvorherbar lange Zeit nicht mehr zur Verfügung steht.
Ein Mangel an Information schadet dem
On 04.02.2011 20:44, Steffen Wolf wrote:
M∡rtin Koppenhoefer schrieb:
Wenn Dir die Information wichtig ist, dass es ein Fahrradweg in der
Nähe einer Straße ist, dann kann man das auch anders in den Daten
unterbringen.
beispielsweise, indem man das cycleway=track an den Fahrradweg selbst
On 03.02.2011 20:10, M∡rtin Koppenhoefer wrote:
Am 2. Februar 2011 22:32 schrieb Pascal Neispascal.n...@gmail.com:
bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem
mit Ways die ein cycleway=track-Tag besitzen aufmerksam
gemacht worden. (danke Sven :) )
Folgendes Problem: Darf ein Way
Im Prinzip nein. Allerdings ist es nicht korrekt durchdacht.
Besser cycleway=track (gleich in die Richtungen gebaut und befahrbar wie
die Straße), left (auf linker Seite), right, both
und dazu bicycle:oneway=no bzw bicycle:oneway=yes um vom oneway=yes //
oneway=no abweichende Regelungen der
On 07.01.2011 09:45, Christoph Wagner wrote:
Am 07.01.2011 02:00, schrieb Felix Hartmann:
Oder anders: Ich will nicht soviel RAM, aber da eben alle Kacheln auf einmal
eingelesen werden, wird zurzeit halt etwa Kachelgröße mal 1.2 an verfügbarem
Ram benötigt. Und wenn der Rechner hier zu
On 07.01.2011 15:03, Sven Geggus wrote:
Felix Hartmannextremecar...@gmail.com wrote:
Sehe ich nur sehr begrenzt so. Einerseits gibt es gerade bei den anderen
Typen große Unterschiede in der Benutzung, anderseits hat eh jeder ein
anderes Design.
Ich bin ja was Garminkarten betrifft nur
Was man eigentlich auch mal versuchen sollte anzugehen wäre die OSM
Typen halbwegs einheitlich auf Garmintypen zu mappen. Derzeit kann
man nämlich aufgrund dieser uneinheitlichen Umsetzung kaum sinnvoll
Typfiles anderer Garminkarten mir der AIO verwenden und umgekehrt.
Du verstehst hier
Hmm, ich gebe zu es wäre mir persönlich am liebsten, wenn sich um die
Styleerstellung komplett jemand anderes kümmert.
Die Typen kann man von mir aus mappen wie man will. Es gibt da leider bei
manchen Garmintypen auf manchen Geräten Probleme (komische Rauten oder weiß der
Geier...)
Ich hab
On 06.01.2011 16:05, Sven Geggus wrote:
Felix Hartmannextremecar...@gmail.com wrote:
Du verstehst hier irgendwas nicht. Es ist komplett egal wer was wie
verwendet. Es braucht eh jede Karte ihr eigenes Typfile. Sonst müsste
man eine komplett einheitliche Darstellung haben, da nicht genug
On 06.01.2011 18:51, Christoph Wagner wrote:
Am 06.01.2011 17:59, schrieb fla...@googlemail.com:
Wer Java installiert hat hat alles was er braucht. 1Ghz und 512MB Ram
sollten reichen.
Na wenn ich Felix richtig verstanden habe, braucht es etwas mehr RAM, wenn man
mit mkgmap den Adressindex
On 06.01.2011 23:37, fla...@googlemail.com wrote:
Klar, derzeit ist es nur bedingt brauchbar. Aber der komplette Code der
benötigt wird, ist hier online:
http://sourceforge.net/projects/cgpsmapper/
Da dies Sourcecode erst seit gut zwei Wochen online ist, wurde er bisher
noch nicht genutzt um
Die Anfrage alleine scheint mir schon Realitätsverweigerung, bzw
Unverständnis den Usern gegenüber zu sein. Da werdens wenige Trotteln
finden.
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
Ich denke, es ist tatsaechlich nicht boese, die nicht-relizensierten
Sachen neu zu erfassen, sondern notwendig.
Wenn so argumentiert wird, denke ich auch nicht, dass es boese ist, odbl
ja Sachen neu zu erfassen, und unter CCBYSA 2.0 exklusiv neu
einzustellen - nein nicht nur boese sondern
On 17.12.2010 22:15, Frederik Ramm wrote:
Hallo,
Felix Hartmann wrote:
Ich denke, es ist tatsaechlich nicht boese, die
nicht-relizensierten Sachen neu zu erfassen, sondern notwendig.
Wenn so argumentiert wird, denke ich auch nicht, dass es boese ist,
odbl ja Sachen neu zu erfassen, und
On 17.12.2010 20:48, Ulf Möller wrote:
Am 17.12.2010 20:18, schrieb Felix Hartmann:
Wenn so argumentiert wird, denke ich auch nicht, dass es boese ist, odbl
ja Sachen neu zu erfassen, und unter CCBYSA 2.0 exklusiv neu
einzustellen - nein nicht nur boese sondern notwendig!
Das ist nicht
On 09.12.2010 23:21, Felix Hartmann wrote:
Bin beim erstellen meiner Karten draufgekommen, dass die Karten um
gute 10% seit Datenstand Freitag Nacht auf Datenstand Mittwoch Nacht
gewachsen sind.
Ist das wirklich möglich? Normalerweise waren es nur 1-2% pro
Woche Wurde wirklich so viel
Burgenland, Niederösterreich (~95%) und Steiermark (~ 75%
hochaufgelöst), Oberösterreich (~ 85%) scheinen mir generell sehr gut zu
sein. In NÖ sind die Luftbilder großteils ident zu den Yahoo Bildern -
aber halt nur dort wo es diese gab. Dieselbe Qualität gibt es nun
flächendeckend (Auflösung
On 01.12.2010 13:59, Martijn van Exel wrote:
Adding source tags never hurts. I believe source=bing is what is sort
of agreed upon.
Is source=bing verified?
Else it is pretty bad to start mapping
___
talk mailing list
talk@openstreetmap.org
Dank Bing Bildern kann man (zumindest in Teilen) in den Alpen nun ja
ziemlich genau Informationen zur Topographie eintragen. Wichtig fände
ich dass es eine Übersichtsseite im Wiki gibt, wo genau detailliert all
diese Sachen zusammengefasst werden. Gibt es da schon was?
Was mir etwa fehlt
On 30.11.2010 17:17, Anthony wrote:
On Tue, Nov 30, 2010 at 10:53 AM, Robert Kaiserka...@kairo.at wrote:
Robin Paulson schrieb:
or am i missing a tag? do i need to tag parks, etc. with area=yes
foot=yes, access=yes or would that be a case of tagging for the
routing engine
Note that in some
On 30.11.2010 08:42, Fichtennadel wrote:
*hochkram*
2010/11/24 Fichtennadel:
Konsens der Diskussion war, in JOSM das Template für path
dahingehend zu ändern, dass in der Auswahlliste für sac_scale
nicht mehr die anscheindend falsch verstandenen textuellen
Beschreibungen
On 30.11.2010 11:38, Boris Cornet wrote:
Hallo!
Nachschlag zu meinem vorigen Posting:
Ich denke es wäre wirklich günstig, die Kategorie Weg zwischen dem
'normalen' Wanderweg und dem Klettersteig mit einem eigenen Tag zu
versehen.
Dank des LEO-forums hab ich auch den passenden Begriff
Eigentlich sollten man auch gleich die Werte von trail_visibility durch
0-5 austauschen. Da ist noch weniger Konsistenz zu erkennen (was alleine
schon daran liegt, dass die Beschreibungen im Wiki unbrauchbar sind)
___
Talk-at mailing list
Hallo,
Am Donnerstag 18 November 2010 14:55:25 schrieb M∡rtin Koppenhoefer:
halte ich für sinnvoll. Insgesamt ist zu viel Übersetzung in den
Presets m.E. eher schädlich, weil sie davon abhält, sich mit der
Bedeutung des tags auseinander zu setzen. Ich halte auch nichts von
Bundesstraße oder
On 21.11.2010 22:54, M∡rtin Koppenhoefer wrote:
Am 21. November 2010 22:41 schrieb Ulf Lampingulf.lamp...@googlemail.com:
Am 21.11.2010 20:13, schrieb Felix Hartmann:
So ich hab mal Beispielbilder bei Trail_visibility angefügt - wobei das
halt schwer ist. Weil eben eigentlich schon bei
On 21.11.2010 23:52, Ulf Lamping wrote:
Am 21.11.2010 23:00, schrieb Felix Hartmann:
Ich bin sofort dafür dass sie jemand austauscht. Da ich sie nicht falsch
finde, würde ich sie bis es bessere Bilder gibt, lieber drinnen lassen.
Ich bin schon mal ein bisschen durch die Gegend gewandert und
On 18.11.2010 08:15, Fichtennadel wrote:
2010/11/17 Felix Hartmannextremecar...@gmail.com:
sac_scale generell + trail_visibility
+1
Stimmt, ist mir auch schon aufgefallen. Die Wikiseiten könnten etwas
besser beschreiben und weniger bergerprobten eine besser
Einschätzung ermöglichen. Da hast
On 18.11.2010 09:24, Sven Geggus wrote:
Andreas Tilleandr...@an3as.eu wrote:
Für mich ist die Konsequenz, daß ich persönlich sac_scale im Harz gar
nicht verwende, denn letztlich wird auf allen path und track gewandert
und nirgends wäre etwas anderes als hiking wirklich sinnvoll.
Das ist
On 18.11.2010 10:54, Ulf Lamping wrote:
Am 17.11.2010 23:12, schrieb Felix Hartmann:
Mir fällt immer wieder auf, dass sehr viele User bei sac_scale bzw
trail_visibility einfach nur Schrott eintragen.
IMHO liegt das an den Werten und wie sie beschrieben sind, bzw noch
schlimmer dass sie eben
On 18.11.2010 08:56, Andreas Tille wrote:
On Wed, Nov 17, 2010 at 11:12:35PM +0100, Felix Hartmann wrote:
Mir fällt immer wieder auf, dass sehr viele User bei sac_scale bzw
trail_visibility einfach nur Schrott eintragen.
IMHO liegt das an den Werten und wie sie beschrieben sind, bzw noch
Mir fällt immer wieder auf, dass sehr viele User bei sac_scale bzw
trail_visibility einfach nur Schrott eintragen.
IMHO liegt das an den Werten und wie sie beschrieben sind, bzw noch
schlimmer dass sie eben im JOSM Preset übersetzt sind, aber sich viele
User scheinbar noch nie die Mühe gemacht
Wär es eigentlich möglich, nicht nur die Anzahl der keys darzustellen,
sondern bei Linien, auch noch die Anzahl der KM? Oder wäre das deutlich
mehr (Rechen-)Aufwand?
Bzw bei Flächen (wenn Länge der Linien nicht schwer implementierbar ist)
auch noch die Fläche insgesamt (wobei ich dies weniger
On 14.11.2010 15:32, Bodo Meissner wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 14.11.2010 01:21, schrieb NopMap:
Ich habe von Leuten gehört, die Schwierigkeiten
mit Mapsource 6.16.x haben
Ich zitiere aus Beiträgen in der Mailingliste map_auth...@yahoogroups.com :
The changes
On 14.11.2010 18:14, Jochen Topf wrote:
On Sun, Nov 14, 2010 at 05:15:30PM +0100, Felix Hartmann wrote:
Wär es eigentlich möglich, nicht nur die Anzahl der keys darzustellen,
sondern bei Linien, auch noch die Anzahl der KM? Oder wäre das deutlich
mehr (Rechen-)Aufwand?
Bzw bei Flächen (wenn
Ohne hier irgendjemand persoenlich attackieren zu wollen, frag ich mich
schon, warum Frederik sich so vehemenent dafuer einsetzt, ein
beschissenes Rendering zu verteidigen. Fuer mich kann da eigentlich nur
der Schluss kommen, dass Geofabrik hier selber bessere Karten
vermarkten/verkaufen
On 24.10.2010 20:39, Johannes Huesing wrote:
Felix Hartmannextremecar...@gmail.com [Sun, Oct 24, 2010 at 06:42:35PM CEST]:
[...]
Denn solange es keinen Schluessel fuer regionale, nationale,
internationale Bedeutung gibt, so lange kann ein Renderer einfach
auch nicht wissen, wie wichtig eine
On 14.09.2010 04:35, Johann H. Addicks wrote:
Am 14.09.2010 00:52, schrieb Felix Hartmann:
Das ganze ist soweit ich erkennen kann offboard. Am GPS sieht man nur
Rasterkarten (und selbst hier ist fraglich wie haeufig und fuer welche
Gegenden man die updaten kann).
Mangels UMTS oder anderer
On 14.09.2010 04:35, Johann H. Addicks wrote:
Am 14.09.2010 00:52, schrieb Felix Hartmann:
Das ganze ist soweit ich erkennen kann offboard. Am GPS sieht man nur
Rasterkarten (und selbst hier ist fraglich wie haeufig und fuer welche
Gegenden man die updaten kann).
Mangels UMTS oder anderer
On 14.09.2010 12:23, Frederik Ramm wrote:
Hallo,
Elmar Burke wrote:
auch ich muss mich erst mal bei dir bedanken, Frederik, ohne deine
Extrakte würde manches Experiment scheitern! Aber mir ist
aufgefallen, dass wenn ich zwei aneinander grenzende Regionen in
Osmosis zusammenfüge (in meinem
On 14.09.2010 18:07, Bernd Wurst wrote:
Hallo.
Am Montag 13 September 2010, 20:35:20 schrieb Frederik Ramm:
Was meint ihr, soll ich das Alpen-Extrakt mal der Realitaet anpassen?
Derzeit enthaelt das Extrakt einen Gutteil von Sueddeutschland, die
komplette Schweiz und halb Oesterreich.
Wenn
On 13.09.2010 18:59, Johann H. Addicks wrote:
Hallo,
wie ich auf
http://www.navigation-professionell.de/xplova-g3-gps-bike-computer-navigieren-mit-openstreetmap
lese kommt ein
Xplova G3 GPS Bike Computer mit einer lokal laufenden OSM-Navigation für Radler
heraus.
Pressmitteilung auf
On 04.09.2010 12:58, Sven Geggus wrote:
Felix Hartmannextremecar...@googlemail.com wrote:
Wobei mir noch nicht klar ist, warum ein style-file nicht mit CCBYSA
geschuetzt werden kann.
Weil das kein kreatives Werk im Sinne der CC-by-SA ist sondern wie
gesagt ein spezieller typ von Software
On 03.09.2010 14:02, Sven Geggus wrote:
Felix Hartmannextremecar...@googlemail.com wrote:
1. oder 3. wobei dass wohl Ansichtssache ist.
Ich würde da deutlich zwischen Typfile uns Style unterscheiden. Die mkgmap
styles sind ja letztlich lediglich logische Konvertierungsanweisungen von
On 03.09.2010 16:25, aighes wrote:
Hallo,
das NC verstehe ich schon. Felix will verhindern, dass andere seinen Style
nehmen und dann dank einer besseren Infrastruktur und besserer Finanzkraft
Geld mit seinem Style verdienen, er aber 2 Jahre Entwicklung rein gesteckt
hat.
Es geht nicht nur um
moeglichen Fall 1 unmoeglich.
Eventuell ist Felix sich nicht darueber im Klaren, dass eine
Garmin-Karte nach ODbL eine Datenbank ist und daher zwingend unter
ODbL lizensiert werden muss.
Doch, dies ist mir natuerlich schon klar. Wenn die Kartendaten unter
ODbl stehen, so muss auch eine Datenbank
was eingecheckt.
Jupp! Ich habe mir vorhin mal git log angeschaut und habe unter
anderem Festgetellt dass Felix die Lizenz seiner Stylefiles unter
eine NC Lizenz gestellt hat. Ich bin da ein wenig kritisch und möchte
erst mal beim FOSSGIS nachfragen ob solches Zeug auf den Server noch
OK geht, denn
On 02.09.2010 12:00, Sven Geggus wrote:
Felix Hartmannextremecar...@googlemail.com wrote:
Die Karten sind ja weitherhin CCBYSA 2.0 und dass soll auch so bleiben.
Die Style-Files sehe ich in Bezug auf odbl jedoch nicht mehr ein, als
CCBYSA wie bisher zu veroeffentlichen.
Was hat das mit der
moeglichen Fall 1 unmoeglich.
Eventuell ist Felix sich nicht darueber im Klaren, dass eine
Garmin-Karte nach ODbL eine Datenbank ist und daher zwingend unter
ODbL lizensiert werden muss.
Bye
Frederik
2. Trifft nicht zu.
1. oder 3. wobei dass wohl Ansichtssache ist. Sollte es so sein, dass
der
der neuen Lizenz veröffentlichen werde. So
lange keiner auf die Idee kommt, die Daten public domain zu
veröffentlichen werde ich nicht die Spaltung des Projektes vorantreiben.
+1
Felix,
willst du deine Haltung nicht nochmal überdenken?
Gerne, wenn die Odbl zu einer SA Lizenz abgeaendert wird
On 27.08.2010 18:14, Manuel Reimer wrote:
Frederik Ramm wrote:
Mittlerweile haben sich die internationalen Befuerworter eines Forks ein
eigenes Forum gegeben: http://groups.google.com/group/osm-fork
Gut für die, dass Google mich keinen Account erstellen lässt.
Geht nämlich nur mit
Instead of just moaning about the Odbl, let's stark working on a
future without Odbl. So let's do our best to convince as many mappers as
possible to not accept Odbl, reopen registration to people who want to
contribute under CCBYSA2.0 terms, and put pressure on OSMF and others to
tell them
101 - 200 di 301 matches
Mail list logo
