Ich finde einige Antworten auch ziemlich wenig einladend formuliert.
Hoffentlich hat das keine zu große abschreckende Wirkung.
Die Idee finde ich nämlich sehr gut.
Der Namensraum sollte angepasst und eine Nachvollziehbarkeit für andere Mapper
sollte gegeben sein.
Es sollte aber klar sein, dass
OsmAnd soll TSP mit der kommenden Version 1.4 können:
https://groups.google.com/forum/?fromgroups#!topic/osmand/UWaMt-_zVRE
https://github.com/osmandapp/Osmand/commit/7de85b7cf6a0bb2c177d8990cc8e1c8af3dc1444
Getestet habe ich diese Funktion bisher nicht.
- Ursprüngliche Message -
Hoffe gibt für die Bezahler über AndroidPIT bald auch ne neue Version.
Ist seit heute auch verfügbar:
http://www.androidpit.de/de/android/market/apps/app/net.osmand.plus/OsmAnd-Karten-Navigation
Die kostenlose Version gab es schon gestern:
OsmAnd ist jetzt wieder im Google Play Store erhältlich:
http://osmand.net/en/component/content/article/85-google-play-app-unavailable.html
https://play.google.com/store/apps/details?id=net.osmand
https://play.google.com/store/apps/details?id=net.osmand.plus
Das Design wurde verändert.
Weiß jemand Näheres?
Es scheint Differenzen zwischen dem Designer und dem Projektmanagement gegeben
zu haben.
Jetzt ist man vermutlich nicht mehr berechtigt, die bisherigen Icons zu
verwenden.
Dies hatte dann vermutlich auch die Entfernung aus dem Google Play Store zur
Folge.
Jetzt ist man
Auch kann ich den Bereich sehr gut einschränken.
Dann hilft dir vielleicht:
http://zverik.osm.rambler.ru/whodidit/
http://owl.apis.dev.openstreetmap.org
___
Talk-de mailing list
Talk-de@openstreetmap.org
Beim genaueren Betrachten der Daten sieht es aus, als würden neue
Objekte und Änderungen an bestehenden seit der Umstellung auf 64-bit
identifiers nicht in der AiO auftauchen.
Die Node-ID 2^31-1 wurde am 9. Februar 2013 überschritten.
Das Problem scheint aber schon am 28. Januar 2013
Angelehnt an:
http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html
name=test123C und name=test1231C (aber nicht name=test123c oder name=test12C)
findet man z.B. so:
name=.+\\d{3,4}\\p{Upper}
___
Talk-de mailing list
Die Information war also bekannt und das es mit dem Auslagern funktioniert
auch. Die dort bereitgestellte Version verwende ich übrigens bis heute.
Wenn es dann trotzdem nicht eingebaut wird fällt es mir echt schwer nicht an
Ignoranz zu denken.
Bitte berücksichtige bei deiner Überlegung,
On Wed 2012-08-15 (12:02), Steffen Grunewald wrote:
Danke, aber das scheint die Westküste ziemlich großräumig auszusparen.
Liegt wahrscheinlich an der geringen Einwohnerdichte (da sollte man
mal drüber nachdenken, auch die Touristen mitzuzählen!).
Heute gibt es auch für Irland wieder neue
Gleich wieder gelöscht, da es der Entwickler mal wieder versäumt hat, dass
man die App auf SD-Karte auslagern kann. Schönen Dank auch.
Warum denn so aufgeregt?
Wahrscheinlich fehlt in der AndroidManifest.xml nur das hier:
android:installLocation=auto
Vielleicht wäre ein freundlicher Hinweis
Am 11. November 2012, 03:50 schrieb Albrecht Will:
es hat den Anschein, als wärst Du dicht bei Osmand dran.
Ich bin nur ein interessierter Beobachter, der auch ab und zu bei der
Fehlersuche und Fehlerbehebung hilft.
Wenn das so ist,
würde ich Dir gern noch weitere Probleme mitteilen. Aber
Cobra schrieb:
In die Liste der Luftbilder wurde es von bubeck eingetragen
Kann man diesen Benutzer irgendwie erreichen?
Ich habe nicht herausgefunden, ob man bei diesem Wiki Benutzern eine Nachricht
schreiben kann.
Registriert ist der Nutzername bubeck.
Am 7. November 2012, 09:25 schrieb Albrecht Will:
am 3.11 habe ich mich erstmalig von Osmand navigieren lassen. Dabei fiel mir
ein eklatanter Fehler in der Führung auf.
Ich wollte gerade einen Fehlerbericht für OsmAnd erstellen, kann dieses Problem
mit der Offline-Navigation aber nicht
Am 7. November 2012, 09:39 schrieb Eckhart Wörner:
Der Fehler liegt in diesem Fall bei Osmand, und zwar gleich doppelt:
1. trunk_link impliziert zwar oneway=yes, das explizite oneway=no hebt das
aber wieder auf.
2. der U-Turn, den Osmand vorschlägt, ist falsch: seit dem 9.1.2012 ist da
ein
Am 26.10.2012 14:32, schrieb Fred Jelk:
Im Webinterface unter http://de.netmeterproject.com/dashboard/account
kann man der CC-BY-SA zustimmen. Und danach in der App in den
Einstellungen meinem Konto zuordnen und die Samples sind CC-BY-SA.
CC-BY-NC-SA, nicht CC-BY-SA.
Am 26.10.2012 11:14, schrieb Fred Jelk:
Alle anderen Daten, bleiben anonym und können nicht heruntergeladen werden.
Auch die herunterladbaren CC-BY-NC-SA-Daten sind anonym.
___
Talk-de mailing list
Talk-de@openstreetmap.org
Am 26.10.2012 14:20, schrieb Cobra:
Lückenhaft unter CC finde ich da schon frech. Aber das noch als NC ist
einfach nur unverschämt.
Sorry, nicht mit mir. Und ich finde auch, dass man für sowas keine Werbung im
OSM-Umfeld machen sollte, egal ob sie jetzt OSM-Daten _nutzen_ wollen oder
Am 26.09.2012 um 8:00, schrieb Jochen Topf:
Da ist noch ein zusätzlicher, leerer SVG-Layer drin, der das verhindert.
Danke.
Habe die SVG-Layer testweise mit Adblock Plus ausgeblendet und danach
funktioniert Grafik anzeigen.
Verwendet habe ich folgende Filterregel:
openstreetmap.de##svg
Am 26.09.2012 um 8:17, schrieb Butrus Damaskus:
das habe ich schon mehrmals gehört, dass es so ein Trick gibt, aber
habe nirgendo gefunden,
wo genau das /dirty kommt.
Beispiel:
Kachel:
http://c.tile.openstreetmap.de/tiles/osmde/18/139330/85893.png
Kachel dirty:
Am 26.09.2012 um 0:29, schrieb Michael Kugelmann:
Geht viel einfacher: die neu zu rendernde Kachel mit der RECHTEN Maustaste
anklicken = Grafik anzeigen
Nein, genau das geht eben bei openstreetmap.DE (darum ging es hier), zumindest
mit dem genannten Firefox, nicht.
Am 26.09.2012 um 1:02, schrieb Frederik Ramm:
Vermutlich geht es, wenn Du den lokale Gruppen-Layer vorher abschaltest.
Danke für den Hinweis, hilft aber leider auch nicht.
___
Talk-de mailing list
Talk-de@openstreetmap.org
Am 08.09.2012, 20:19 Uhr, schrieb Andreas Schmidt:
Der Fehler Linie mit Flächenzeichenstil nicht geschlossen wird
anscheinend von einem Punkt der Waldgrenze ausgelöst, der oben rechts liegt.
Den habe ich mal gelöscht und neu erstellt, das brachte aber leider nichts.
Die Tags der outer-Wege
Am 06.09.2012, 11:37 Uhr, schrieb Steffen Grunewald:
Hängt damit irgendwie zusammen, dass die Garmin-img-Dateien von
All-In-One und Raumbezug heute *sehr* klein ausgefallen sind?
Nein, das liegt daran, dass die Geofabrik-Extrakte heute teilweise leer sind:
Am 04.09.2012, 8:45 Uhr, schrieb Lars Schimmer:
Einen Track aufs ETrex bringen ist ja
ned, bei 50 (oder waren es 500?) Punkten ist Schluß - das reicht
nichtmal für eine Tagesetappe.
Mit diesem Trick ist es mir gelungen, Tracks mit bis zu 10.000 Punkten auf ein
eTrex Vista HCx zu bekommen:
Am 04.09.2012, 11:56 Uhr, schrieb Jacques Nietsch:
Erledigt!
Ticket #400
Direktlink, damit nicht jeder suchen muss:
https://github.com/DennisOSRM/Project-OSRM/issues/400
Eigentlich sollte motorcar=yes inzwischen (31. August) berücksichtigt werden:
Am 03.09.2012, 17:01 Uhr, schrieb Jacques Nietsch:
Ganz schlecht leider!
siehe http://map.project-osrm.org/1hf
Schranken scheinen immer als unüberwindlich zu gelten :(
Um welche Schranke geht es denn in deinem Beispiel?
Diese hier?
http://www.openstreetmap.org/browse/node/1513009639
Wenn
Am 24.08.2012 0:21, schrieb Johann H. Addicks:
d.h. auch wenn es Beschleunigungswerte in Tunneln gibt, daraus lassen
sich -so sehe ich's- keine Tracks verbessern.
Richtig.
___
Talk-de mailing list
Talk-de@openstreetmap.org
Am 27.08.2012 23:55, schrieb Michael Kugelmann:
Es gab nun mal eine sehr deutliche Mehrheit der Mapper, welche für eine
Lizenzumstellung gestimmt haben.
Scheinbar hat aber eine kleine Minderheit z.B. ein aus meiner Sicht gestörtes
Demokratieverständnis (oder was auch immer).
Es gab keine
Hallo!
Am 23.08.2012 03:25, schrieb Johann H. Addicks:
Vielleicht kann ja jemand von Euch auf dieser Grundlage das Format
enträtseln.
Wir haben mehrere Lösungen erarbeitet und vorgeschlagen:
http://lists.openstreetmap.org/pipermail/talk-de/2012-June/096027.html
On Wed 2012-08-15 (12:02), Steffen Grunewald wrote:
Danke, aber das scheint die Westküste ziemlich großräumig auszusparen.
Liegt wahrscheinlich an der geringen Einwohnerdichte (da sollte man
mal drüber nachdenken, auch die Touristen mitzuzählen!).
Es wird für die ganze Insel neue Bing-Bilder
Die (irgendwo) versprochenen höherauflösenden Bing-Bilder habe ich noch nicht
sichten können.
Ich habe die Umrisse der bisher schon verfügbaren neuen Bing-Bilder in Irland
hier als OSM-Datei hochgeladen:
http://pastebin.com/download.php?i=aL8vSFYH
Jetzt kannst du dir ein genaues Bild davon
Ich habe mir das genauer angesehen und festgestellt, dass der Bot die
Löschungen vorgenommen hat:
http://www.openstreetmap.org/browse/way/8433108/history
http://www.openstreetmap.org/browse/way/8432921/history
Warum der OSMI das nicht anzeigt, ist mir nicht bekannt.
Am 09.08.2012 1:07, schrieb
Hallo Frederik,
manche Löschungen durch den Bot werden nicht angezeigt:
http://lists.openstreetmap.org/pipermail/talk-de/2012-August/097402.html
Weißt du woran das liegt?
___
Talk-de mailing list
Talk-de@openstreetmap.org
Am 12.06.2012 11:29, schrieb Steffen Grunewald:
Die Einheiten des Beschleunigungssensors wären ja auch mal interessant...
Offensichtlich milli g.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Am 11.06.2012 15:17, schrieb Steffen Grunewald:
So offensichtlich ist das für mich nicht - dann sollte doch nach Pythagoras
die Summe der Quadrate der einzelnen Komponenten genau 100 ergeben?
Nein, warum?
Da aber der eine Wert ziemlich konstant über 1000 liegt, geht das schon
mal nicht
Jetzt mit Offset-Berechnung, verwendet * aus der NMEA-Prüfsumme:
#include stdlib.h
#include stdio.h
int main (int argc, char *argv[])
{
if (argc != 2)
{
printf(usage: %s filename\n, argv[0]);
exit(1);
}
else
{
FILE *file = fopen(argv[1],r);
Wer mit diesen Daten (Offset 57) testen möchte, sollte die Zeilen nicht, so wie
ich zuerst, inUTF-8 speichern, sondern z.B. Windows-1252 verwenden, damitdie
Zeichen €, ‰, ‹, † und ‡ als 0x80 (128), 0x89 (137), 0x8b (139), 0x86 (134)und
0x87 (135) abgespeichert werden, umgewandelt sind das dann
Dieser Variante hier ist die Größe des Offsets egal.
Meinst du damit z.B. 57 + 1024 oder 57 - 1024?
Mit dieser Version sollte das ebenfalls funktionieren:
#include stdlib.h
#include stdio.h
int main (int argc, char *argv[])
{
if (argc != 2)
{
printf(usage: %s filename\n,
Am 11.06.2012 2:46, schrieb bkmap:
ok, die Version war bei mir noch nicht angekommen. Da hätte ich mir das
Posten sparen können :-)
Mehrere Varianten sind doch interessant. :-)
___
Talk-de mailing list
Talk-de@openstreetmap.org
Perfekt! :)
Hier ein kleines Programm für die Umwandlung:
#include stdlib.h
#include stdio.h
int main (int argc, char *argv[])
{
if (argc != 2)
{
printf(usage: %s filename\n, argv[0]);
exit(1);
}
else
{
FILE *file = fopen(argv[1],r);
Hier meine Analyse:
T sind die Feldtrenner.
Die kurzen Zeilen enthalten die
Daten des Beschleunigungssensors, das Datum und die Uhrzeit, aber nur
leere GPS-Daten, da hier noch kein GPS-Fix vorliegt.
Die langen Zeilen enthalten auch die GPS-Daten.
Aufbau:
42 matches
Mail list logo
