Import danych z http://ump.waw.pl/

Dok?adnie tak jak mówisz, punkty nie s? do niczego potrzebne, a je?li droga jest rzeczywi?cie z UMP to powinna mie? odpowiedni tag source.

Zaczynam prostowa? b??dy - usuwam te setki punktów tylko z tagami source i debug (do niczego one w osm niepotrzebne) i poprawiam co si? da wyrównuj?c do gpxów. Mój JOSM teraz ciekawie wygl?da, a? oczy wypadaj? :wink:
]

Problem punktów POI z tagiem source i debug, powstaje kiedy skasujesz z importowanych danych jak?? ?cie?k? (bo np. jest ju? ona w OSM) zanim usuniesz z wszystkiego tag debug. Punkty z tagiem debug s? traktowane jako specjalne i JOSM nie usuwa ich przy kasowaniu danej ?cie?ki z nich z?o?onych. Dlatego tak wa?ne jest zacz?? import od Ctrl+A i usun?? tag debug.

Te punkty, by?y zatem przypuszczam ?cie?k? z UMP, któr? kto? usun?, bo zobaczy?, ?e Ty ju? namalowa?e? tam wszystko jak trzeba z .gpx’ow. Punkty ‘specjalne’ jednak zosta?y. Nie chodzi wi?c o to, aby doda? teraz tag source do ulic, poniewa? jak mówisz, pod spodem s? tracki - ?ród?em tych ulic nie jest UMP. Chodzi jedynie o r?czne usuni?cie samych POI.

Lub, kto? importuj?c dane usun? wszystko co Ty zrobi?e?, a te ?cie?ki to w istocie wci?? dane z UMP. Ty widzia?e? w Potlachu punkty sk?adowe danych ?cie?ek jako POI, bo mia?y (zdaje si? ju? nie maj?) nieusuni?ty tag debug (o którym to efekcie pisa? ju? antblant). I tak to chyba by?o my?l? po spojrzeniu na ten obszar w JOSM. :slight_smile:

Czyli wszystko jasne, dzi?ki za wyja?nienie. Chodzi o “POI” a nie punkty sk?adowe dróg, nie wiem jak w JOSM, ale w Potlachu ró?nica jest bardzo wyra?na, nie sposób pomyli?. :smiley: Jest takich punktów du?o w wielu miejscach … kiedy je spotkam po prostu kasuj? przy okazji rozgl?dam si? po okolicy przegl?daj?c nazwy ulic, czasami wymagaj? poprawy. W sumie to ich chyba jedyna zaleta, pokazuj? gdzie by? mo?e znajduje si? “ba?agan nazewniczy”.

Wi?ksze nieszcz??cia si? nam tu mog? wydarzy?, z t? niedogodno?ci? na pewno sobie wspólnymi si?ami poradzimy. :smiley:
Zrobi?em te? wst?pne rozpoznanie w kierunku nazw zaimportowanych ze z?ym kodowaniem, w pliku pobranym z geofabric znalaz?em niespe?na 600 wyst?pie? “WTF sign”

$ grep -c `printf '\xEF\xBF\xBD'` poland.osm
572

to kolejny ?lad po którym mo?na poszukiwa? nie do ko?ca prawid?owych nazw ulic (w okolicy wyst?pienia WTF’a).

Ktoś ma pomysł jak poprawić tag source w przypadku gdy node zaimportowany z UMP został poprawiony w oparciu o track gpx?

Tutaj http://wiki.openstreetmap.org/index.php/Key:source#Notes: jest napisane

Wydaje mi się więc, że kiedy wgramy publicznego tracka, i dostosujemy dane, tag source powinniśmy usuwać. W sensie tak całkowicie. Zamykamy temat wyrzucając klucz. :slight_smile:

Przenosz? z w?tku o debugowaniu mapy:

W wielkim skrócie:

  1. Pliki, na http://www.cd-sulewski.de/osmfiles/ od wczoraj, s? generowane z kodowaniem utf8. (dobra wiadomo??) :slight_smile:
  2. B?d? tam przypuszczalnie najwy?ej jeszcze par? miesi?cy, bo Damian musi odda? miejsce na serwerze. (z?a wiadomo??) :frowning:

To samo tylko, ?e szczegó?owiej (g?ównie po to, ?e jest tu opis jak ump2osm dzia?a):
Zacz??o si? po angielsku (Damian jest z Dortmundu), ale w ko?cu okaza?o si?, ?e…

Ustalili?my jednak, ?e nie potrzebny jest nam na razie kod do txt2osm. Wystarczy jedynie ma?a zmiana w update_ump.

I gdy na koniec nareszcie nie wytrzyma?em i zada?em oczywiste pytanie!

