Nie zgadzam się z Tobą. Uważam, że miejsce gdzie jest tag zależy od POI. Jeśli tagujemy centrum handlowe to punktami POI są konkretne sklepy, a budynek to shop=mall. Gdy POI jest sklepem w kamienicy to jako POI, ale gdy jest to biedronka, która obejmuje cały budynek to powinno być w obrysie. To jest moje podejście. Oczywiście jeśli budynek składa się z segmentów to tag w relacji zamiast w obrysie.
Ok, masz rację, ale Twój post nie jest negacją, tylko uzupełnieniem mojej koncepcji
Dotevo, mam pytanie: czy jeśli będę chciał wyciągnąć z bazy OSM określone POI i zrobić z tego GPX, to taki budynek otagowany jako POI będzie w nim jako czy nie? A jeśli będzie, to co dokładnie zadecyduje o jego współrzędnych? Geometryczny środek?
Powyższe pytanie, w moim zamiarze, ma zobrazować pewien problem…
Pewnym rozwiązaniem jest dublowanie, czyli tagowanie i węzła, i obrysu, ale dla mnie to jest fuj…
GPX to nie wszystko… A dzięki takiej koncepcji zyskujemy grupowanie obiektów i może kiedyś nawigacja Ci napisze, że najbliższy bankomat jest w galerii A. Albo, że mięsny znajduje się w budynku biedronki. Oczywiście do GPX zostaje jedynie wpt z geometrycznym środkiem lub wejście.
Ja się zgadzam z Dotevo i zrobiłbym tak jak użytkownik z pierwszego posta.
W Garmin dzięki mkgmap można nawigować do POI, które jest otagowane jako budynek wprost do wejścia (building=entrance).
Ja widzę wręcz przeciwny problem. Jeśli POI jest tagowane jako node i kilka takich obiektów znajduje się w jednym budynku to nie jesteśmy w stanie tego oznaczyć w OSM, oprócz tego, że pozycja node jest wewnątrz obszaru ograniczonego przez budynek.
Ja też zgadzam się z Dotevo, co jednak nie zmienia mojego stanowiska
A co w sytuacji, kiedy jest sobie budynek, a w nim jest i przedszkole, i policja (przykład autentyczny)? Mam zastanawiać się, czy to jest bardziej przedszkole, czy może bardziej policja tagując obrys? Nie, wolę narysować obrys budynku, otagować go jako budynek i postawić dwa nody z odpowiednim amenity.
Odpowiadam widzac ze dodales “z mojej storny” Mielismy juz dyskusje o szkolach, mysle ze tutaj tak samo rozwiazaniem jest tagowac POI na budynku tylko tam gdzie rzeczywiscie zajmuje caly budynek. Tam gdzie mamy kilka rzeczy w budynku to musimy je wpisac oddzielnie (dwa node’y lub dwa obrysy)
Ja uważam, że mimo zajmowania przez POI całego budynku, rozsądniej jest jednak ustawiać go jako node wewnątrz. Kilka przykładów:
POI może zajmować budynek. Po pewnym czasie jednak może zostać przeniesiony do innego. Przeniesienie punktu nie tylko będzie łatwiejsze/wygodniejsze, będzie bardziej zgodne z przeniesieniem POI w rzeczywistości. Baza danych też na tym skorzysta
To taki przykład ogólny (działający dla każdego POI).
Pytanie jak robią to inni ? np. Niemcy którzy są chyba największą społecznością OSM
Do tej pory byłem przekonany że jeżeli już jest budynek to trzeba wywalić node i otagować budynek.
Zrobiłem taką operacje może z dwa razy tam gdzie mogłem się przejść z GPS’em wokół budynku (gdyż jest brak zdjęć binga w mojej najbliższej okolicy) więc w razie co mogę szybko naprawić.
Z przyjęciem metody będzie trudno. Pewnie tak jak u nas i u naszych sąsiadów zdania będą podzielone. Tak samo zresztą z różnymi rodzajami POI. Ja podałem swoje, wg mnie sensowne przykłady. Ty podałeś przykład (trudny do obalenia) kościoła, który jako budynek-zabytek pozostanie pod nazwą kościół (może oprócz wezwania parafii) mimo, że jako instytucja może się przenieść do nowego
W moich edycjach też znajdzie się kilka budynków “otagowanych zawartością”.
Pozostaje jeszcze kwestia historii samego budynku. Gdy POI jest oddzielnym node, w historii budynku nie będzie informacji, kto ten budynek wcześniej zajmował.
Można np. przyjąć metodę, w której w tagach budynku będą informacje wg stanu dzisiejszego. Tylko gdzie zapisywać te wszystkie old_name itp.
Ja tylko powiem, ze wiekszosc obiektow w rzeczywistosci ma niezerowa powierzchnie i obrysowanie obszaru niewatpliwie niesie wiecej informacji niz tylko zaznaczenie srodka. W przypadku sklepu z ciuchami oczywiscie roznica jest zupelnie nieistotna. Ale OSM idzie w kierunku coraz wiekszej szczegolowosci i wiekszej ilosci informacji i nawet takie nieistotne informacje w koncu sie w nim znajda. Raczej nie warto probowac tego powstrzymywac.
Bedziemy sie starali podjac temat na spotkaniu roboczym w Garchingu w polowie marca tym bardziej, ze wraz ze szczególowym 3D powstaje coraz wiecej dykusyjnych kwestii
Podsumowujac warto rozbudować relacje type=building o dane niedokładne (czyli brak obrysu pokoju, brak danych o piętrze) wtedy łatwiej ulepszać takie dane.
Napisałem, ponieważ mają być jakieś rozmowy na ten temat szkoda, żeby moja propozycja ulepszenia przepadła.
Wydaje mi sie sensowne
Móglbys tę propozycje po angielsku zrobic ( *.ppt) w formie prezentacji, rysujac jakis fikcyjny przyklad pod dyskusje?
Kolega od indoor mapping jest oczywicie na spotkaniu w Garchingu…