edit
Aha, dope?niaj?c opisu ump2osm.
txt2osm u?ywa plików MIASTO.ulice.txt ze ?róde? ump http://ump.fuw.edu.pl/wiki/Znaczenie_plików_w_projekcie_UMP
update_ump od?wie?a je za ka?dym razem z cvs, mniej wi?cej tak: http://ump.fuw.edu.pl/wiki/FAQ#Jak_.C5.9Bci.C4.85ga.C4.87_ca.C5.82e_.C5.BAr.C3.B3d.C5.82a.3F

Nie przejmowa?bym si? za bardzo. Warto utrzyma? kontakt z koleg? tak, aby informacja o tym, ?e pliki znikn? dotar?a do nas z jakim? wyprzedzeniem, cho? rozumiem, ?e je?li mamy skrypt generuj?cy pliki to w?a?ciwie nie ma problemu bo to co “zniknie” samo si? odtworzy. Jedyne czego brakuje to ludzi tutaj w celu przeprowadzenia evil planu w którym…
Je?li jest kto? kto chcia?by (i potrafi?) si? tym zaj??? To mo?e ten kto? potrzebuje konta shellowego za pó? ceny? Robimy zrzutk? na drugie pó? i ju?.
Konto na rootnode to 150z?/rok warto si? tylko dowiedzie? ile transferu miesi?cznie zu?ywa obs?uga skryptu i przystawi? te liczby do parametrów konta, ewentualnie ponegocjowa? z administracj? konta.

P.S. Je?li nikt nie doda dzi? nic nowego jutrzejszy poland.osm b?dzie WTFcharacter free (!)

Zauwa?y?em ostatnio, ?e txt2osm ma problemy z liczbami o precyzji ró?nej od 5 cyfr po przecinku (a w?a?ciwie kropce); w przypadku map Wroc?awia (lat/lon maj? po 6 cyfr po przecinku) zwraca

terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr

W tym przypadku wystarczy prosty regexp

s/\([0-9]*\.[0-9]*\)[0-9]/\1

który ucina ostatni? cyfr?, co nie jest mo?e najlepszym rozwi?zaniem, ale dzia?a. Problem dotyczy prawdopodobnie wi?kszej ilo?ci map, bo na http://www.cd-sulewski.de/osmfiles/ jest troch? wi?cej plików o podejrzanie ma?ym rozmiarze. Mo?e komu? si? chce/ma za du?o czasu, ?eby przepisa? txt2osm, je?li to ma jaki? sens?

K?opot polega zdaje si? na tym, ?e ?ród?a txt2osm nie istniej?, czyli trzeba by wszystko od nowa, napisa? przetestowa? etc.

Chyba sam mia?em za du?o czasu:) Tutaj jest skrypcik w pythonie, który (mam nadziej?) realizuje funkcjonalno?? txt2osm i nie ma problemów z ró?n? liczb? cyfr po przecinku. Poniewa? to skrypt, ka?dy mo?e go sobie “dotweakowa?” do swoich potrzeb, no i kod si? ju? nie zgubi:) Rozpoznaje typy dróg od 0x1 do 0x7, ale stosunkowo ?atwo mo?na zaimplementowa? konwersj? tak?e innych obiektów.

Poprawiam w?a?nie powy?szy skrypt. Troch? ma?o czytelny by? :P. Mog? wytkn?? sporo rzeczy, które przechodz? w innych j?zykach, ale w tym s? dziwaczne, ale… to nie forum programistyczne :). Zreszt? zasze mo?na spojrze? do kodu.
Sam kod b?dzie dost?pny przez jaki? czas tu: http://pinalambla.net/txt2osm.py od momentu, gdy go sko?cz?.

Dzi?ki za pomoc:) Or?em w pythonie nie jestem; szczerze mówi?c dopiero si? go ucz?.

Wida?, ?e przechodzisz z czego? podobnego do C :slight_smile:

Plik ju? mo?na pobra? z w/w adresu - dzia?a (chyba) jak nale?y:

[rhn@workhorse play]$./txt2osm_oryg.py ZASCIANKI.ulice.txt > r1
[rhn@workhorse play]$./txt2osm.py ZASCIANKI.ulice.txt > r2
[rhn@workhorse play]$ diff r1 r2
[rhn@workhorse play]$

Okazuje si?, ?e praktycznie przepisa?em logik? (za mocno sobie nakomplikowa?e?, wyja?ni? via email lub PW), za to wypisywanie si? mocno przyda?o (przede wszystkim dlatego nie chcia?em si? za to zabiera?).
Nie wiem tylko co oznacza zmienna “ref” w funkcji print_way. Pozwoli?em sobie j? zignorowa? przy wczytywaniu :).

Apropos podzi?kowa? - robimy to we wspólnym interesie :wink:

Wciąż mam “nie odnaleziono adresu”:confused: Na pewno jest prawidłowy?

Ref oznacza numer drogi (tag ref).

Wci??o mi literk?, dobrze, ?e zwróci?e? uwag? - poprawione.
W?a?nie spojrza?em na pliki UMP - rzeczywi?cie co? tam jest z numerami dróg… ale nie wiem za bardzo, co, wi?c nie b?d? rusza?. Mam nadziej?, ?e dosy? jasne jest, co w moim kodzie nale?a?oby zmieni?.

Tak tylko gwoli wyja?nienia jak to jest z tymi numeracjami dróg. W przypadku gdy jest co? takiego ~[0x2e]14, to oznacza to ni mniej ni wi?cej droge nr 14. Ten ca?y przedrostek informuje w jaki sposób ma by? ten numer wy?wietlany (czy w kó?eczku, prostok?cie, na tarczy jak w stanach itd itd, jest kilka mo?liwo?ci). Tak wi?c dla celów importu do osm mo?na to z powodzeniem pomin??.

Z tego, co zauwa?y?em, ten przedrostek razem z numerem powinien by? przed nazw? drogi, nie myl? si?? Wtedy jest kolejna niejasno??, bo droga wpisana jest w dwóch innych linijkach, za ka?dym razem inaczej.
Spróbuj? spojrze? na to do poniedzia?ku, je?li znajd? troch? wolnego czasu (prawdopodobnie za jednym zamachem z mapowaniem :)).

Co do pytania to przedrostek z numerem powinien byc przed nazwa drogi.

No wiec szybki kurs jak to z ump, nazwami i numerami drog jest:

Danej drodze mozna przypisac trzy rozne nazwy. W zrodlach oznacza sie je poprzez Label, Label2 i Label3. Pierwszy Label stosuje sie zawsze dla nazwy drogi, drugi i trzeci prawie tylko wtedy gdy droga jest numerowana. Jesli droga jest numerowana to wtedy aby pokazac numer tej drogi dodaje sie ten dziwny przedrostek (jak juz opisywalem) a zaraz za nim numer drogi, po czym nazwe ulicy. To wszystko dla Label. Taki sposob zapisu powodowalby jednak problemy przy sortowaniu nazw do ineksu (na przyklad drogi trzeba szukac by razem z jej numerem, co nie jest wskazane). Z tego powodu jest tez Label2 w ktorym dopisuje sie juz sama nazwe ulicy, bez numeru i innych takich. Label3 uzywa sie w wyjatkowych sytuacjach, gdy jakas ulica ma swoja alternatywna nazwe lokalna (ktora znaja tubylcy) oraz dla skrotow. No wiec konkretny przyklad:

[POLYLINE]
Type=0x4
Label=~[0x2f]705 Polskiego Czerwonego Krzyza
EndLevel=1
DirIndicator=1
Data0=(51.95443,20.15786),(51.95423,20.15743)
Label2=Polskiego Czerwonego Krzyza
Label3=PCK
[END]

No i teraz co mamy w Label
~[0x2f] - przedrostek ktory kaze wyswietlac numer drogi na mapie w prostokaciku z czarnymi obwodkami na gorze i dole
705 - numer drogi
Polskiego Czerwonego krzyza - nazwa ulicy

mamy tez dwa pozostale labele
Label2 - pod taka alternatywna nazwa bedzie ulica bedzie znajdowana
Label3 - pewnie wielu powie ze to ulica PCK wiec warto aby mozna bylo ja znalezc jeszcze pod taka nazwa.

Label2 i Label3 maja tez swoje dodatkowe znaczenia dla odbiornika, ale nie jest to istotne dla tych rozwazan. Mam nadzieje, ze troszeczke rozjasnilem. Jak chcecie robic import z ump naprawde dobrze to radze sie zapoznac ze struktura danych w UMP. Unikniecie sporo problemow a i osm bedzie lepsze. W razie problemow sluze pomoca.

http://pinalambla.net/txt2osm.py - tutaj jest kolejna wersja skryptu, która ju? rozumie, gdzie schowa? si? numer ref :slight_smile:
Poniewa? znalaz?em gdzie? kiedy? robzbie?no?? mi?dzy Label i Label2 (w której? brakowa?o polskich znaków), stwierdzi?em, ?e lepiej korzysta? z tej, która jest naprawd? u?ywana, czyli Label2. Teraz je?li jest ustawione, jest brane zamiast Label (oczywi?cie, numer drogi nadal jest brany pod uwag?).

Poprawi?em te? kod odpowiadaj?cy za wczytywanie koordynatów. Teraz b?d? dok?adnie takie, jak by?y w pliku, poniewa? nie s? wczytywane jako liczby. Usuwa to te? potencjaln? dziur? w bezpiecze?stwie (odpowiednio spreparowany plik móg? zrobi? szkody w systemie, poniewa? pary koordynatów by?y interpretowane jako kod).

Dzi?ki za podpowiedzi!