Re: [talk-ph] Where exactly is Apalit Bridge?
got it thanks :-) http://www.gmanews.tv/story/239379/regions/apalit-pampanga-bridge-collapses-as-three-dump-trucks-pass I think it's Colgante Bridge in our OSM map N14 56.351 E120 44.139. ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Osm to distribute south africa geodata
Sharing this news: http://afrispatial.co.za/open-data/osm-to-become-a-distributor-of-ngis-south-african-topo-data/ South Africa, NGI [1] is in the process of signing an agreement with OSM [2]. It is a modified version of NGI’s standard ‘Map Data Services Provider’ agreement whereby third parties can distribute NGI data. What this means is that OSM will incorporate all the most recent South African topographical vector data from NGI. NGI data have been free and open for several years but this will make them accessible as never before. ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[OSM-talk-be] potlatch onbegrijpelijk
Ik begrijp niet wat er gebeurd is, maar ik herken me niet meer in potlatch, heb 2 weken geleden nog een edit gedaan. Welke settings voor: - background - map style ? Marc -- The Penguin has arrived - and he's not going away - ever. What's on Shortwave guide: choose an hour, go! http://shortwave.tk 700+ Radio Stations on SW http://swstations.tk 300+ languages on SW http://radiolanguages.tk ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] potlatch onbegrijpelijk
Marc, Ben juist aan het editen, geen enkel probleem. Background is standaard Bing, mapstyle Potlatch. (werk in Firefox - MacOsX) Georges Op 23 november 2011 21:40 schreef Marc Coevoet sintsix...@gmail.com het volgende: Ik begrijp niet wat er gebeurd is, maar ik herken me niet meer in potlatch, heb 2 weken geleden nog een edit gedaan. Welke settings voor: - background - map style ? Marc -- The Penguin has arrived - and he's not going away - ever. What's on Shortwave guide: choose an hour, go! http://shortwave.tk 700+ Radio Stations on SW http://swstations.tk 300+ languages on SW http://radiolanguages.tk __**_ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-behttp://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] potlatch onbegrijpelijk
Misschien een boodschap van het universum om aan te geven dat het tijd is om de overstap te maken naar JOSM? Ik ben ook 's gaan kijken en ik zie ook geen verschil. Ik heb ook Show License Status aangezet in de settings, maar zie ook daardoor geen verschil. Ik ben speciaal naar rendle z'n habitat (Dendermonde/Aalst en grote omgeving) gegaan, omdat ik weet dat daar een groot gat zal ontstaan op 1 april 2012 (misschien in de vorm van een vis? toch wel een zeer ongelukkig gekozen datum...) Maar goed, Potlatch2 werkt even goed als voorheen, maar ik kan er, tot mijn grote spijt, niet meer mee overweg. mvg, Jo Op 23 november 2011 21:40 heeft Marc Coevoet sintsix...@gmail.com het volgende geschreven: Ik begrijp niet wat er gebeurd is, maar ik herken me niet meer in potlatch, heb 2 weken geleden nog een edit gedaan. Welke settings voor: - background - map style ? Marc -- The Penguin has arrived - and he's not going away - ever. What's on Shortwave guide: choose an hour, go! http://shortwave.tk 700+ Radio Stations on SW http://swstations.tk 300+ languages on SW http://radiolanguages.tk ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Ik heb net deze conversatie gehad met Jan:
Dag Jo,
Zou je even willen kijken naar FRN SRAN relatie 957169 (25-26). Je
controle pagina geeft aan forward continuous / backward NOT continuous.
Er is echter niets mis met de forward/backward rollen in deze relatie.
Ik denk dat het ligt aan way 61319667 (een fietspad bij de kruising die in
twee richtingen te befietsen is; i.t.t. de anderen bij deze kruising als ik
het me goed herinner). Deze heeft in relatie 957169 als enige stukje een
role=backward. En dat moet ook.
Er zijn drie verschillende routes die gebruik maken van fietspad 61319667.
Een (26-98) gebruikt het in beide richtingen; een (26-27) in dezelfde
richting als de tekenrichting (role=forward) en een (25-26) in
tegengestelde richting (=backward).
Het staat in OSM zoals het ook in de werkelijkheid is bewegwijzerd. (Voor
de goede orde, het fietspad langs de Van Elkweg vanaf knooppunt De Heister
naar het zuid-oost is een tweerichting fietspad en 26 naar 25 gaat daar
langs (naar 'beneden'); maar 25 naar 26 ('omhoog') is bewegwijzerd langs
het fietspad aan de andere kant van de Van Elkweg).
Dit is een voorbeeld waar het niet handig is om de tekenrichting van een
weg om te draaien om forward/backward op te lossen (of in ieder geval het
zal niets uitmaken want dan heeft de ander relatie een 'probleem').
Ik denk dat de forward/backward logica die je gebruikt niet berekend is op
alle situaties en dus niet correct staat op je controle pagina. Dat kan
voor meer van die relaties gelden (ik heb ze niet onderzocht).
Als het niet duidelijk is, mij even berichten.
Groeten,
Frank
Jo
01:55 (10 uren geleden)
Ik heb er naar gekeken en mijn conclusie is dat die node (26)
gesplitst moet worden. Ik ga dat dus even doen en dan laat je me
achteraf maar weten of je daarmee kan leven.
Jo
Op 24 november 2011 01:49 heeft Frankl2009 frankl2...@xs4all.nl het
volgende geschreven:
Jo
02:07 (9 uren geleden)
aan Frankl2009
De node is nu gesplitst in 3 nodes. Eén voor elk punt waar een route
met als begin-/eindpunt KP 26 toekomt.
25-26 is aangepast. Het stuk dat jij een role backward had gegeven
hoort eigenlijk niet bij 25-26. Het stuk dat van de route die uit het
westen komt, zit er dan weer wel bij. Verder heb ik een paar wegen van
volgorde moeten veranderen. Om dat soort dingen te doen, is JOSM echt
veel beter geschikt. Op het tentakel na, zou die de leden van die
relatie zelfs in jouw plaats kunnen sorteren. Met het tentakel bedoel
ik dat stukje dat van het einde van de route uit het westen, naar het
eigenlijke begin van 26-25 leidt. (Ik heb de cijfers met opzet even
omgewisseld).
Nu ga ik de andere routes nakijken die op KP 26 toekomen.
Jo
02:34 (9 uren geleden)
aan Frankl2009
Ik had te laat gezien dat er ook nog een vierde route op dat knooppunt
toekomt, dus heb ik één van de nodes van het gesplitste KP moeten
aanpassen en dat heeft z'n weerslag op alle 3 de routes waar ik van
dacht dat ze al klaar waren.
Dit is vanaf nu dus één van de meer ingewikkelde knooppunten in het
netwerk geworden. Als je er één wilt zien dat nog wat complexer is,
kijk dan hier eens:
http://www.openstreetmap.org/?lat=51.18752lon=4.40465zoom=17layers=M
Dat is het knooppunt waar ik op geleerd heb, hoe het moet met
gesplitste knooppunten en de 'tentakels' die ze veroorzaken. Ik hoop
dat ik het nu correct geleerd heb, anders zijn er massaal veel
knooppunten die (nog) niet in orde zijn.
mvg,
Jo
Op 24 november 2011 02:07 heeft Jo winfi...@gmail.com het volgende
geschreven:
Frankl2009 frankl2...@xs4all.nl
10:33 (1 uur geleden)
aan mij
Nee, Joe, doe dat maar niet (splitsen). Er is daar GEEN gesplitst node
(i.t.t. sommige locaties waar er inderdaad twee nodes te vinden zijn).
Volgt aub de werkelijkheid en niet denkbeeldige constructies.
Je zult dus rekening moeten houden van situaties zoals ik al had geschetst.
Mocht je dit ondertussen wel gedaan hebt, aub terugdraaien.
Groeten,
frank
- Original Message - From: Jo winfi...@gmail.com
To: Frankl2009 frankl2...@xs4all.nl
Sent: Thursday, November 24, 2011 1:55 AM
Subject: Re: FRN SRAN Vraag over werkwijze controle
Frankl2009 frankl2...@xs4all.nl
10:41 (1 uur geleden)
aan mij
Nee, nee, driewerf, nee. Ik verzet me tegen dit soort constructies.
Als we zo te werk willen gaan op zijn minst moet er eerst toch enige
overeenstemming zijn dat we het zo gaan doen. Maak dan als je het echt wil
eerst een voorstel (maar niet meteen implementeren op de wiki, aub) en
kijken of men er voor te vinden is.
Let wel op dat dit bij vele (complexe) kruisingen met fietspaden die
tevens knooppunt zijn zal moeten gebeuren.
Ik ben er niet voor omdat het de map what you see principe helemaal
loslaat. Wij zien in het veld maar één node in het FRN SRAN bij zo'n
kruising. Om te komen bij zo'n infopaneel moet je geleid worden zoals de
verkeerregels dat toestaan. En er moet voldoende intelligentie zijn in
Re: [OSM-talk-be] Fwd: [OSM-talk-fr] StreetView?
OSM is no alternative to StreetView. It's an alternative to Google Maps though. So I don't think we should react. We should just spread the word of OSM on a continuous base. Apart from that, if OSM would suddenly get in the big media, we would also have a lot of problems with training newbies. The best system is that of continuous growth, where the older generation can teach the newer generation. And I'm not even talking about vandalism here. I hope you understand what I'm saying. Regards, Sander 2011/11/24 Julien Fastré julienfas...@gmail.com Hi everybody, I am a bit tired to see - the media talking about the problem of privacy ; - some institutions (I am thinking to the mayor of Brussels, and tourism brussels) happy to promote their service /via/ StreetView; And all those things without mentioning the alternative (including OSM). I think we should react. It is time to make speaking about osm with some regional and federal MP. We should make contact with some of them, and give them arguments. Some MP should make interpellation with the theme you are going to rely on private companies to promote tourism in our region, why don't you use free and opensource tools ? Julien question ng street name. The housenumbers were as indicated approximative and way off. The viewpoints of Google are with distances of 20 m plus and so many signs and even housenumbers (when houses are not at the street border) are not readable on the photo. Also Polyglot will be out of luck for decoding sign plates at the bus stops. Oh, I didn't even bother to try to do that yet. Doing it for the remaining 39000 would most probably not be all right at all... so it didn't even occur to me. Jo ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be -- Julien FASTRE http://www.meta-morphoses.be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
On Thursday 24 November 2011 12:32:39 Jo wrote: ... mvg, Jo TL;DR? :-p Als ik het in het snel doorlezen een beetje heb begrepen wat het probleem is, namelijk dat er maar één overzichtsbord staat in NL op het knooppunt, en dat dan door die Jan beschouwd wordt als het knooppunt met rcn_ref en al de rest niet, dan zitten we met het probleem van het halfslachtig bewegwijzeren in NL, waar de knooppuntnummers in enkele netwerken niet worden weergegeven op de bordjes zelf eens je er aankomt, enkel op het grote overzichtsbord (dit is bvb. een knooppunt: http://www.vv.nl/images/upload/knooppunt.jpg ). M.a.w. de plekken waar je de bordjes zoals hierboven tegenkomt zijn de nodes die je tagt met rcn_ref, en je negeert eigenlijk het overzichtsbord (kan je eventueel nog wel anders taggen als je wil). En nu hoop ik dat ik de discussie juist begrepen heb :-) groetjes Ben ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fwd: [OSM-talk-fr] StreetView?
I think you are right in saying that we should not try to force the issue. On Thu, Nov 24, 2011 at 3:04 PM, Sander Deryckere sander...@gmail.comwrote: Sorry to go off topic, but... 2011/11/24 Ben Abelshausen ben.abelshau...@gmail.com So I don't think we should react. We should just spread the word of OSM on a continuous base. Apart from that, if OSM would suddenly get in the big media, we would also have a lot of problems with training newbies. The best system is that of continuous growth, where the older generation can teach the newer generation. And I'm not even talking about vandalism here. I don't think a lot of new users should scare us into not seeking more visibility for the project. I think it would be a very good thing to get more new users involved! OSM is the best mapping project and free as in free speech! Everybody should know this... We should not be scared of seeking visibility, I know OSM can handle a lot of new users, and making us visible is also a way to get a steady growth. But we should not demand the media to give us the attention. When we grow bigger, the media will report about OSM because we're more interesting, and we will have enough man-power to handle everything. If you disrupt that steady process, and you really demand stuff through laws and lawsuits, I don't think it would end very well. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en egrijpelijke misverstanden eromheen
Het moet waarschijnlijk nog gecorrigeerd worden, ik had ook niet vanaf het begin begrepen wat de beste werkwijze was en hier en daar heb ik ook 1 knooppunt aangemaakt, waar ik er nu wel 2, 3 of 4 zou opsplitsen. Ik kijk er straks even naar. Jo Op 24 november 2011 15:21 schreef Marc Gemis marc.ge...@gmail.com het volgende: Ik heb nog nooit op de bordjes voor fietsenknooppunten gelet. Vanwege de discussie hier heb ik eens gekeken hier in de buurt http://www.openstreetmap.org/?lat=51.073425lon=4.424868zoom=18layers=M Knooppunt 51 heeft bordjes aan beide zijde van de Nete. Er zijn 2 knopen met rcn_ref 51. In OSM loopt Route 51-21 steeds over de brug, terwijl dit niet nodig als je 50-51-21 wil volgen. Ik weet niet hoe een routebegeleidingssysteem de huidige data zou interpreteren. Zou dit niet op de een of andere manier moeten gecorrigeerd/aangepast worden worden ? Hetzelfde probleem treedt op bij de brug over de Dijle net ten zuiden van de vorige brug Gelukkig voor mij zijn er wel afzonderlijke knooppunten voor het wandelnetwerk daar ;-) Marc ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fwd: [OSM-talk-fr] StreetView?
People tend to judge the book by the cover and not by the content. In this respect OSM is no match to StreetView. So, we should not try to profilate us against it. It will only cause disbelief and leaves OSM with a stamp of inferiority, because there is not the bling bling of StreetView. There are other opportunities, which are more suitable to get attention for OSM and then we can do it with our strong points. One example is trage wegen / voies lentes, which get much attention in many villages and its councels these days. There we can offer advanced mapping en cartography. If you can't win, don't go to the battle. Ben Abelshausen wrote: I think you are right in saying that we should not try to force the issue. On Thu, Nov 24, 2011 at 3:04 PM, Sander Deryckere sander...@gmail.com mailto:sander...@gmail.com wrote: Sorry to go off topic, but... 2011/11/24 Ben Abelshausen ben.abelshau...@gmail.com mailto:ben.abelshau...@gmail.com So I don't think we should react. We should just spread the word of OSM on a continuous base. Apart from that, if OSM would suddenly get in the big media, we would also have a lot of problems with training newbies. The best system is that of continuous growth, where the older generation can teach the newer generation. And I'm not even talking about vandalism here. I don't think a lot of new users should scare us into not seeking more visibility for the project. I think it would be a very good thing to get more new users involved! OSM is the best mapping project and free as in free speech! Everybody should know this... We should not be scared of seeking visibility, I know OSM can handle a lot of new users, and making us visible is also a way to get a steady growth. But we should not demand the media to give us the attention. When we grow bigger, the media will report about OSM because we're more interesting, and we will have enough man-power to handle everything. If you disrupt that steady process, and you really demand stuff through laws and lawsuits, I don't think it would end very well. ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en egrijpelijke misverstanden eromheen
Een fietsknooppuntennetwerk is sowieso een stuk ingewikkelder dan een wandelknooppuntennetwerk, omwille van éénrichtingsverkeer waar wandelaars geen last van hebben en ook omdat ze hebben ingezien dat het nergens voor nodig is om zich te beperken tot de getallen 01-99 bij het aanleggen van de wandelknooppuntennetwerken in België 3-10 jaar na de FKpNw'en. Het eerste wat ik opmerk, is dat ik daar blijkbaar een rwn_ref van 165 naar 90 heb gewijzigd. Kan je dat 's nakijken? Dat is waarschijnlijk fout. De kans is groot dat ik ik daar iets fout gedaan heb met copy/'paste tags', bij het ontdubbelen van dat KP. Verder kan ik melden dat, wat je daar ziet een perfecte demonstratie is van wat ik dus 'tentakels' ben gaan noemen. Alle leden van routerelaties tussen twee knooppunten met hetzelfde rcn_ref nummer die een role forward of backward hebben, leiden een fietser van het ene KP naar het eigenlijke begin van de fietsroute. In dit geval is elk zo'n beginpunt ook een eindpunt, maar dat is niet altijd het geval. Enkel de eindpunten (waar een route toekomt, krijgt zo'n rcn_ref). Eimai, gelieve te bevestigen. Als het niet zo is, dan moet dat gewijzigd worden op de wiki, want ik heb dat daar expliciet zo beschreven. mvg, Jo Het moet waarschijnlijk nog gecorrigeerd worden, ik had ook niet vanaf het begin begrepen wat de beste werkwijze was en hier en daar heb ik ook 1 knooppunt aangemaakt, waar ik er nu wel 2, 3 of 4 zou opsplitsen. Ik kijk er straks even naar. Op 24 november 2011 15:21 schreef Marc Gemis marc.ge...@gmail.com het volgende: Ik heb nog nooit op de bordjes voor fietsenknooppunten gelet. Vanwege de discussie hier heb ik eens gekeken hier in de buurt http://www.openstreetmap.org/?lat=51.073425lon=4.424868zoom=18layers=M Knooppunt 51 heeft bordjes aan beide zijde van de Nete. Er zijn 2 knopen met rcn_ref 51. In OSM loopt Route 51-21 steeds over de brug, terwijl dit niet nodig als je 50-51-21 wil volgen. Ik weet niet hoe een routebegeleidingssysteem de huidige data zou interpreteren. Zou dit niet op de een of andere manier moeten gecorrigeerd/aangepast worden worden ? Hetzelfde probleem treedt op bij de brug over de Dijle net ten zuiden van de vorige brug Gelukkig voor mij zijn er wel afzonderlijke knooppunten voor het wandelnetwerk daar ;-) Marc ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fwd: [OSM-talk-fr] StreetView?
2011/11/24 Gerard Vanderveken g...@ghia.eu: People tend to judge the book by the cover and not by the content. In this respect OSM is no match to StreetView. So, we should not try to profilate us against it. It will only cause disbelief and leaves OSM with a stamp of inferiority, because there is not the bling bling of StreetView. I think you are right. There are other opportunities, which are more suitable to get attention for OSM and then we can do it with our strong points. One example is trage wegen / voies lentes, which get much attention in many villages and its councels these days. There we can offer advanced mapping en cartography. yes. There are many maps that OSM could help the communes / gemeente to draw right. Why not helping them to get much from OSM by giving some of their data to OSM ? If you can't win, don't go to the battle. indeed We need to be creative. -- Nicolas Pettiaux, dr. sc - gsm : 0496 24 55 01 ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en egrijpelijke misverstanden eromheen
Ik vind het hele gedoe met die tentakels een zeer hoog absurdistan gehalte hebben. Een route is simpelweg een aaneenschakeling van wegen tussen 2 punten: beginpunt A en eindpunt B. Een speciaal geval is wanneer A en B hetzelfde punt zijn, dan heb je een omloop. Dat het trajekt van A naar B verschillend kan zijn van het trajekt van B naar A is al genoeg komplikatie, maar daar zijn de forward en backward rollen voor. Maar wanneer je in 1 route 3 begin- en 3 eindpunten begint te mappen en bovendien bestaan er soms ook nog eens verschillende paden voor de heen- en terugweg, dan ben je volgens mij toch niet goed bezig. Eigenlijk prop je dan een tiental routes in 1 relatie. Met zo'n relatie kan je echt niks aanvangen. Daar kan je geen GPX of routing mee samenstellen zonder alle deelnemende straten te gaan analyseren en op die set een eigen routing te gaan toepassen om te zien welke wegen moeten behouden of uitgesloten worden. Dan getuigt de aanpak op fietsnet.be toch wel van een meer realistischer en pragmatischer kijk op de dingen, die dan ook praktisch en makkelijk bruikbaar is. - Apart houden waar het moet, zie het hier onder aangehaalde voorbeeld: http://www.openstreetmap.org/?lat=51.069lon=4.42439zoom=15layers=Crelation=9754 Op fietsnet zijn er 2 losse routes tussen de 3 in lijn liggende knopen met nr 52 en ook 1 tussen de 2 knooppunten 51. - Samenvoegen waar het kan: vb knooppunt 90 wat lager op de Zenne. http://www.openstreetmap.org/?lat=51.03433lon=4.42266zoom=16layers=Crelation=9754 Bij fietsnet is er maar 1 knoop en die ligt gewoon midden op de brug. (Hier onbreekt blijkbaar in OSM wel nog de verbinding tussen de 2 knopen nr 90 over de daar aanwezige voetgangers- (+fietsers-?)brug.) Wanneer twee of drie knoopunten zeer kort bij mekaar liggen, kies gewoon ergens 1 punt en maak dat het knooppunt. Bvb op het middenbeen van een T of een arbitraire arm op een rondpunt. Zoals hier http://www.openstreetmap.org/?lat=51.15636lon=4.2292zoom=17layers=Crelation=9754 Leid daarna alle routes van de nabuurpunten naar dat punt. Want eigelijk is er ook maar een knooppunt. Dat de resulterende aaneengeschakelde routes hierdoor een kleine krul kunnen bevatten vind ik dan nog niet eens zo erg. Die omweg is de prijs die de mensen betalen, die blindelings hun GPS volgen zonder zelf maar een poging te doen van op de bordjes te letten. Alternatief is dat je voor mikro-mapping gaat en alle 'losse' knooppunten met hetzelfde nummer gaat mappen, maar dan dien je ook voor deze kort bij elkaar liggende punten de aparte routetjes te worden voorzien. In het voorbeeld van knoop 98 worden dat dan 3 aparte routetjes (er zijn blijkbaar geen eenrichtingsbaantjes of verplichte rijrichtingen bij) elk op hun zijde van de driehoek. Ik weet dat ik nogal skeptisch was tegen de aanpak van Polyglot die het eerst op die wijze implementeerde, vooral skeptisch dan op de zin ervan. Is zo'n fijn detail niet overdreven of wel nodig? Dat gevoel heb ik nog steeds, maar als er dan toch meerdere knopen voor 1 nummer gemapt worden, dan is het voor mij de enige goede manier en zeker stukken beter dan die tentakels. Gewoon een waardeloos systeem! Op die manier wordt OSM nooit praktisch bruikbaar om sites a la fietsnet op te zetten. Ook met de definities voor de rollen forward en backward heb ik het moeilijk. Die zijn voor mij ook absurd en zorgen enkel voor komplikatie zonder echt iets toe te voegen. Ik heb ook de indruk dat het dateert uit de tijd dat er nog geen volgorde kon worden gegeven (of behouden worden) aan de leden in een relatie. Wat betekent een rol hebben in een relatie? Het betekent dat je als element in een relatie deelneemt, maar niet op dezelfde wijze als een ander element. Een 'way' in een gebied kan zowel een stuk van de buitenkant of van een enclave zijn. Daar geeft de rol outer of inner perfekt weer wat een bepaalde way komt doen in de relatie. Voor een route die in principe zowel van A naar B als van B naar A kan gevolgd worden, is het te volgen pad voor heen en terug meestal gelijk. Wanneer er eenrichtingswegen inzitten ontstaat er een verschillend pad voor die heen- en terugweg. Er zitten dus drie verschillende wegen in de relatie. Wegen die een rol spelen voor beide richtingen, of alleen in de heen-, of in de terugrichting worden gebruikt. Logischerwijs krijgt de heenrichting van A naar B de rol forward en de terugweg van B naar A backward. Een lege rol is niets speciaals en daar wordt de weg in beide richtingen gebruikt. Heel simpel. Moet je een route in een GPX gieten neem je gewoon de leden met een lege rol, aangevuld met de leden met of de rol forward voor de heenrichting, of de rol backward voor de andere richting. Ook heel simpel uit te sorteren en gemakkelijk. Maar het door de Wiki voorgestelde systeem heeft gemeend te moeten rekening houden met de richting van de onderliggende weg en daar dan een rol aan toe te kennen. If a route should only be
Re: [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Op 24-11-11 heeft Gerard Vandervekeng...@ghia.eu het volgende geschreven: Ik vind het hele gedoe met die tentakels een zeer hoog absurdistan gehalte hebben. Een route is simpelweg een aaneenschakeling van wegen tussen 2 punten: beginpunt A en eindpunt B. Een speciaal geval is wanneer A en B hetzelfde punt zijn, dan heb je een omloop. Dat het trajekt van A naar B verschillend kan zijn van het trajekt van B naar A is al genoeg komplikatie, maar daar zijn de forward en backward rollen voor. Maar wanneer je in 1 route 3 begin- en 3 eindpunten begint te mappen en bovendien bestaan er soms ook nog eens verschillende paden voor de heen- en terugweg, dan ben je volgens mij toch niet goed bezig. Eigenlijk prop je dan een tiental routes in 1 relatie. Met zo'n relatie kan je echt niks aanvangen. Daar kan je geen GPX of routing mee samenstellen zonder alle deelnemende straten te gaan analyseren en op die set een eigen routing te gaan toepassen om te zien welke wegen moeten behouden of uitgesloten worden. Dan getuigt de aanpak op fietsnet.be toch wel van een meer realistischer en pragmatischer kijk op de dingen, die dan ook praktisch en makkelijk bruikbaar is. - Apart houden waar het moet, zie het hier onder aangehaalde voorbeeld: http://www.openstreetmap.org/?lat=51.069lon=4.42439zoom=15layers=Crelation=9754 Op fietsnet zijn er 2 losse routes tussen de 3 in lijn liggende knopen met nr 52 en ook 1 tussen de 2 knooppunten 51. - Samenvoegen waar het kan: vb knooppunt 90 wat lager op de Zenne. http://www.openstreetmap.org/?lat=51.03433lon=4.42266zoom=16layers=Crelation=9754 Bij fietsnet is er maar 1 knoop en die ligt gewoon midden op de brug. (Hier onbreekt blijkbaar in OSM wel nog de verbinding tussen de 2 knopen nr 90 over de daar aanwezige voetgangers- (+fietsers-?)brug.) Wanneer twee of drie knoopunten zeer kort bij mekaar liggen, kies gewoon ergens 1 punt en maak dat het knooppunt. Bvb op het middenbeen van een T of een arbitraire arm op een rondpunt. Zoals hier http://www.openstreetmap.org/?lat=51.15636lon=4.2292zoom=17layers=Crelation=9754 Leid daarna alle routes van de nabuurpunten naar dat punt. Want eigelijk is er ook maar een knooppunt. Dat de resulterende aaneengeschakelde routes hierdoor een kleine krul kunnen bevatten vind ik dan nog niet eens zo erg. Die omweg is de prijs die de mensen betalen, die blindelings hun GPS volgen zonder zelf maar een poging te doen van op de bordjes te letten. Alternatief is dat je voor mikro-mapping gaat en alle 'losse' knooppunten met hetzelfde nummer gaat mappen, maar dan dien je ook voor deze kort bij elkaar liggende punten de aparte routetjes te worden voorzien. In het voorbeeld van knoop 98 worden dat dan 3 aparte routetjes (er zijn blijkbaar geen eenrichtingsbaantjes of verplichte rijrichtingen bij) elk op hun zijde van de driehoek. Ik weet dat ik nogal skeptisch was tegen de aanpak van Polyglot die het eerst op die wijze implementeerde, vooral skeptisch dan op de zin ervan. Is zo'n fijn detail niet overdreven of wel nodig? Dat gevoel heb ik nog steeds, maar als er dan toch meerdere knopen voor 1 nummer gemapt worden, dan is het voor mij de enige goede manier en zeker stukken beter dan die tentakels. Gewoon een waardeloos systeem! Op die manier wordt OSM nooit praktisch bruikbaar om sites a la fietsnet op te zetten. Ook met de definities voor de rollen forward en backward heb ik het moeilijk. Die zijn voor mij ook absurd en zorgen enkel voor komplikatie zonder echt iets toe te voegen. Ik heb ook de indruk dat het dateert uit de tijd dat er nog geen volgorde kon worden gegeven (of behouden worden) aan de leden in een relatie. Wat betekent een rol hebben in een relatie? Het betekent dat je als element in een relatie deelneemt, maar niet op dezelfde wijze als een ander element. Een 'way' in een gebied kan zowel een stuk van de buitenkant of van een enclave zijn. Daar geeft de rol outer of inner perfekt weer wat een bepaalde way komt doen in de relatie. Voor een route die in principe zowel van A naar B als van B naar A kan gevolgd worden, is het te volgen pad voor heen en terug meestal gelijk. Wanneer er eenrichtingswegen inzitten ontstaat er een verschillend pad voor die heen- en terugweg. Er zitten dus drie verschillende wegen in de relatie. Wegen die een rol spelen voor beide richtingen, of alleen in de heen-, of in de terugrichting worden gebruikt. Logischerwijs krijgt de heenrichting van A naar B de rol forward en de terugweg van B naar A backward. Een lege rol is niets speciaals en daar wordt de weg in beide richtingen gebruikt. Heel simpel. Moet je een route in een GPX gieten neem je gewoon de leden met een lege rol, aangevuld met de leden met of de rol forward voor de heenrichting, of de rol backward voor de andere richting. Ook heel simpel uit te sorteren en gemakkelijk. Maar het door de Wiki voorgestelde systeem heeft gemeend te moeten rekening houden met de richting
Re: [OSM-talk-be] [OSM-talk-nl] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Ik ben al wel situaties tegengekomen waar ook het systeem met de tentakels het moeilijk mee heeft, maar er is geen enkel systeem dat voor die situatie een sluitende of betere oplossing biedt. Het gaat dan om knooppunten in de buurt van sluizen, waar of de ene of de andere sluis openstaat en de route dus daarvan afhangt. Verder is er in Oostende een stel bruggen met een gelijkaardige situatie, maar dan op de route, niet tussen de gesplitste knooppunten in. Het is zeer waarschijnlijk dat er in Nederland ook van dat soort situaties gevonden kunnen worden. Voor de eerstgenoemde sluizen heb ik gewoon zeer pragmatisch twee routes aangelegd, die dan heel wat leden gemeenschappelijk hebben. Voor de situatie in Oostende heb ik me van de tweede brug niets aangetrokken... ofwel stuikt er daar dus iemand binnenkort in het water, of blijft daar een paar uur voor een gesloten brug staan, totdat ze zien dat de kusttram wel aan de overkant geraakt... Ook voor de route van de kusttram zat ik daar trouwens met een probleem. Ik zie nu dat het daar ook om een grote sluis gaat. de Demeysluis. Mijn probleem is dat ik niet altijd ter plaatse kan gaan om te gaan kijken welke bordjes er nu eigenlijk staan, vandaar dat ik tracht om simpele eenduidige regeltjes gedefinieerd te krijgen, zoals zet een rcn_ref op alle eindpunten van een routerelatie en verbind dan alle gelijkgenummerde knooppunten met tentakels voorzien van roles om de fietsers vanaf elk ander gesplitst KP naar de eigenlijke start van de route te krijgen. Ik heb dat zelf niet bedacht, maar tracht gewoon om te beschrijven wat ik slechts mits een vrij grote inspanning geleerd heb, zodat anderen het hopelijk makkelijker hebben om het te snappen. Ik heb Koen van Fietsnet ook om zijn opinie gevraagd, maar het kan wel enkele dagen duren eer hij antwoord geeft. Met name dus de vraag of dit systeem geschikt is om mee aan de slag te gaan voor zijn routering. mvg, Jo Op 24 november 2011 21:37 schreef Jeroen Muris jer...@tweejee.net het volgende: Beste mede-mappers, Hierbij wat willekeurige gedachten van mij over de wijze waarop fietsknooppuntennetwerken worden getagd. Wat mij betreft is de oplossing met de 'tentakels' werkbaar, sluitend en uit wat er te zien is in het terrein af te leiden. Ik denk dat de oplossing met 'tentakels' werkbaar is. Voorheen heb ik mij bij de wat ingewikkelder knooppunten - en die zijn er voldoende in mijn omgeving - in allerlei bochten moeten wringen. Na de uitgebreide uitleg enige weken terug [1] en enige gewenning blijkt het voor mij in de meeste gevallen mogelijk vrij eenvoudig de routes samen te stellen. Hoewel ik dat niet met 100% zekerheid weet, geloof ik dat alle denkbare situaties met de op de wiki beschreven werkwijze zijn vorm te geven. Ik ben in ieder geval nog geen voorbeeld tegengekomen, en ik heb ik al wel het een en ander gezien (bijvoorbeeld [2a,2b]). Map what you see. Wanneer ik bij een (enkel~ of meervoudig) knooppunt aankom kom ik voordat ik bij een eventueel paneel kom vrijwel altijd een bordje tegen met het knooppuntnummer en de richtingen naar de aansluitende knoopunten. Afhankelijk van de te nemen route kan ik vanaf dat punt het nieuwe nummer volgen. Uit mijn ervaring blijkt dat - in ieder geval in mijn omgeving - bij veel knooppunten een paneel ontbreekt. Op basis van taggen wat je ziet en de keuze voor één node op de plek van het paneel zou er in die situaties geheel geen knooppunt zijn ;-). De wijze van gebruik van forward/backward heeft bij mij in eerste instantie ook voor verwarring gezorgd [3]. En nog is er ook wat voor te zeggen om het anders te doen, maar als de hele wereld het nu zo doet... (Overigens heb ik een niet bevestigd gevoel dat Jo's script in sommige gevallen moeite heeft met role=backward, maar dat terzijde). Het is waar dat bij een meervoudig knooppunt, met meerdere als knooppunt getagde nodes, alle nodes als POI in de GPS te zien zullen zijn. Maar is het kiezen van één om heen te navigeren niet net zo willekeurig als naar het paneel navigeren? Als je op het knooppunt aankomt zul je in beide gevallen je hoofd en/of de aanwezige bordjes moeten gebruiken. En zou het niet mogelijk zijn bij het aanmaken van je POI bestand de knooppunten uit te dunnen? ... Hier wil ik het nu bij laten. Hoop dat bovenstaande iets bijdraagt in de gedachtenvorming. Vriendelijke groet, J-. [1] http://lists.openstreetmap.**org/pipermail/talk-nl/2011-** October/013200.htmlhttp://lists.openstreetmap.org/pipermail/talk-nl/2011-October/013200.html [2a] http://www.openstreetmap.org/**browse/relation/1166853http://www.openstreetmap.org/browse/relation/1166853 [2b] http://dl.dropbox.com/u/**20232727/Rdam60-61.jpghttp://dl.dropbox.com/u/20232727/Rdam60-61.jpg [3] http://lists.openstreetmap.**org/pipermail/talk-nl/2010-** July/011250.htmlhttp://lists.openstreetmap.org/pipermail/talk-nl/2010-July/011250.html __**_ Talk-nl
Re: [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en egrijpelijke misverstanden eromheen
On Thursday 24 November 2011 20:07:20 Gerard Vanderveken wrote: Ik vind het hele gedoe met die tentakels een zeer hoog absurdistan gehalte hebben. Een route is simpelweg een aaneenschakeling van wegen tussen 2 punten: beginpunt A en eindpunt B. Een speciaal geval is wanneer A en B hetzelfde punt zijn, dan heb je een omloop. Dat het trajekt van A naar B verschillend kan zijn van het trajekt van B naar A is al genoeg komplikatie, maar daar zijn de forward en backward rollen voor. Maar wanneer je in 1 route 3 begin- en 3 eindpunten begint te mappen en bovendien bestaan er soms ook nog eens verschillende paden voor de heen- en terugweg, dan ben je volgens mij toch niet goed bezig. Eigenlijk prop je dan een tiental routes in 1 relatie. Met zo'n relatie kan je echt niks aanvangen. Daar kan je geen GPX of routing mee samenstellen zonder alle deelnemende straten te gaan analyseren en op die set een eigen routing te gaan toepassen om te zien welke wegen moeten behouden of uitgesloten worden. Met wat je van fietsnet krijgt kan je soms niks aanvangen; de OSM-methode mapt de realiteit en bijgevolg laat die je ook niet een halve kilometer omrijden in sommige gevallen zoals fietsnet. Dan getuigt de aanpak op fietsnet.be toch wel van een meer realistischer en pragmatischer kijk op de dingen, die dan ook praktisch en makkelijk bruikbaar is. Fietsnet wil vooral een mooi prentje geven, die zitten helemaal niet bezig met onderliggende data. Wij hebben de wegen wel in onze database en dus kunnen we ervan gebruik maken om exact te mappen hoe het nu in werkelijkheid zit, en die is complexer dan een lijntje dat twee punten met elkaar verbindt. Het vergt wat meer berekenen maar je GPX die je via OSM kan maken zal een stuk nauwkeurigere info geven. Het is alleen bij mijn weten nog niet geïmplementeerd, maar laat dat nu geen reden te zijn om het slecht te vinden. Wanneer twee of drie knoopunten zeer kort bij mekaar liggen, kies gewoon ergens 1 punt en maak dat het knooppunt. Bvb op het middenbeen van een T of een arbitraire arm op een rondpunt. Zoals hier http://www.openstreetmap.org/?lat=51.15636lon=4.2292zoom=17layers=Crela tion=9754 Leid daarna alle routes van de nabuurpunten naar dat punt. Want eigelijk is er ook maar een knooppunt. Dat de resulterende aaneengeschakelde routes hierdoor een kleine krul kunnen bevatten vind ik dan nog niet eens zo erg. Die omweg is de prijs die de mensen betalen, die blindelings hun GPS volgen zonder zelf maar een poging te doen van op de bordjes te letten. Alternatief is dat je voor mikro-mapping gaat en alle 'losse' knooppunten met hetzelfde nummer gaat mappen, maar dan dien je ook voor deze kort bij elkaar liggende punten de aparte routetjes te worden voorzien. In het voorbeeld van knoop 98 worden dat dan 3 aparte routetjes (er zijn blijkbaar geen eenrichtingsbaantjes of verplichte rijrichtingen bij) elk op hun zijde van de driehoek. Jij gaat de weg in die Jo eerst volgde precies, tot die het licht zag :-) Ik weet dat ik nogal skeptisch was tegen de aanpak van Polyglot die het eerst op die wijze implementeerde, vooral skeptisch dan op de zin ervan. Is zo'n fijn detail niet overdreven of wel nodig? Als mensen er moeite in willen steken om een dergelijk fijn detail te mappen, waarom niet? 't Is niet alsof andere mensen daar last van hebben... Dat gevoel heb ik nog steeds, maar als er dan toch meerdere knopen voor 1 nummer gemapt worden, dan is het voor mij de enige goede manier en zeker stukken beter dan die tentakels. Gewoon een waardeloos systeem! Op die manier wordt OSM nooit praktisch bruikbaar om sites a la fietsnet op te zetten. Ook met de definities voor de rollen forward en backward heb ik het moeilijk. Die zijn voor mij ook absurd en zorgen enkel voor komplikatie zonder echt iets toe te voegen. Ik heb ook de indruk dat het dateert uit de tijd dat er nog geen volgorde kon worden gegeven (of behouden worden) aan de leden in een relatie. Wat betekent een rol hebben in een relatie? Het betekent dat je als element in een relatie deelneemt, maar niet op dezelfde wijze als een ander element. Een 'way' in een gebied kan zowel een stuk van de buitenkant of van een enclave zijn. Daar geeft de rol outer of inner perfekt weer wat een bepaalde way komt doen in de relatie. Voor een route die in principe zowel van A naar B als van B naar A kan gevolgd worden, is het te volgen pad voor heen en terug meestal gelijk. Wanneer er eenrichtingswegen inzitten ontstaat er een verschillend pad voor die heen- en terugweg. Er zitten dus drie verschillende wegen in de relatie. Wegen die een rol spelen voor beide richtingen, of alleen in de heen-, of in de terugrichting worden gebruikt. Logischerwijs krijgt de heenrichting van A naar B de rol forward en de terugweg van B naar A backward. Een lege rol is niets speciaals en daar wordt de weg in beide richtingen gebruikt. Heel simpel. Die forward/backward is al
[OSM-talk] Osm to distribute south africa geodata
Sharing this news: http://afrispatial.co.za/open-data/osm-to-become-a-distributor-of-ngis-south-african-topo-data/ South Africa, NGI [1] is in the process of signing an agreement with OSM [2]. It is a modified version of NGI’s standard ‘Map Data Services Provider’ agreement whereby third parties can distribute NGI data. What this means is that OSM will incorporate all the most recent South African topographical vector data from NGI. NGI data have been free and open for several years but this will make them accessible as never before. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osm to distribute south africa geodata
Hi, On 11/25/2011 01:29 AM, maning sambale wrote: Sharing this news: http://afrispatial.co.za/open-data/osm-to-become-a-distributor-of-ngis-south-african-topo-data/ Must be a misunderstanding. OSM is not in the business of distributing other geodata than our own. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osm to distribute south africa geodata
Anyone can be an OSM contributor. Including South Africa's Department of Rural Development and Land Reform, if they so desire. Steve On 25/11/2011 00:41, Frederik Ramm wrote: Hi, On 11/25/2011 01:29 AM, maning sambale wrote: Sharing this news: http://afrispatial.co.za/open-data/osm-to-become-a-distributor-of-ngis-south-african-topo-data/ Must be a misunderstanding. OSM is not in the business of distributing other geodata than our own. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Osm to distribute south africa geodata
On 25.11.2011 01:29, maning sambale wrote: Sharing this news: http://afrispatial.co.za/open-data/osm-to-become-a-distributor-of-ngis-south-african-topo-data/ sounds like another massive data import. Is the community involved? http://wiki.openstreetmap.org/wiki/WikiProject_South_Africa Stephan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Ik heb net deze conversatie gehad met Jan:
Dag Jo,
Zou je even willen kijken naar FRN SRAN relatie 957169 (25-26). Je
controle pagina geeft aan forward continuous / backward NOT continuous.
Er is echter niets mis met de forward/backward rollen in deze relatie.
Ik denk dat het ligt aan way 61319667 (een fietspad bij de kruising die in
twee richtingen te befietsen is; i.t.t. de anderen bij deze kruising als ik
het me goed herinner). Deze heeft in relatie 957169 als enige stukje een
role=backward. En dat moet ook.
Er zijn drie verschillende routes die gebruik maken van fietspad 61319667.
Een (26-98) gebruikt het in beide richtingen; een (26-27) in dezelfde
richting als de tekenrichting (role=forward) en een (25-26) in
tegengestelde richting (=backward).
Het staat in OSM zoals het ook in de werkelijkheid is bewegwijzerd. (Voor
de goede orde, het fietspad langs de Van Elkweg vanaf knooppunt De Heister
naar het zuid-oost is een tweerichting fietspad en 26 naar 25 gaat daar
langs (naar 'beneden'); maar 25 naar 26 ('omhoog') is bewegwijzerd langs
het fietspad aan de andere kant van de Van Elkweg).
Dit is een voorbeeld waar het niet handig is om de tekenrichting van een
weg om te draaien om forward/backward op te lossen (of in ieder geval het
zal niets uitmaken want dan heeft de ander relatie een 'probleem').
Ik denk dat de forward/backward logica die je gebruikt niet berekend is op
alle situaties en dus niet correct staat op je controle pagina. Dat kan
voor meer van die relaties gelden (ik heb ze niet onderzocht).
Als het niet duidelijk is, mij even berichten.
Groeten,
Frank
Jo
01:55 (10 uren geleden)
Ik heb er naar gekeken en mijn conclusie is dat die node (26)
gesplitst moet worden. Ik ga dat dus even doen en dan laat je me
achteraf maar weten of je daarmee kan leven.
Jo
Op 24 november 2011 01:49 heeft Frankl2009 frankl2...@xs4all.nl het
volgende geschreven:
Jo
02:07 (9 uren geleden)
aan Frankl2009
De node is nu gesplitst in 3 nodes. Eén voor elk punt waar een route
met als begin-/eindpunt KP 26 toekomt.
25-26 is aangepast. Het stuk dat jij een role backward had gegeven
hoort eigenlijk niet bij 25-26. Het stuk dat van de route die uit het
westen komt, zit er dan weer wel bij. Verder heb ik een paar wegen van
volgorde moeten veranderen. Om dat soort dingen te doen, is JOSM echt
veel beter geschikt. Op het tentakel na, zou die de leden van die
relatie zelfs in jouw plaats kunnen sorteren. Met het tentakel bedoel
ik dat stukje dat van het einde van de route uit het westen, naar het
eigenlijke begin van 26-25 leidt. (Ik heb de cijfers met opzet even
omgewisseld).
Nu ga ik de andere routes nakijken die op KP 26 toekomen.
Jo
02:34 (9 uren geleden)
aan Frankl2009
Ik had te laat gezien dat er ook nog een vierde route op dat knooppunt
toekomt, dus heb ik één van de nodes van het gesplitste KP moeten
aanpassen en dat heeft z'n weerslag op alle 3 de routes waar ik van
dacht dat ze al klaar waren.
Dit is vanaf nu dus één van de meer ingewikkelde knooppunten in het
netwerk geworden. Als je er één wilt zien dat nog wat complexer is,
kijk dan hier eens:
http://www.openstreetmap.org/?lat=51.18752lon=4.40465zoom=17layers=M
Dat is het knooppunt waar ik op geleerd heb, hoe het moet met
gesplitste knooppunten en de 'tentakels' die ze veroorzaken. Ik hoop
dat ik het nu correct geleerd heb, anders zijn er massaal veel
knooppunten die (nog) niet in orde zijn.
mvg,
Jo
Op 24 november 2011 02:07 heeft Jo winfi...@gmail.com het volgende
geschreven:
Frankl2009 frankl2...@xs4all.nl
10:33 (1 uur geleden)
aan mij
Nee, Joe, doe dat maar niet (splitsen). Er is daar GEEN gesplitst node
(i.t.t. sommige locaties waar er inderdaad twee nodes te vinden zijn).
Volgt aub de werkelijkheid en niet denkbeeldige constructies.
Je zult dus rekening moeten houden van situaties zoals ik al had geschetst.
Mocht je dit ondertussen wel gedaan hebt, aub terugdraaien.
Groeten,
frank
- Original Message - From: Jo winfi...@gmail.com
To: Frankl2009 frankl2...@xs4all.nl
Sent: Thursday, November 24, 2011 1:55 AM
Subject: Re: FRN SRAN Vraag over werkwijze controle
Frankl2009 frankl2...@xs4all.nl
10:41 (1 uur geleden)
aan mij
Nee, nee, driewerf, nee. Ik verzet me tegen dit soort constructies.
Als we zo te werk willen gaan op zijn minst moet er eerst toch enige
overeenstemming zijn dat we het zo gaan doen. Maak dan als je het echt wil
eerst een voorstel (maar niet meteen implementeren op de wiki, aub) en
kijken of men er voor te vinden is.
Let wel op dat dit bij vele (complexe) kruisingen met fietspaden die
tevens knooppunt zijn zal moeten gebeuren.
Ik ben er niet voor omdat het de map what you see principe helemaal
loslaat. Wij zien in het veld maar één node in het FRN SRAN bij zo'n
kruising. Om te komen bij zo'n infopaneel moet je geleid worden zoals de
verkeerregels dat toestaan. En er moet voldoende intelligentie zijn in
[OSM-talk-nl] buslijnen in Zuid-Limburg
Niemand die mij van advies kan dienen? Dan begin ik maar eens en hoop niet te veel rotzooi te trappen. Als ik tijd en energie wil steken in het opvoeren/aanleggen van de buslijnen van het streekvervoer in Zuid-Limburg in OSM, waar moet ik dan op letten? De wiki vind ik niet al te duidelijk, ik vind het niet helder of ik nu een stop of een platform moet gebruiken en wanneer welke. Volgens mij zijn nog niet eens de busstops in deze streek terug te vinden in OSM. Hoe dit gedegen op te zetten? Deze link heb ik ook al gevonden. Ik neem aan dat mijn in te voeren buslijnen ook in dit overzicht opgenomen zouden moeten worden. Is er een goed voorbeeld dat ik in JOSM kan openen om eens een goed idee te krijgen hoe ik een relatie opbouw om een buslijn op te zetten? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] De geschiedenis van Amsterdam
Hmm, ik sta er helemaal niet op, waarom is dat? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] buslijnen in Zuid-Limburg
Het spijt me, ik was van plan om te antwoorden, maar als ik dat niet meteen doe, gaat het uit m'n gedachten. Op 24 november 2011 12:36 schreef Patrick Coenen pe...@live.com het volgende: Niemand die mij van advies kan dienen? Dan begin ik maar eens en hoop niet te veel rotzooi te trappen. A*ls ik tijd en energie wil steken in het opvoeren/aanleggen van de buslijnen van het streekvervoer in Zuid-Limburg in OSM, waar moet ik dan op letten? De wiki vind ik niet al te duidelijk, ik vind het niet helder of ik nu een stop of een platform moet gebruiken en wanneer welke. Volgens mij zijn nog niet eens de busstops in deze streek terug te vinden in OSM. Hoe dit gedegen op te zetten?* Ik was begonnen met nodes (langs de weg, niet als deel van de weg) met highway=bus_stop. Ik heb wel positief gestemd voor het gebruik van het nieuwe schema, maar ik ben er nog niet toe gekomen om dat allemaal om te zetten in Vlaanderen. Ik zet ook geen nodes bij op de ways, voor de stop_position. Ik zie echter wel dat in Nederland nagenoeg alle bushaltes als node die deel uitmaakt van de ways bestaan. Dat zouden in de nieuwe manier van werken dus public_tranportation=stop_position moeten worden en aan weerszijden een node of way met public_transportation=platform. In Vlaanderen heeft De Lijn aan elke halte een uniek referentienummer meegegeven, dat tegenwoordig uit 6 cijfers bestaat (voordien 5), vandaar dat het voor mij voor de hand lag om voor elke halte een eigen node te gebruiken. Een bushalte staat ook naast de weg, vind ik. Ik denk dat in de AND-data de bushaltes als nodes, die deel uitmaken van een weg zitten en dat dat de reden is waarom het in Nederland overwegend zo gedaan is. Ik ga ook eens aan de slag gaan om een mapcss-bestand te maken dat de bushaltes en hun eigenschappen naar voren haalt voor gebruik in JOSM. Onthoud voornamelijk dat je voor elke richting van een buslijn een aparte relatie 'moet' aanmaken. Voor voorbeelden die ik gemaakt heb, kan je elke buslijn nemen die Leuven aandoet (In Vlaanderen wel te verstaan). Op de 178 en 179 na, zitten ze er allemaal volledig in. Ik kijk ze ook regelmatig na (met een script uiteraard) om te zien of ze nog wel helemaal continu van begin naar einde lopen. Al is het ondertussen sinds begin september geleden, dus misschien zijn er hier en daar toch enkele 'stuk'. mvg, Jo * * *Deze link http://wiki.openstreetmap.org/wiki/NL-OV/Bus heb ik ook al gevonden. Ik neem aan dat mijn in te voeren buslijnen ook in dit overzicht opgenomen zouden moeten worden.* * * *Is er een goed voorbeeld dat ik in JOSM kan openen om eens een goed idee te krijgen hoe ik een relatie opbouw om een buslijn op te zetten? * ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] buslijnen in Zuid-Limburg
bus stops dus naast de weg invoegen, en eventueel een stop-positie in/op de weg. Dan een relatie maken met de wegen van de route en de bussstop_positie erbij. Ik zal in Leuven eens gaan kijken naar hoe dan die busstop naast de weg in de relatie wordt opgenomen. Een relatie is uniek naar 1 richting en een master relatie is er voor een verzameling van alle relaties van 1 buslijn bij elkaar. Zo had ik het begrepen. Ik zal beginnen met 1 lijn in de buurt en de busstops en posities eens invoeren. Dan 2 keer een relatie aanleggen voor iedere richting en 1 master relatie voor de buslijn. Ben benieuwd of het gaat lukken en of ik me niet te veel werk op de hals haal. even een noob-vraag: is echt iedereen die relaties maakt in OSM (fietsknooppunten, buslijnen, enz), bezig met nalopen/narijden en zo of is er DB's die gebruikt kan worden zonder al dat gecheck? Is bijvoorbeeld de info van http://nl.haltescan.nl/ te gebruiken? Hier is toch al alle info van buslijnen en busstops al bekend. Date: Thu, 24 Nov 2011 12:48:09 +0100 From: winfi...@gmail.com To: talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] buslijnen in Zuid-Limburg Het spijt me, ik was van plan om te antwoorden, maar als ik dat niet meteen doe, gaat het uit m'n gedachten. Op 24 november 2011 12:36 schreef Patrick Coenen pe...@live.com het volgende: Niemand die mij van advies kan dienen? Dan begin ik maar eens en hoop niet te veel rotzooi te trappen. Als ik tijd en energie wil steken in het opvoeren/aanleggen van de buslijnen van het streekvervoer in Zuid-Limburg in OSM, waar moet ik dan op letten? De wiki vind ik niet al te duidelijk, ik vind het niet helder of ik nu een stop of een platform moet gebruiken en wanneer welke. Volgens mij zijn nog niet eens de busstops in deze streek terug te vinden in OSM. Hoe dit gedegen op te zetten? Ik was begonnen met nodes (langs de weg, niet als deel van de weg) met highway=bus_stop. Ik heb wel positief gestemd voor het gebruik van het nieuwe schema, maar ik ben er nog niet toe gekomen om dat allemaal om te zetten in Vlaanderen. Ik zet ook geen nodes bij op de ways, voor de stop_position. Ik zie echter wel dat in Nederland nagenoeg alle bushaltes als node die deel uitmaakt van de ways bestaan. Dat zouden in de nieuwe manier van werken dus public_tranportation=stop_position moeten worden en aan weerszijden een node of way met public_transportation=platform. In Vlaanderen heeft De Lijn aan elke halte een uniek referentienummer meegegeven, dat tegenwoordig uit 6 cijfers bestaat (voordien 5), vandaar dat het voor mij voor de hand lag om voor elke halte een eigen node te gebruiken. Een bushalte staat ook naast de weg, vind ik. Ik denk dat in de AND-data de bushaltes als nodes, die deel uitmaken van een weg zitten en dat dat de reden is waarom het in Nederland overwegend zo gedaan is. Ik ga ook eens aan de slag gaan om een mapcss-bestand te maken dat de bushaltes en hun eigenschappen naar voren haalt voor gebruik in JOSM. Onthoud voornamelijk dat je voor elke richting van een buslijn een aparte relatie 'moet' aanmaken. Voor voorbeelden die ik gemaakt heb, kan je elke buslijn nemen die Leuven aandoet (In Vlaanderen wel te verstaan). Op de 178 en 179 na, zitten ze er allemaal volledig in. Ik kijk ze ook regelmatig na (met een script uiteraard) om te zien of ze nog wel helemaal continu van begin naar einde lopen. Al is het ondertussen sinds begin september geleden, dus misschien zijn er hier en daar toch enkele 'stuk'. mvg, Jo Deze link heb ik ook al gevonden. Ik neem aan dat mijn in te voeren buslijnen ook in dit overzicht opgenomen zouden moeten worden. Is er een goed voorbeeld dat ik in JOSM kan openen om eens een goed idee te krijgen hoe ik een relatie opbouw om een buslijn op te zetten? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Jo schreef: http://www.openstreetmap.org/?lat=51.18752lon=4.40465zoom=17layers=M Ik denk niet dat Jo hier iets mee te maken heeft, maar even een vraagje... Ik zie daar een weg (de N150) over de snelweg kruisen. Nu had ik begrepen dat in het AND-model er nooit kruisende wegen waren zonder een node op het kruispunt. Hier lijkt dat (in Firefox...) niet zo te zijn. Klopt deze situatie volgens het OSM-model? Christ van Willegen ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
On Thursday 24 November 2011 13:27:55 Christ van Willegen wrote: Jo schreef: http://www.openstreetmap.org/?lat=51.18752lon=4.40465zoom=17layers=M Ik denk niet dat Jo hier iets mee te maken heeft, maar even een vraagje... Ik zie daar een weg (de N150) over de snelweg kruisen. Nu had ik begrepen dat in het AND-model er nooit kruisende wegen waren zonder een node op het kruispunt. Hier lijkt dat (in Firefox...) niet zo te zijn. Klopt deze situatie volgens het OSM-model? Dat is een brug. Bruggen kruisen elkaar nooit in een gemeenschappelijke node, want dan is het een kruispunt... Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Dit kruispunt ligt in België, dus AND heeft er alleszins niets mee te maken. Ik zie nu ook dat het fietspad daar niet over een brug gaat. Geen idee of ik dat zo gedaan heb, als dat zo zou zijn, mijn excuses. Ik heb het nu aangepast Jo Op 24 november 2011 13:27 schreef Christ van Willegen cvwille...@gmail.comhet volgende: Jo schreef: http://www.openstreetmap.org/?lat=51.18752lon=4.40465zoom=17layers=M Ik denk niet dat Jo hier iets mee te maken heeft, maar even een vraagje... Ik zie daar een weg (de N150) over de snelweg kruisen. Nu had ik begrepen dat in het AND-model er nooit kruisende wegen waren zonder een node op het kruispunt. Hier lijkt dat (in Firefox...) niet zo te zijn. Klopt deze situatie volgens het OSM-model? Christ van Willegen ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] De geschiedenis van Amsterdam
He fair improver, Toch wel, de balk boven paulbe. Gr, Floris 2011/11/24 Meeuw d...@mrns.nl: Hmm, ik sta er helemaal niet op, waarom is dat? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
On Thursday 24 November 2011 12:32:39 Jo wrote: ... mvg, Jo TL;DR? :-p Als ik het in het snel doorlezen een beetje heb begrepen wat het probleem is, namelijk dat er maar één overzichtsbord staat in NL op het knooppunt, en dat dan door die Jan beschouwd wordt als het knooppunt met rcn_ref en al de rest niet, dan zitten we met het probleem van het halfslachtig bewegwijzeren in NL, waar de knooppuntnummers in enkele netwerken niet worden weergegeven op de bordjes zelf eens je er aankomt, enkel op het grote overzichtsbord (dit is bvb. een knooppunt: http://www.vv.nl/images/upload/knooppunt.jpg ). M.a.w. de plekken waar je de bordjes zoals hierboven tegenkomt zijn de nodes die je tagt met rcn_ref, en je negeert eigenlijk het overzichtsbord (kan je eventueel nog wel anders taggen als je wil). En nu hoop ik dat ik de discussie juist begrepen heb :-) groetjes Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
2011/11/24 Ben Laenen benlae...@gmail.com: Dat is een brug. Bruggen kruisen elkaar nooit in een gemeenschappelijke node, want dan is het een kruispunt... Ik had het subtiel verkeerd onthouden... In de originele AND-data (inderdaad, niets met Belgie te maken...) stonden er dan 2 nodes op dezelfde plek, 1 node tussen de 2 wegdelen onder de brug door, en 1 node tussen de 2 wegdelen er overheen. Had iets te maken met wegen die niet mochten kruisen in de AND data (mocht niet van de data-afnemers oid.) Groeten! Christ -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] buslijnen in Zuid-Limburg
Op 24-11-11 12:59, Patrick Coenen schreef: Is bijvoorbeeld de info van http://nl.haltescan.nl/ te gebruiken? Hier is toch al alle info van buslijnen en busstops al bekend. Ik denk het niet, want dat is gewoon een betaalde dienst. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Die Jan heet Frank. :) Je begrijpt het goed, Ben. Maar het is in FRN SRAN niet een kwestie van halfslachtig bewegwijzering in NL. Wat ik gezien hebt bij SRAN is heel duidelijk bewegwijzerd. Als je door wilt bij aankomst op zo'n kruising staat al aangegeven op een verwijsbord bijvoorbeeld dat je rechtdoor moet, maar als je naar het knooppunt (d.w.z. het infopaneel) wilt, dan linksaf o.i.d. Er staan geen knooppuntborden of panelen bij een tweede, derde, enz. kruising van fietspaden (bij een kruising van wegen) maar een verwijsbord (net zoals alle anderen die je tegenkomt onderweg) die je naar het paneel leidt. De doorverwijzing houdt op als je daar aankomt op het stukje asfalt van de kruisende fietspaden net bij zo'n infopaneel. Eveneens is dat zo voor rotondes (je wordt eromheen geleidt, tenzij er een tweerichting fietspad is gemaakt om direct naar het paneel te komen). Er staat ook meestal niet een verwijsbord in de geest van naar het infopaneel. Alleszins begrijpelijk, dus, dat als je het vastlegt op basis van wat er in het veld te zien is, er maar één rcn_ref wordt gezet, op de kruising van fietspaden bij het infopaneel. Dat je ook kan beargumenteren dat een knooppuntennetwerk een denkbeeldig iets is, en dus de kruising (de rotonde) in zijn geheel als knooppunt te beschouwen is, begrijp ik ook. Het maakt het echter niet eenvoudiger. Groeten, Frank - Original Message - From: Ben Laenen benlae...@gmail.com To: talk...@openstreetmap.org; winfi...@gmail.com Cc: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Sent: Thursday, November 24, 2011 1:58 PM Subject: Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken,hun complexiteit en begrijpelijke misverstanden eromheen On Thursday 24 November 2011 12:32:39 Jo wrote: ... mvg, Jo TL;DR? :-p Als ik het in het snel doorlezen een beetje heb begrepen wat het probleem is, namelijk dat er maar één overzichtsbord staat in NL op het knooppunt, en dat dan door die Jan beschouwd wordt als het knooppunt met rcn_ref en al de rest niet, dan zitten we met het probleem van het halfslachtig bewegwijzeren in NL, waar de knooppuntnummers in enkele netwerken niet worden weergegeven op de bordjes zelf eens je er aankomt, enkel op het grote overzichtsbord (dit is bvb. een knooppunt: http://www.vv.nl/images/upload/knooppunt.jpg ). M.a.w. de plekken waar je de bordjes zoals hierboven tegenkomt zijn de nodes die je tagt met rcn_ref, en je negeert eigenlijk het overzichtsbord (kan je eventueel nog wel anders taggen als je wil). En nu hoop ik dat ik de discussie juist begrepen heb :-) groetjes Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] buslijnen in Zuid-Limburg
Ik denk niet dat er vele anderen bezig zijn met 'gecheck'. Het vraagt een
vrij intensieve manier van onderzoeken hoe alles in elkaar zit en vanalles
uitproberen om plugins te installeren, uit te testen, te exploreren wat de
mogelijkheden zijn e.d.
Zo ben ik dus bij die Scripting Plugin uitgekomen en heb dan 's gekeken hoe
moeilijk het zou zijn om uit te zoeken of zo'n route continu verloopt. Voor
elke OV-route apart is het vrij eenvoudig om in JOSM visueel vast te
stellen of ze continu is (als er tenminste gekozen werd voor een relatie
per rijrichting), maar als je dat voor een 100-tal of een paar 1000 wilt
beginnen doen, wordt dat al gauw een onmogelijke opgave. Vandaar dus de
automatisering. (En voor mij is het een manier om 'actief' te blijven met
programmeeromgevingen binnen een project dat me nauw aan het hart ligt).
Ik neem ook voortdurend de bus. Al een paar abonnementen 'versleten'. Dus
ben ik enigszins gemotiveerd om die data in OSM te willen krijgen.
Een andere reden is dat ik bij De Lijn (Vlaanderen) het deksel op de neus
heb gekregen, nadat ik de aard van het project had uitgelegd. Volgens hen
omdat we niet voldoende kwaliteit konden garanderen. Het is mijn bedoeling
om binnenkort opnieuw de vraag tot vrijgave van hun haltegegevens te
stellen, maar deze keer op een heel gefundeerde wijze met een volledig
proces dat klaarstaat, om de kwaliteit van onze data te controleren.
En, euh, 1 lijn is niet onoverkomelijk veel werk. Met alle lijnen voor een
kleine stad als Leuven ben ik een paar maanden zoet geweest (niet continu,
zoals tijdens de maand september met de Belgische fietsroutes), maar ik
moet je wel waarschuwen: er kruipt wel degelijk veel werk (en dus tijd) in
(wat voor mij nog een argument erbij is om het in de gaten te blijven
houden, achteraf). Aangezien iedereen met een account wijzigingen aan de
data kan aanbrengen en aangezien alles met elkaar verknoopt is, is het
geheel enigszins 'fragiel'. Veel 'breekbaarder' dan bijvoorbeeld een
wikipedia, ondanks dat ook daar alles met elkaar verbonden is via links
tussen pagina's (en macro's {{ }}).
Oh, nu zie ik dat je het niet had over mijn kwaliteitscontrole, maar wel
over het effectief nemen van de bus of de route van de bus afrijden met bv.
de fiets en overal foto's te maken van de halteborden e.d.
Als je toestemming krijgt van je busmaatschappij om hun data te
(her)gebruiken, dan kan je natuurlijk een soort import doen, maar ik kan je
verzekeren, dat is dus niet zo evident (hier in België toch niet alleszins)
en dan blijft er enkel nog het mappen van de hele zwik op ambachtelijke
wijze over...
Zag ik een bushalte als ik te voet, met de fiets of zelfs te paard onderweg
was (uitzonderlijk er staan niet zoveel bushaltes in het bos of in
boomgaarden), dan nam ik daar een foto van.
Als ik in de bus zat, noteerde ik wanneer we een halte voorbijreden. Stopte
de bus, dan noteerde ik zoveel info als ik kon, vanop het bordje als POI in
m'n htc-GPS. De ene keer de zone, de andere keer de naam, nog een andere
keer het refnummer, enz. Als je foto's begint te nemen vanop de bus, kijken
de mensen wel heel raar op :-) (en die foto's zijn van bijzonder slechte
kwaliteit). Maar over het algemeen heb je toch je handen vrij en sowieso
niet veel anders te doen tijdens zo'n rit met de bus.
Je moet dus eigenlijk beginnen met het ingeven van de haltes en welke
lijnen deze bedienen in route_ref zetten. Dan ga je met Ctrl-f op zoek naar:
route_ref=(;)420(;)
En dan speel je connect the dots om routes aan te maken. Het helpt wel als
je die bus ook al genomen hebt en een GPX-track hebt voor minstens één van
de richtingen. Vooral binnen steden die je niet kent, is het niet altijd
eenvoudig om te weten hoe zo'n bus nu eigenlijk rijdt, maar die zijn dan
eigenlijk voor iemand anders, he.
Als je graag fietst en het is geen lijn van Leuven naar Hamont waar zo'n
bus zelf 3 uur over doet, is het affietsen van de route en foto's maken van
de haltes onderweg nog veruit de beste methode. De eerste route moet je
helemaal doen, maar je zal algauw merken dat er veel buskilometers over
dezelfde stukken asfalt gaan en die moet je dan toch slechts eenmaal doen.
Je mag het me alleszins laten weten als je er eentje 'af' hebt, dan kom ik
graag eens kijken.
mvg,
Jo
Op 24 november 2011 12:59 schreef Patrick Coenen pe...@live.com het
volgende:
bus stops dus naast de weg invoegen, en eventueel een stop-positie in/op
de weg. Dan een relatie maken met de wegen van de route en de
bussstop_positie erbij. Ik zal in Leuven eens gaan kijken naar hoe dan die
busstop naast de weg in de relatie wordt opgenomen. Een relatie is uniek
naar 1 richting en een master relatie is er voor een verzameling van alle
relaties van 1 buslijn bij elkaar. Zo had ik het begrepen. Ik zal beginnen
met 1 lijn in de buurt en de busstops en posities eens invoeren. Dan 2 keer
een relatie aanleggen voor iedere richting en 1 master relatie voor de
buslijn. Ben benieuwd of het gaat lukken en of ik me
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Oei, Frank, ik ben blijkbaar danig in de war als ik je nu al Jan begin te noemen. Hiervoor mijn excuses. Ik hoop dat we hieruit kunnen komen, zonder dat ik heel mijn kwaliteitscontrolescript (nog maar 's) moet beginnen herschrijven. Op dit ogenblik kan het overweg met de situatie met gesplitste knooppunten zoals ik het vannacht heb opgezet. Dat is iets of wat complex, maar routersoftware heeft hiermee wel exact die informatie de ze nodig heeft om fietsers van een knooppunt naar het volgende deel van een route te leiden. Ik zou dus willen vragen: bestudeer het een beetje, laat het wat bezinken en laat het ons weten als je echt niet inziet dat het zo beter is. Dan laat ik Arnhem-Nijmegen gewoon uit de (te creëren) collectie van netwerken in Nederland en dan wordt het maar niet regelmatig nagekeken op continuïteit e.d. Of we leiden alles naar één knooppunt en routersoftware geeft dan maffe instructies van rijd vooruit, rijd even terug, rijd om, e.d. mvg, Jo Op 24 november 2011 14:32 schreef Frankl2009 frankl2...@xs4all.nl het volgende: Die Jan heet Frank. :) Je begrijpt het goed, Ben. Maar het is in FRN SRAN niet een kwestie van halfslachtig bewegwijzering in NL. Wat ik gezien hebt bij SRAN is heel duidelijk bewegwijzerd. Als je door wilt bij aankomst op zo'n kruising staat al aangegeven op een verwijsbord bijvoorbeeld dat je rechtdoor moet, maar als je naar het knooppunt (d.w.z. het infopaneel) wilt, dan linksaf o.i.d. Er staan geen knooppuntborden of panelen bij een tweede, derde, enz. kruising van fietspaden (bij een kruising van wegen) maar een verwijsbord (net zoals alle anderen die je tegenkomt onderweg) die je naar het paneel leidt. De doorverwijzing houdt op als je daar aankomt op het stukje asfalt van de kruisende fietspaden net bij zo'n infopaneel. Eveneens is dat zo voor rotondes (je wordt eromheen geleidt, tenzij er een tweerichting fietspad is gemaakt om direct naar het paneel te komen). Er staat ook meestal niet een verwijsbord in de geest van naar het infopaneel. Alleszins begrijpelijk, dus, dat als je het vastlegt op basis van wat er in het veld te zien is, er maar één rcn_ref wordt gezet, op de kruising van fietspaden bij het infopaneel. Dat je ook kan beargumenteren dat een knooppuntennetwerk een denkbeeldig iets is, en dus de kruising (de rotonde) in zijn geheel als knooppunt te beschouwen is, begrijp ik ook. Het maakt het echter niet eenvoudiger. Groeten, Frank - Original Message - From: Ben Laenen benlae...@gmail.com To: talk...@openstreetmap.org; winfi...@gmail.com Cc: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Sent: Thursday, November 24, 2011 1:58 PM Subject: Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken,hun complexiteit en begrijpelijke misverstanden eromheen On Thursday 24 November 2011 12:32:39 Jo wrote: ... mvg, Jo TL;DR? :-p Als ik het in het snel doorlezen een beetje heb begrepen wat het probleem is, namelijk dat er maar één overzichtsbord staat in NL op het knooppunt, en dat dan door die Jan beschouwd wordt als het knooppunt met rcn_ref en al de rest niet, dan zitten we met het probleem van het halfslachtig bewegwijzeren in NL, waar de knooppuntnummers in enkele netwerken niet worden weergegeven op de bordjes zelf eens je er aankomt, enkel op het grote overzichtsbord (dit is bvb. een knooppunt: http://www.vv.nl/images/**upload/knooppunt.jpghttp://www.vv.nl/images/upload/knooppunt.jpg). M.a.w. de plekken waar je de bordjes zoals hierboven tegenkomt zijn de nodes die je tagt met rcn_ref, en je negeert eigenlijk het overzichtsbord (kan je eventueel nog wel anders taggen als je wil). En nu hoop ik dat ik de discussie juist begrepen heb :-) groetjes Ben __**_ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl __**_ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en egrijpelijke misverstanden eromheen
Een fietsknooppuntennetwerk is sowieso een stuk ingewikkelder dan een wandelknooppuntennetwerk, omwille van éénrichtingsverkeer waar wandelaars geen last van hebben en ook omdat ze hebben ingezien dat het nergens voor nodig is om zich te beperken tot de getallen 01-99 bij het aanleggen van de wandelknooppuntennetwerken in België 3-10 jaar na de FKpNw'en. Het eerste wat ik opmerk, is dat ik daar blijkbaar een rwn_ref van 165 naar 90 heb gewijzigd. Kan je dat 's nakijken? Dat is waarschijnlijk fout. De kans is groot dat ik ik daar iets fout gedaan heb met copy/'paste tags', bij het ontdubbelen van dat KP. Verder kan ik melden dat, wat je daar ziet een perfecte demonstratie is van wat ik dus 'tentakels' ben gaan noemen. Alle leden van routerelaties tussen twee knooppunten met hetzelfde rcn_ref nummer die een role forward of backward hebben, leiden een fietser van het ene KP naar het eigenlijke begin van de fietsroute. In dit geval is elk zo'n beginpunt ook een eindpunt, maar dat is niet altijd het geval. Enkel de eindpunten (waar een route toekomt, krijgt zo'n rcn_ref). Eimai, gelieve te bevestigen. Als het niet zo is, dan moet dat gewijzigd worden op de wiki, want ik heb dat daar expliciet zo beschreven. mvg, Jo Het moet waarschijnlijk nog gecorrigeerd worden, ik had ook niet vanaf het begin begrepen wat de beste werkwijze was en hier en daar heb ik ook 1 knooppunt aangemaakt, waar ik er nu wel 2, 3 of 4 zou opsplitsen. Ik kijk er straks even naar. Op 24 november 2011 15:21 schreef Marc Gemis marc.ge...@gmail.com het volgende: Ik heb nog nooit op de bordjes voor fietsenknooppunten gelet. Vanwege de discussie hier heb ik eens gekeken hier in de buurt http://www.openstreetmap.org/?lat=51.073425lon=4.424868zoom=18layers=M Knooppunt 51 heeft bordjes aan beide zijde van de Nete. Er zijn 2 knopen met rcn_ref 51. In OSM loopt Route 51-21 steeds over de brug, terwijl dit niet nodig als je 50-51-21 wil volgen. Ik weet niet hoe een routebegeleidingssysteem de huidige data zou interpreteren. Zou dit niet op de een of andere manier moeten gecorrigeerd/aangepast worden worden ? Hetzelfde probleem treedt op bij de brug over de Dijle net ten zuiden van de vorige brug Gelukkig voor mij zijn er wel afzonderlijke knooppunten voor het wandelnetwerk daar ;-) Marc ___ Talk-be mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Geen probleem, Jo. Uitkomen doen we zeker (al is de vraag waar dat dan is). Mag ik je opnieuw uitnodigen om ook het nl-forum te bezoeken (alwaar ik je reeds heb aangekondigd). En nogmaals, ik heb liever dat de routeersoftware de nodige intelligentie heeft dan dat we OSM moeten aanpassen ter wille van het routeren. Frank - Original Message - From: Jo To: OpenStreetMap NL discussion list Sent: Thursday, November 24, 2011 3:38 PM Subject: Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen Oei, Frank, ik ben blijkbaar danig in de war als ik je nu al Jan begin te noemen. Hiervoor mijn excuses. Ik hoop dat we hieruit kunnen komen, zonder dat ik heel mijn kwaliteitscontrolescript (nog maar 's) moet beginnen herschrijven. Op dit ogenblik kan het overweg met de situatie met gesplitste knooppunten zoals ik het vannacht heb opgezet. Dat is iets of wat complex, maar routersoftware heeft hiermee wel exact die informatie de ze nodig heeft om fietsers van een knooppunt naar het volgende deel van een route te leiden. Ik zou dus willen vragen: bestudeer het een beetje, laat het wat bezinken en laat het ons weten als je echt niet inziet dat het zo beter is. Dan laat ik Arnhem-Nijmegen gewoon uit de (te creëren) collectie van netwerken in Nederland en dan wordt het maar niet regelmatig nagekeken op continuïteit e.d. Of we leiden alles naar één knooppunt en routersoftware geeft dan maffe instructies van rijd vooruit, rijd even terug, rijd om, e.d. mvg, Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Hallo, even my 10-cents worth. Ik heb deze discussie nu een tijdje aangezien, en behalve dat ik van het tentakel verhaal niet zoveel begrijp, dacht ik dat we mapten wat er in-the-field te vinden was. Dus als er op een knooppunt 1 paaltje of bordje staat, dan zetten we dat dacht ik toch op de kaart. We mappen niet voor router software, die moet z'n eigen broek ophouden, en zorgen dat het werkt met de data zoals aangeleverd. We kunnen dus mappen voor toekomstige oplossingen, die hier wel mee gaan werken, maar dat lijkt me helemaal fout. Als ik nu, met mijn Garmin, van knooppunt naar knooppunt wil rijden, dan kies ik de knooppunten, en vervolgens kijkt mijn apparaat welke route hij wil rijden. Hij doet dus weinig tot niets met de route zoals die in OSM, of op de bordjes langs de weg te zien is. Door nu een knooppunt op te splitsen in meerdere, heb ik plotseling ook meerdere knooppunten om uit de kiezen. Welke is dan de goede ? Ik vind knooppuntennetwerken juist helemaal niet complex, ze zijn opgezet om simpel te zijn. Je rijd van Knooppunt A naar Knooppunt B en volgt daarbij de bordjes langs de route, en houd rekening met de geldende verkeersregels. Simpeler kan volgens mij niet. Maar, zoals gezegd, slechts mijn tien centen. Ik hoop alleen dat de routes hier op Voorne-Putten niet teveel verhaspeld worden, groeten, Piet. Op 24-11-2011 16:49, Frankl2009 schreef: Geen probleem, Jo. Uitkomen doen we zeker (al is de vraag waar dat dan is). Mag ik je opnieuw uitnodigen om ook het nl-forum te bezoeken (alwaar ik je reeds heb aangekondigd). En nogmaals, ik heb liever dat de routeersoftware de nodige intelligentie heeft dan dat we OSM moeten aanpassen ter wille van het routeren. Frank - Original Message - *From:* Jo mailto:winfi...@gmail.com *To:* OpenStreetMap NL discussion list mailto:talk-nl@openstreetmap.org *Sent:* Thursday, November 24, 2011 3:38 PM *Subject:* Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen Oei, Frank, ik ben blijkbaar danig in de war als ik je nu al Jan begin te noemen. Hiervoor mijn excuses. Ik hoop dat we hieruit kunnen komen, zonder dat ik heel mijn kwaliteitscontrolescript (nog maar 's) moet beginnen herschrijven. Op dit ogenblik kan het overweg met de situatie met gesplitste knooppunten zoals ik het vannacht heb opgezet. Dat is iets of wat complex, maar routersoftware heeft hiermee wel exact die informatie de ze nodig heeft om fietsers van een knooppunt naar het volgende deel van een route te leiden. Ik zou dus willen vragen: bestudeer het een beetje, laat het wat bezinken en laat het ons weten als je echt niet inziet dat het zo beter is. Dan laat ik Arnhem-Nijmegen gewoon uit de (te creëren) collectie van netwerken in Nederland en dan wordt het maar niet regelmatig nagekeken op continuïteit e.d. Of we leiden alles naar één knooppunt en routersoftware geeft dan maffe instructies van rijd vooruit, rijd even terug, rijd om, e.d. mvg, Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Jo, Ik denk dat het probleem is dat we eigenlijk geen tentacles hebben (hadden) in FRN SRAN. D.w.z. het manier waarop het FRN is uitgevoerd die oplossing niet nodig heeft gemaakt. SRAN is een van de laatste FRN die is opgezet en in OSM ingebracht, dus het kan zijn dat een aantal problemen die er eerder waren ondertussen op een ander manier nu zijn opgelost (b.v. doorverwijzen naar één punt waar een boord staat?). En als nu de oplossing voor ik vind meerdere knooppunten met eenzelfde nummer in het veld, hoe verbind ik ze in OSM wordt uitgebreid tot hoe ga ik om met complexe wegkruisingen waar er maar één nummer is, geeft dat wat last. Komt wel goed als we even uitzoeken wat er te doen is, dacht ik. Frank - Original Message - From: Jo winfi...@gmail.com To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Sent: Thursday, November 24, 2011 6:11 PM Subject: Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen Ik wil eigenlijk vooral nog even vermelden dat ik dat van die 'tentakels' niet bedacht heb. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Ik denk ook dat we er wel uitkomen, maar ik ben enigszins uitgeblust, vrees ik. Groeten, Jo Op 24-11-11 heeft Frankl2009frankl2...@xs4all.nl het volgende geschreven: Jo, Ik denk dat het probleem is dat we eigenlijk geen tentacles hebben (hadden) in FRN SRAN. D.w.z. het manier waarop het FRN is uitgevoerd die oplossing niet nodig heeft gemaakt. SRAN is een van de laatste FRN die is opgezet en in OSM ingebracht, dus het kan zijn dat een aantal problemen die er eerder waren ondertussen op een ander manier nu zijn opgelost (b.v. doorverwijzen naar één punt waar een boord staat?). En als nu de oplossing voor ik vind meerdere knooppunten met eenzelfde nummer in het veld, hoe verbind ik ze in OSM wordt uitgebreid tot hoe ga ik om met complexe wegkruisingen waar er maar één nummer is, geeft dat wat last. Komt wel goed als we even uitzoeken wat er te doen is, dacht ik. Frank - Original Message - From: Jo winfi...@gmail.com To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Sent: Thursday, November 24, 2011 6:11 PM Subject: Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen Ik wil eigenlijk vooral nog even vermelden dat ik dat van die 'tentakels' niet bedacht heb. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Op 24-11-11 heeft Gerard Vandervekeng...@ghia.eu het volgende geschreven: Ik vind het hele gedoe met die tentakels een zeer hoog absurdistan gehalte hebben. Een route is simpelweg een aaneenschakeling van wegen tussen 2 punten: beginpunt A en eindpunt B. Een speciaal geval is wanneer A en B hetzelfde punt zijn, dan heb je een omloop. Dat het trajekt van A naar B verschillend kan zijn van het trajekt van B naar A is al genoeg komplikatie, maar daar zijn de forward en backward rollen voor. Maar wanneer je in 1 route 3 begin- en 3 eindpunten begint te mappen en bovendien bestaan er soms ook nog eens verschillende paden voor de heen- en terugweg, dan ben je volgens mij toch niet goed bezig. Eigenlijk prop je dan een tiental routes in 1 relatie. Met zo'n relatie kan je echt niks aanvangen. Daar kan je geen GPX of routing mee samenstellen zonder alle deelnemende straten te gaan analyseren en op die set een eigen routing te gaan toepassen om te zien welke wegen moeten behouden of uitgesloten worden. Dan getuigt de aanpak op fietsnet.be toch wel van een meer realistischer en pragmatischer kijk op de dingen, die dan ook praktisch en makkelijk bruikbaar is. - Apart houden waar het moet, zie het hier onder aangehaalde voorbeeld: http://www.openstreetmap.org/?lat=51.069lon=4.42439zoom=15layers=Crelation=9754 Op fietsnet zijn er 2 losse routes tussen de 3 in lijn liggende knopen met nr 52 en ook 1 tussen de 2 knooppunten 51. - Samenvoegen waar het kan: vb knooppunt 90 wat lager op de Zenne. http://www.openstreetmap.org/?lat=51.03433lon=4.42266zoom=16layers=Crelation=9754 Bij fietsnet is er maar 1 knoop en die ligt gewoon midden op de brug. (Hier onbreekt blijkbaar in OSM wel nog de verbinding tussen de 2 knopen nr 90 over de daar aanwezige voetgangers- (+fietsers-?)brug.) Wanneer twee of drie knoopunten zeer kort bij mekaar liggen, kies gewoon ergens 1 punt en maak dat het knooppunt. Bvb op het middenbeen van een T of een arbitraire arm op een rondpunt. Zoals hier http://www.openstreetmap.org/?lat=51.15636lon=4.2292zoom=17layers=Crelation=9754 Leid daarna alle routes van de nabuurpunten naar dat punt. Want eigelijk is er ook maar een knooppunt. Dat de resulterende aaneengeschakelde routes hierdoor een kleine krul kunnen bevatten vind ik dan nog niet eens zo erg. Die omweg is de prijs die de mensen betalen, die blindelings hun GPS volgen zonder zelf maar een poging te doen van op de bordjes te letten. Alternatief is dat je voor mikro-mapping gaat en alle 'losse' knooppunten met hetzelfde nummer gaat mappen, maar dan dien je ook voor deze kort bij elkaar liggende punten de aparte routetjes te worden voorzien. In het voorbeeld van knoop 98 worden dat dan 3 aparte routetjes (er zijn blijkbaar geen eenrichtingsbaantjes of verplichte rijrichtingen bij) elk op hun zijde van de driehoek. Ik weet dat ik nogal skeptisch was tegen de aanpak van Polyglot die het eerst op die wijze implementeerde, vooral skeptisch dan op de zin ervan. Is zo'n fijn detail niet overdreven of wel nodig? Dat gevoel heb ik nog steeds, maar als er dan toch meerdere knopen voor 1 nummer gemapt worden, dan is het voor mij de enige goede manier en zeker stukken beter dan die tentakels. Gewoon een waardeloos systeem! Op die manier wordt OSM nooit praktisch bruikbaar om sites a la fietsnet op te zetten. Ook met de definities voor de rollen forward en backward heb ik het moeilijk. Die zijn voor mij ook absurd en zorgen enkel voor komplikatie zonder echt iets toe te voegen. Ik heb ook de indruk dat het dateert uit de tijd dat er nog geen volgorde kon worden gegeven (of behouden worden) aan de leden in een relatie. Wat betekent een rol hebben in een relatie? Het betekent dat je als element in een relatie deelneemt, maar niet op dezelfde wijze als een ander element. Een 'way' in een gebied kan zowel een stuk van de buitenkant of van een enclave zijn. Daar geeft de rol outer of inner perfekt weer wat een bepaalde way komt doen in de relatie. Voor een route die in principe zowel van A naar B als van B naar A kan gevolgd worden, is het te volgen pad voor heen en terug meestal gelijk. Wanneer er eenrichtingswegen inzitten ontstaat er een verschillend pad voor die heen- en terugweg. Er zitten dus drie verschillende wegen in de relatie. Wegen die een rol spelen voor beide richtingen, of alleen in de heen-, of in de terugrichting worden gebruikt. Logischerwijs krijgt de heenrichting van A naar B de rol forward en de terugweg van B naar A backward. Een lege rol is niets speciaals en daar wordt de weg in beide richtingen gebruikt. Heel simpel. Moet je een route in een GPX gieten neem je gewoon de leden met een lege rol, aangevuld met de leden met of de rol forward voor de heenrichting, of de rol backward voor de andere richting. Ook heel simpel uit te sorteren en gemakkelijk. Maar het door de Wiki voorgestelde systeem heeft gemeend te moeten rekening houden met de richting
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Beste mede-mappers, Hierbij wat willekeurige gedachten van mij over de wijze waarop fietsknooppuntennetwerken worden getagd. Wat mij betreft is de oplossing met de 'tentakels' werkbaar, sluitend en uit wat er te zien is in het terrein af te leiden. Ik denk dat de oplossing met 'tentakels' werkbaar is. Voorheen heb ik mij bij de wat ingewikkelder knooppunten - en die zijn er voldoende in mijn omgeving - in allerlei bochten moeten wringen. Na de uitgebreide uitleg enige weken terug [1] en enige gewenning blijkt het voor mij in de meeste gevallen mogelijk vrij eenvoudig de routes samen te stellen. Hoewel ik dat niet met 100% zekerheid weet, geloof ik dat alle denkbare situaties met de op de wiki beschreven werkwijze zijn vorm te geven. Ik ben in ieder geval nog geen voorbeeld tegengekomen, en ik heb ik al wel het een en ander gezien (bijvoorbeeld [2a,2b]). Map what you see. Wanneer ik bij een (enkel~ of meervoudig) knooppunt aankom kom ik voordat ik bij een eventueel paneel kom vrijwel altijd een bordje tegen met het knooppuntnummer en de richtingen naar de aansluitende knoopunten. Afhankelijk van de te nemen route kan ik vanaf dat punt het nieuwe nummer volgen. Uit mijn ervaring blijkt dat - in ieder geval in mijn omgeving - bij veel knooppunten een paneel ontbreekt. Op basis van taggen wat je ziet en de keuze voor één node op de plek van het paneel zou er in die situaties geheel geen knooppunt zijn ;-). De wijze van gebruik van forward/backward heeft bij mij in eerste instantie ook voor verwarring gezorgd [3]. En nog is er ook wat voor te zeggen om het anders te doen, maar als de hele wereld het nu zo doet... (Overigens heb ik een niet bevestigd gevoel dat Jo's script in sommige gevallen moeite heeft met role=backward, maar dat terzijde). Het is waar dat bij een meervoudig knooppunt, met meerdere als knooppunt getagde nodes, alle nodes als POI in de GPS te zien zullen zijn. Maar is het kiezen van één om heen te navigeren niet net zo willekeurig als naar het paneel navigeren? Als je op het knooppunt aankomt zul je in beide gevallen je hoofd en/of de aanwezige bordjes moeten gebruiken. En zou het niet mogelijk zijn bij het aanmaken van je POI bestand de knooppunten uit te dunnen? ... Hier wil ik het nu bij laten. Hoop dat bovenstaande iets bijdraagt in de gedachtenvorming. Vriendelijke groet, J-. [1] http://lists.openstreetmap.org/pipermail/talk-nl/2011-October/013200.html [2a] http://www.openstreetmap.org/browse/relation/1166853 [2b] http://dl.dropbox.com/u/20232727/Rdam60-61.jpg [3] http://lists.openstreetmap.org/pipermail/talk-nl/2010-July/011250.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
Ik ben al wel situaties tegengekomen waar ook het systeem met de tentakels het moeilijk mee heeft, maar er is geen enkel systeem dat voor die situatie een sluitende of betere oplossing biedt. Het gaat dan om knooppunten in de buurt van sluizen, waar of de ene of de andere sluis openstaat en de route dus daarvan afhangt. Verder is er in Oostende een stel bruggen met een gelijkaardige situatie, maar dan op de route, niet tussen de gesplitste knooppunten in. Het is zeer waarschijnlijk dat er in Nederland ook van dat soort situaties gevonden kunnen worden. Voor de eerstgenoemde sluizen heb ik gewoon zeer pragmatisch twee routes aangelegd, die dan heel wat leden gemeenschappelijk hebben. Voor de situatie in Oostende heb ik me van de tweede brug niets aangetrokken... ofwel stuikt er daar dus iemand binnenkort in het water, of blijft daar een paar uur voor een gesloten brug staan, totdat ze zien dat de kusttram wel aan de overkant geraakt... Ook voor de route van de kusttram zat ik daar trouwens met een probleem. Ik zie nu dat het daar ook om een grote sluis gaat. de Demeysluis. Mijn probleem is dat ik niet altijd ter plaatse kan gaan om te gaan kijken welke bordjes er nu eigenlijk staan, vandaar dat ik tracht om simpele eenduidige regeltjes gedefinieerd te krijgen, zoals zet een rcn_ref op alle eindpunten van een routerelatie en verbind dan alle gelijkgenummerde knooppunten met tentakels voorzien van roles om de fietsers vanaf elk ander gesplitst KP naar de eigenlijke start van de route te krijgen. Ik heb dat zelf niet bedacht, maar tracht gewoon om te beschrijven wat ik slechts mits een vrij grote inspanning geleerd heb, zodat anderen het hopelijk makkelijker hebben om het te snappen. Ik heb Koen van Fietsnet ook om zijn opinie gevraagd, maar het kan wel enkele dagen duren eer hij antwoord geeft. Met name dus de vraag of dit systeem geschikt is om mee aan de slag te gaan voor zijn routering. mvg, Jo Op 24 november 2011 21:37 schreef Jeroen Muris jer...@tweejee.net het volgende: Beste mede-mappers, Hierbij wat willekeurige gedachten van mij over de wijze waarop fietsknooppuntennetwerken worden getagd. Wat mij betreft is de oplossing met de 'tentakels' werkbaar, sluitend en uit wat er te zien is in het terrein af te leiden. Ik denk dat de oplossing met 'tentakels' werkbaar is. Voorheen heb ik mij bij de wat ingewikkelder knooppunten - en die zijn er voldoende in mijn omgeving - in allerlei bochten moeten wringen. Na de uitgebreide uitleg enige weken terug [1] en enige gewenning blijkt het voor mij in de meeste gevallen mogelijk vrij eenvoudig de routes samen te stellen. Hoewel ik dat niet met 100% zekerheid weet, geloof ik dat alle denkbare situaties met de op de wiki beschreven werkwijze zijn vorm te geven. Ik ben in ieder geval nog geen voorbeeld tegengekomen, en ik heb ik al wel het een en ander gezien (bijvoorbeeld [2a,2b]). Map what you see. Wanneer ik bij een (enkel~ of meervoudig) knooppunt aankom kom ik voordat ik bij een eventueel paneel kom vrijwel altijd een bordje tegen met het knooppuntnummer en de richtingen naar de aansluitende knoopunten. Afhankelijk van de te nemen route kan ik vanaf dat punt het nieuwe nummer volgen. Uit mijn ervaring blijkt dat - in ieder geval in mijn omgeving - bij veel knooppunten een paneel ontbreekt. Op basis van taggen wat je ziet en de keuze voor één node op de plek van het paneel zou er in die situaties geheel geen knooppunt zijn ;-). De wijze van gebruik van forward/backward heeft bij mij in eerste instantie ook voor verwarring gezorgd [3]. En nog is er ook wat voor te zeggen om het anders te doen, maar als de hele wereld het nu zo doet... (Overigens heb ik een niet bevestigd gevoel dat Jo's script in sommige gevallen moeite heeft met role=backward, maar dat terzijde). Het is waar dat bij een meervoudig knooppunt, met meerdere als knooppunt getagde nodes, alle nodes als POI in de GPS te zien zullen zijn. Maar is het kiezen van één om heen te navigeren niet net zo willekeurig als naar het paneel navigeren? Als je op het knooppunt aankomt zul je in beide gevallen je hoofd en/of de aanwezige bordjes moeten gebruiken. En zou het niet mogelijk zijn bij het aanmaken van je POI bestand de knooppunten uit te dunnen? ... Hier wil ik het nu bij laten. Hoop dat bovenstaande iets bijdraagt in de gedachtenvorming. Vriendelijke groet, J-. [1] http://lists.openstreetmap.**org/pipermail/talk-nl/2011-** October/013200.htmlhttp://lists.openstreetmap.org/pipermail/talk-nl/2011-October/013200.html [2a] http://www.openstreetmap.org/**browse/relation/1166853http://www.openstreetmap.org/browse/relation/1166853 [2b] http://dl.dropbox.com/u/**20232727/Rdam60-61.jpghttp://dl.dropbox.com/u/20232727/Rdam60-61.jpg [3] http://lists.openstreetmap.**org/pipermail/talk-nl/2010-** July/011250.htmlhttp://lists.openstreetmap.org/pipermail/talk-nl/2010-July/011250.html __**_ Talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
On 24-11-2011 22:20, Jo wrote: Verder is er in Oostende een stel bruggen met een gelijkaardige situatie, maar dan op de route, niet tussen de gesplitste knooppunten in. Het is zeer waarschijnlijk dat er in Nederland ook van dat soort situaties gevonden kunnen worden. Uiteraard zijn die in NL ook te vinden: http://www.openfietskaart.nl/?zoom=15lat=51.33094lon=3.8202layers=BTTT http://osm.org/go/0EmKK5EQ--?layers=C Zelfs drie sluizen op een rij. Ga je dan ook 3^2 routes aanleggen? Op dit moment ligt daar heel pragmatisch een enkele route over het sluizencomplex, tussen 25 en 28. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Aanbod van een ambulance rijder
Goedeavond, Ik kreeg vanavond het aanbod van een Ambulance rijder om de problemen die zij aan hun kaartenboer terugmelden ook op te sturen naar OpenStreetMap. Zij werken nu met CitiGIS en hebben volgens mij niet echt een openstreetbugs bugflow zoals wij dat hebben. Maar misschien is daat wat mee te doen. Het gaat om omgeving Zwolle. Zijn er mensen die in die buurt wonen en/of graag dit soort data zou willen verwerken? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
On Thursday 24 November 2011 17:23:18 Piet Smits wrote: Hallo, even my 10-cents worth. Ik heb deze discussie nu een tijdje aangezien, en behalve dat ik van het tentakel verhaal niet zoveel begrijp, dacht ik dat we mapten wat er in-the-field te vinden was. Dus als er op een knooppunt 1 paaltje of bordje staat, dan zetten we dat dacht ik toch op de kaart. We mappen niet voor router software, die moet z'n eigen broek ophouden, en zorgen dat het werkt met de data zoals aangeleverd. We kunnen dus mappen voor toekomstige oplossingen, die hier wel mee gaan werken, maar dat lijkt me helemaal fout. In realiteit zijn er vaak genoeg knooppunten die eigenlijk meerdere knooppunten bevatten (behalve dan misschien in dat netwerk waarover onlangs de discussie bezig was). Het bordje met dat knooppuntnummer staat dan ook op elk van die plekken. Als ik nu, met mijn Garmin, van knooppunt naar knooppunt wil rijden, dan kies ik de knooppunten, en vervolgens kijkt mijn apparaat welke route hij wil rijden. Hij doet dus weinig tot niets met de route zoals die in OSM, of op de bordjes langs de weg te zien is. Door nu een knooppunt op te splitsen in meerdere, heb ik plotseling ook meerdere knooppunten om uit de kiezen. Welke is dan de goede ? Je gps moet maar slim genoeg zijn... Ik vind knooppuntennetwerken juist helemaal niet complex, ze zijn opgezet om simpel te zijn. Je rijd van Knooppunt A naar Knooppunt B en volgt daarbij de bordjes langs de route, en houd rekening met de geldende verkeersregels. Simpeler kan volgens mij niet. Maar, zoals gezegd, slechts mijn tien centen. Ik hoop alleen dat de routes hier op Voorne-Putten niet teveel verhaspeld worden, Het probleem is dat een gps maar een dom ding is en dat je iets beters nodig hebt om rechtstreeks iets met de data van OSM te doen (en dan vooral met de tentakels). Wat niet wegneemt dat je altijd automatisch die data kan vereenvoudigen om er iets van te maken dat je gps wel aankan. Maar de fout die je maakt is dat je niet iets niet moet mappen omdat applicatie X dat niet zomaar kan gebruiken zonder dat de data eerst moet verwerkt worden. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[Talk-de] Bilder dauerhaft lagern
hi ! auch wenn die Titelzeile etwas merkwürdig klingt trifft es die Sache auf den Kopf. Ein Mapper kommt viel durch die Gegend und dabei wird das eine oder andere Bild (z.b. Kulturdenkmäler, Grenz- und Meilensteine) gemacht was für die Nachwelt interessant ist und auch ggf. verlinkt werden kann. Wo lasse ich solche Bilder aber - ich kann diese auf meinem Server legen; aber auch ich bin vergänglich bzw. habe irgendwann vielleicht einmal andere Interessen. Weiß einer von Euch ob es irgendwo ein Projekt gibt wo man so bilder für die Ewigkeit einlagern kann ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Bilder dauerhaft lagern
Am 24.11.2011 09:45, schrieb Jan Tappenbeck: Ein Mapper kommt viel durch die Gegend und dabei wird das eine oder andere Bild (z.b. Kulturdenkmäler, Grenz- und Meilensteine) gemacht was für die Nachwelt interessant ist und auch ggf. verlinkt werden kann. Dafür ist Wikimedia gedacht. Da gabs sogar gerade mal eine Aktion im Hinblick auf Kulturdenkmäler. Dann evtl. einen Link in einen geeigneten Wikipedia Artikel einbauen und fertig ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder dauerhaft lagern
On 11/24/2011 09:45 AM, Jan Tappenbeck wrote: hi ! auch wenn die Titelzeile etwas merkwürdig klingt trifft es die Sache auf den Kopf. Ein Mapper kommt viel durch die Gegend und dabei wird das eine oder andere Bild (z.b. Kulturdenkmäler, Grenz- und Meilensteine) gemacht was für die Nachwelt interessant ist und auch ggf. verlinkt werden kann. Wo lasse ich solche Bilder aber - ich kann diese auf meinem Server legen; aber auch ich bin vergänglich bzw. habe irgendwann vielleicht einmal andere Interessen. Weiß einer von Euch ob es irgendwo ein Projekt gibt wo man so bilder für die Ewigkeit einlagern kann ? Gruß Jan :-) Spontan fallen mir da die Bilderdienste wie flickr oder picassa ein. Persönlich würde ich es ja bei http://commons.wikimedia.org einlagern. Dann kann man (besonders bei Denkmälern) in der Wikipedia drauf zurückgreifen. Guten Morgen, Andreas signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Bilder dauerhaft lagern
Was werden die davon machen wenn ich da anfänge Bilder mit Strassennamenschilder und Bushaltestellen hoch zu laden? Die Interes des Bildes die für uns interessant sind, ist das meistens nicht für Wikimedia. Und ihr werd sehen dass die Bilder da bald wieder vernichtet werden, wenn ohne Interes die zu benutzen in eine Wikimediaprojekt. Jo 2011/11/24 Wolfgang Barth wolfg...@barthwo.de: Am 24.11.2011 09:45, schrieb Jan Tappenbeck: Ein Mapper kommt viel durch die Gegend und dabei wird das eine oder andere Bild (z.b. Kulturdenkmäler, Grenz- und Meilensteine) gemacht was für die Nachwelt interessant ist und auch ggf. verlinkt werden kann. Dafür ist Wikimedia gedacht. Da gabs sogar gerade mal eine Aktion im Hinblick auf Kulturdenkmäler. Dann evtl. einen Link in einen geeigneten Wikipedia Artikel einbauen und fertig ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Bilder dauerhaft lagern
Wenn es wirklich Bauwerke oder Dinge von Interesse sind, würde ich auch Wikimedia empfehlen (am besten Public Domain und mit Geotags) Es gibt aber auch bei uns ein paar Projekte die genau das abdecken: http://wiki.openstreetmap.org/wiki/OpenStreetView http://wiki.openstreetmap.org/wiki/OpenStreetPhoto http://www.opentrailview.org/ Gruß Matthias (user:!i!) Am 24.11.2011 09:55, schrieb Jo: Was werden die davon machen wenn ich da anfänge Bilder mit Strassennamenschilder und Bushaltestellen hoch zu laden? Die Interes des Bildes die für uns interessant sind, ist das meistens nicht für Wikimedia. Und ihr werd sehen dass die Bilder da bald wieder vernichtet werden, wenn ohne Interes die zu benutzen in eine Wikimediaprojekt. Jo 2011/11/24 Wolfgang Barthwolfg...@barthwo.de: Am 24.11.2011 09:45, schrieb Jan Tappenbeck: Ein Mapper kommt viel durch die Gegend und dabei wird das eine oder andere Bild (z.b. Kulturdenkmäler, Grenz- und Meilensteine) gemacht was für die Nachwelt interessant ist und auch ggf. verlinkt werden kann. Dafür ist Wikimedia gedacht. Da gabs sogar gerade mal eine Aktion im Hinblick auf Kulturdenkmäler. Dann evtl. einen Link in einen geeigneten Wikipedia Artikel einbauen und fertig ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: [bulk]: Bilder dauerhaft lagern
Am 24.11.2011 09:55, schrieb Jo: Was werden die davon machen wenn ich da anfänge Bilder mit Strassennamenschilder und Bushaltestellen hoch zu laden? Diese Art von Bildern ist für die Nachwelt nicht von Interesse. Die gehören da nicht hin. Ich bin nicht mal sicher ob diese Bilder für die Mapper-Gemeinde noch von Interesse sind, nachdem man sie in die Karte eingebaut hat. Es ging ausdrücklich um Kulturdenkmäler und ähnliches. Alle Gebäude unter Denkmalschutz, Naturdenkmäler ... gehören dazu. Grenz- und Meilensteine sind für Wikimedia wohl schon grenzwertig. Die Interes des Bildes die für uns interessant sind, ist das meistens nicht für Wikimedia. Und ihr werd sehen dass die Bilder da bald wieder vernichtet werden, wenn ohne Interes die zu benutzen in eine Wikimediaprojekt. Sehe ich auch so, wenn es Bilder von Bushaltestellen oder Strassenschildern sind. Die würde ich auch löschen. Aber z.B. Gebäude unter Denkmalschutz oder Naturdenkmäler, die sind bei Wikipedia ausdrücklich erwünscht. Man sollte die dann in einem passenden Artikel z.B. zu dem zugehörigen Ort erwähnen, evtl. einfach auflisten und mit Links zu den Wikimedia-Bildern versehen. Auch für einen historisch interessanten Grenzstein würde sich da ein Plätzchen finden. Ebenso ist Georeferenzierung möglich und die erfolgt dann auch gerne mit einem OSM Link! Das ist in der Bildbeschreibung aber auch im verlinkenden Wikipedia Artikel möglich. 2011/11/24 Wolfgang Barthwolfg...@barthwo.de: Am 24.11.2011 09:45, schrieb Jan Tappenbeck: Ein Mapper kommt viel durch die Gegend und dabei wird das eine oder andere Bild (z.b. Kulturdenkmäler, Grenz- und Meilensteine) gemacht was für die Nachwelt interessant ist und auch ggf. verlinkt werden kann. Dafür ist Wikimedia gedacht. Da gabs sogar gerade mal eine Aktion im Hinblick auf Kulturdenkmäler. Dann evtl. einen Link in einen geeigneten Wikipedia Artikel einbauen und fertig ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder dauerhaft lagern
Am 24.11.2011 09:45, schrieb Jan Tappenbeck: Wo lasse ich solche Bilder aber - ich kann diese auf meinem Server legen; aber auch ich bin vergänglich Vielleicht wird in den nächsten 20 Jahren die Unsterblichkeitspille erfunden? Weiß einer von Euch ob es irgendwo ein Projekt gibt wo man so bilder für die Ewigkeit einlagern kann ? Im Prinzip kommt jeder Bilderdienst in Frage dem Du eine gewisse Beständigkeit bescheinigen würdest. Ob es allerdings Wikimedia, picasa etc. in 50 Jahren noch geben wird? Da hilft wohl nur die Bilder in Stein zu meißeln. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder dauerhaft lagern - Commons
Hallo Jan, http://commons.wikimedia.org/ ist hervorragend geeignet für alle Bilder die - wesentliche Objekte (Fotos) - wesentliche Zusammenhänge (Grafik) abbilden * und die handwerklich gut gemacht sind. Commons ist zusammen mit Wikipedia und OSM einer der Global-Player in OpenData. Entsprechende Nachhaltigkeit ist bei allen drei Projekten zu erwarten. Nicht geeignet ist Commons für Schnappschüsse aus dem privaten Umfeld oder für Mapper-Bilder die Hauseingänge, Sitzbänke etc zeigen. Gruss, Markus * Commons speichert auch wesentliche Ton- und Videoaufzeichnungen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder dauerhaft lagern
2011/11/24 Chris66 chris66...@gmx.de: Am 24.11.2011 09:45, schrieb Jan Tappenbeck: Wo lasse ich solche Bilder aber - ich kann diese auf meinem Server legen; aber auch ich bin vergänglich Vielleicht wird in den nächsten 20 Jahren die Unsterblichkeitspille erfunden? Hoffentlich nicht, wir sind mit 7.000.000.000 schon mit zuviele anwesend auf der Erde... Weiß einer von Euch ob es irgendwo ein Projekt gibt wo man so bilder für die Ewigkeit einlagern kann ? Im Prinzip kommt jeder Bilderdienst in Frage dem Du eine gewisse Beständigkeit bescheinigen würdest. Ob es allerdings Wikimedia, picasa etc. in 50 Jahren noch geben wird? Da hilft wohl nur die Bilder in Stein zu meißeln. Und denn davon eine Foto auf Wikipedia hoch zu laden :-) Jo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Saarland nicht mehr anonym
Die letzten drei nodes, die sich da heftig gewehrt haben, sind jetzt auch draussen. Das Saarland hat keine anonym eingetragenen Nodes mehr! Jetzt noch die Lizenzen fertig prüfen und dann sollte zumindest mal meine Region sauber sein für die Umstellung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Adress-Dialog über Shortcut
hi ! es muss doch irgendwie gehen das ich über eine Tastenkombi die Vorlage für die Adresserfassung geöffnet bekomme. Soweit man mir gesagt hat ist ein editieren der Seite mit den Tastenkürzel diesbezüglich nicht möglich - geht das dann vielleicht über die Makros ??? Über eine kurze Beschreibung würde vermutlich nicht nur ich mich sehr freuen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Überwachung von Koordinaten (Fix-Punkte)
Hi ! es wurde kürzlich schon einmal über Fixpunkte in OSM nachgedacht. Derzeit gibt es ja keine Chance vor der Verschiebung zu schützen. Gibt es vielleicht schon irgendwo ein (Perl)Tool mit dem eine definierte Menge von Punkte auf Koordinatenidentität (z.b. vergleich der Node-Koord. mit den zugehörigen Tags) geprüft werden kann. Oder auch versehentlich gelöschte Punkte listet. Der Rest wäre dann derzeit wohl noch handarbeit. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überwachung von Koordinaten (Fix-Punkte)
Hallo, On 11/24/11 12:54, Jan Tappenbeck wrote: es wurde kürzlich schon einmal über Fixpunkte in OSM nachgedacht. Derzeit gibt es ja keine Chance vor der Verschiebung zu schützen. Wenn etwas vor Verschiebung geschuetzt werden muss, dann kann es doch von der Community gar nicht sinnvoll gepflegt werden und sollte daher *ausserhalb* unseres Editiersystems gespeichert werden. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Höranlagen für Geschädigte
hi ! ich habe in Wedel kürzlich ein Schild gesehen zum wiederholten male was hörgeschädigten Helfen soll. Ich habe nur im Wiki nichts tagmäßiges gefunden ! Kann mir einer weiterhelfen ? Gruß Jan :-) [1] http://www.schwerhoerigen-netz.de/MAIN/home.asp [2] http://www.schwerhoerigen-netz.de/MAIN/hoeranlagen.asp?inhalt=01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höranlagen für Geschädigte
Am 24. November 2011 14:02 schrieb Jan Tappenbeck o...@tappenbeck.net: ich habe in Wedel kürzlich ein Schild gesehen zum wiederholten male was hörgeschädigten Helfen soll. Ich habe nur im Wiki nichts tagmäßiges gefunden ! Kann mir einer weiterhelfen ? Sieh mal hier: http://wiki.openstreetmap.org/wiki/Disabilities#Deaf.2F_Hearing_impaired (da steht allerdings noch nicht besonders viel, musst vermutlich passende Tags entwickeln, ich würde mich mal an die accessibility-Liste wenden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Am 24.11.2011 12:52, Jan Tappenbeck: es muss doch irgendwie gehen das ich über eine Tastenkombi die Vorlage für die Adresserfassung geöffnet bekomme. Soweit man mir gesagt hat ist ein editieren der Seite mit den Tastenkürzel diesbezüglich nicht möglich - geht das dann vielleicht über die Makros ??? Über eine kurze Beschreibung würde vermutlich nicht nur ich mich sehr freuen. Redest du gerade von: - JOSM - Wiki - etwas völlig anderem? Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut -
Am 24.11.2011 14:15, schrieb Claudius: Am 24.11.2011 12:52, Jan Tappenbeck: es muss doch irgendwie gehen das ich über eine Tastenkombi die Vorlage für die Adresserfassung geöffnet bekomme. Soweit man mir gesagt hat ist ein editieren der Seite mit den Tastenkürzel diesbezüglich nicht möglich - geht das dann vielleicht über die Makros ??? Über eine kurze Beschreibung würde vermutlich nicht nur ich mich sehr freuen. Redest du gerade von: - JOSM - Wiki - etwas völlig anderem? Claudius hi ! sorry, wenn etwas knapp geschrieben. JOSM meine ich ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Am 24. November 2011 12:52 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! es muss doch irgendwie gehen das ich über eine Tastenkombi die Vorlage für die Adresserfassung geöffnet bekomme. Über eine kurze Beschreibung würde vermutlich nicht nur ich mich sehr freuen. Tastenkürzel kann ich Dir leider nicht sagen (geht vermutlich auch irgendwie), aber ich habe mir einen Button für die Adressen in die Leiste oben gelegt, das ist auch schon ein Fortschritt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Ist die Tastenkürzel nicht zu sehen im Menu, wenn du die Funktion anrufst? Normalerweise kann man selber auch Tastenkürzel einstellen mit F12/Tastatursymbol/Keyboard Shortcuts (steht bei mir auf Englisch) Jo 2011/11/24 Jan Tappenbeck o...@tappenbeck.net hi ! es muss doch irgendwie gehen das ich über eine Tastenkombi die Vorlage für die Adresserfassung geöffnet bekomme. Soweit man mir gesagt hat ist ein editieren der Seite mit den Tastenkürzel diesbezüglich nicht möglich - geht das dann vielleicht über die Makros ??? Über eine kurze Beschreibung würde vermutlich nicht nur ich mich sehr freuen. Gruß Jan :-) __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Moin, zufällig gerade entdeckt: Mit F3 wird der Vorlagensuchdialog geöffnet. (*) Und zufällig ist dann der Adressdialog der erste Eintrag - also einmal Pfeil-nach-unten Ein weiteres Enter - und man ist drin. Sind immerhin nur noch drei Tastendrücke ... ;-) Gruß Georg (*) Vorausgesetzt man hat das bei den Tastaturkürzeln nicht bereits verkurbelt ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing
Ein Punkt, der mich gelegentlich ohne Ergebnis zum Nachdenken bringt sind Multipolygone, die Highway-areas darstellen. Weiss jemand, ob aktuelle Router damit klarkommen (wenn die Tags nur in der Relation sind)? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überwachung von Koordinaten (Fix-Punkte) (Jan Tappenbeck)
Am 24.11.2011 13:00, schrieb talk-de-requ...@openstreetmap.org: Gibt es vielleicht schon irgendwo ein (Perl)Tool mit dem eine definierte Menge von Punkte auf Koordinatenidentität (z.b. vergleich der Node-Koord. mit den zugehörigen Tags) geprüft werden kann. Oder auch versehentlich gelöschte Punkte listet. Hallo Jan, immer diese Wünsche nach einer bestimmten SW-Lösung. Da es verschiedene Ansätze gibt, wäre es interessanter zu erfahren, was an Informationen existiert. Sollen die Überprüfungen in Zeitabständen stattfinden (Extrakt durchsuchen oder Overpass-API nutzen) oder zeitnah berichtet werden (Change Dateien durchflöhen). Sollen neue Elemente erkannt werden und/oder auch Tag-Value Modifikationen berichtet werden? Bist Du bereit eine Datenbank für die Informationen zu spendieren oder sind es nur x-hundert Punkte, die man auch leicht im Memory halten kann? Du siehst, ich habe mir dazu schon Gedanken gemacht (käme aber allenfalls in knapp 4 Wochen dazu, entsprechendes allgemein Verwendbares zusammen zubauen), aber die Notwendigkeit in meinen Umfeld ist noch nicht besonders hoch. Da hat das Thema DQ schon relevanter (http://www.familieverweyen.de/txt_0053.php ). Wenn Du aber da Wünsche hast und noch etwas Zeit bis zur Lösung hast (und Dich mit PHP anfreunden könntest), schick mir mal eine PM. MfG Georg V. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Ich mag es eigentlich nicht Adresse so ein zu tragen. Ich würde nur die Hausnummer und vielleicht housename so eintragen. Alles andere geht in die associatedStreet Relation. Sonst sind viel zu viele Daten immer wieder wiederholt in die DB und ist es einfacher falsche/inkonsistente Daten im DB zu haben. Jo 2011/11/24 Georg Feddern o...@bavarianmallet.de Moin, zufällig gerade entdeckt: Mit F3 wird der Vorlagensuchdialog geöffnet. (*) Und zufällig ist dann der Adressdialog der erste Eintrag - also einmal Pfeil-nach-unten Ein weiteres Enter - und man ist drin. Sind immerhin nur noch drei Tastendrücke ... ;-) Gruß Georg (*) Vorausgesetzt man hat das bei den Tastaturkürzeln nicht bereits verkurbelt ... __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing
Am 24.11.2011 16:39, schrieb Martin Koppenhoefer: Ein Punkt, der mich gelegentlich ohne Ergebnis zum Nachdenken bringt sind Multipolygone, die Highway-areas darstellen. Weiss jemand, ob aktuelle Router damit klarkommen (wenn die Tags nur in der Relation sind)? Vermutlich nicht. Leider sind die Online Router Monate im Datenrückstand so dass ich's grad nicht testen kann. ORS: 18-10-2011 YOURS: 28-06-2011 Cloudmade: ??? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Am 24. November 2011 16:47 schrieb Jo winfi...@gmail.com: Ich mag es eigentlich nicht Adresse so ein zu tragen. Ich würde nur die Hausnummer und vielleicht housename so eintragen. Alles andere geht in die associatedStreet Relation. Sonst sind viel zu viele Daten immer wieder wiederholt in die DB und ist es einfacher falsche/inkonsistente Daten im DB zu haben. Ganz alleine bist Du damit zwar nicht (sind ja auch viele Informatiker hier): 47 353 associatedStreet http://taginfo.openstreetmap.org/keys/type#values aber so richtig durchgesetzt hat sich das auch nicht: http://taginfo.openstreetmap.org/search?q=addr#keys bisherige Diskussionen (s. Archiv) haben soweit ich mich erinnere zum Schluss geführt, dass ein niedrigeres Komplexitätslevel und etwas Redundanz uns hier weiter bringen als die Relationen und stabiler sind. Wenn jemand die Relation z.B. mit Potlatch bearbeitet (behaupte ich mal so frech ohne ganz sicher zu sein) kann es vermutlich gut passieren, dass sie zerstört wird, dann fehlen Deinen Hausnummern plötzlich die Straßen. Inkonsistente Daten kann man so oder so drin haben, bei welcher Version das einfacher im Editor zu erkennen ist, weiss ich nicht genau. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing
Am 24.11.2011 16:51, schrieb Chris66: Vermutlich nicht. mal ebend Garmin-Karten via BaseCamp getestet: Sowohl Karten die mit den Default-mkgmap-Rules erstellt wurden als auch mein derzeitiger Favorit, die Freizeitkarte Deutschland schaffen es noch nicht mal über normale (area=yes, kein MP) Pedestrian-Areas zu routen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing
On 11/24/2011 05:06 PM, Chris66 wrote: Am 24.11.2011 16:51, schrieb Chris66: Vermutlich nicht. mal ebend Garmin-Karten via BaseCamp getestet: Sowohl Karten die mit den Default-mkgmap-Rules erstellt wurden als auch mein derzeitiger Favorit, die Freizeitkarte Deutschland schaffen es noch nicht mal über normale (area=yes, kein MP) Pedestrian-Areas zu routen. Chris Das Problem besteht schon lange, weshalb ich immer predige über so toll gemappte Plätze bitte die Laufwege reinzumalen... MfG Andreas signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Am 24.11.2011 16:51, schrieb Jo: Sonst sind viel zu viele Daten immer wieder wiederholt in die DB und ist es einfacher falsche/inkonsistente Daten im DB zu haben. Hallo Jo, Eigenwerbung da gibt es nette kleine Tools, die solche Fehler aufdecken: http://www.familieverweyen.de/txt_0055.php Für kleiner Datenauszüge (OSM-Datei 6MB) kommt man sogar ohne SW aus, da ich direkt auch ein (mehrsprachiges) Browser-Interface dazu geschrieben habe. /Eigenwerbung MfGGeorg V. (OSM=user_5359) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing
Am 24. November 2011 17:06 schrieb Chris66 chris66...@gmx.de: Am 24.11.2011 16:51, schrieb Chris66: Vermutlich nicht. mal ebend Garmin-Karten via BaseCamp getestet: Sowohl Karten die mit den Default-mkgmap-Rules erstellt wurden als auch mein derzeitiger Favorit, die Freizeitkarte Deutschland schaffen es noch nicht mal über normale (area=yes, kein MP) Pedestrian-Areas zu routen. klar, _über_ die areas geht natürlich nicht, aber am Rand entlang? D.h. die area wie einen geschlossenen Linienzug um den Platz rum interpretiert, das sollte normalerweise der Fall sein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder dauerhaft lagern - Commons
Markus schrieb am 24.11.2011 11:22: http://commons.wikimedia.org/ ist hervorragend geeignet für alle Bilder die - wesentliche Objekte (Fotos) - wesentliche Zusammenhänge (Grafik) abbilden * und die handwerklich gut gemacht sind. Commons ist zusammen mit Wikipedia und OSM einer der Global-Player in OpenData. Entsprechende Nachhaltigkeit ist bei allen drei Projekten zu erwarten. Nicht geeignet ist Commons für Schnappschüsse aus dem privaten Umfeld oder für Mapper-Bilder die Hauseingänge, Sitzbänke etc zeigen. Hier die Beschreibung dessen, was für Commons geeignet ist: http://commons.wikimedia.org/wiki/Commons:Projektrahmen Ausschlaggebend ist der edukative Zweck. Das können auch repräsentativ einzelne Straßenschilder, Haustüren, Sitzbänke sein, wenn sie zB. zur Illustration eines bestimmten Typus dienen. Historische Meilensteine sind sicher immer interessant. Genauso wie Gebäude, Straßenaufnahmen, Denkmäler. Womit Du Dir auf Commons vermutlich wenig Freunde machst, wenn Du einige 100 Fotos von Straßenschildern hochlädst, mit denen keiner weiter was anfangen kann. Das könnte dann uU. auch gelöscht werden - genauso wie die täglich zu Hauf hochgeladenen My Penis.jpg :) Gruß, Alex -- http://de.wikipedia.org/wiki/Benutzer:Alexrk2 http://de.wikipedia.org/wiki/Wikipedia:Kartenwerkstatt/Blog ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing
Am 24.11.2011 17:24, schrieb Martin Koppenhoefer: klar, _über_ die areas geht natürlich nicht, aber am Rand entlang? D.h. die area wie einen geschlossenen Linienzug um den Platz rum interpretiert, das sollte normalerweise der Fall sein. Nein, auch nicht am Rand entlang: http://up.picr.de/8840518htn.png weshalb ich immer predige über so toll gemappte Plätze bitte die Laufwege reinzumalen... Es gibt aber keine Laufwege, man kann kreuz und quer über den Platz laufen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: Datum Lizenzumstellung bekannt
2011/11/23 Wolfgang Barth wolfg...@barthwo.de: Wenn man das einschaltet, wie sehe ich dann die Lizenzprobleme? Hab keinen Hilfetext dazu gefunden. Eingefärbt? Wie? Das ganze ist (vorerst auf Englisch) hier dokumentiert: http://wiki.openstreetmap.org/wiki/Remapping#Visualising_what_needs_to_be_remapped Zusammengefasst: Ja, alles Objekte die als Unsauber gelten (nach gleichen Regeln, wie in JOSM) werden mit farben versehen. Dunkelrot: Der V1 Mapper hat die Lizenzumstellung ausdrücklich abgelehnt. Transparent-Rot: V1 ist sauber, aber ein weiterer Mapper hat abgelehnt. Orange: Mindestens ein Mapper hat noch keine entscheidung getroffen, aber noch keiner hat abgelehnt. Dermot -- -- Igaühel on siin oma laul ja ma oma ei leiagi üles ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Am 24.11.2011 17:12, schrieb Georg Verweyen: Am 24.11.2011 16:51, schrieb Jo: Sonst sind viel zu viele Daten immer wieder wiederholt in die DB und ist es einfacher falsche/inkonsistente Daten im DB zu haben. Hallo Jo, Eigenwerbung da gibt es nette kleine Tools, die solche Fehler aufdecken: http://www.familieverweyen.de/txt_0055.php Für kleiner Datenauszüge (OSM-Datei 6MB) kommt man sogar ohne SW aus, da ich direkt auch ein (mehrsprachiges) Browser-Interface dazu geschrieben habe. /Eigenwerbung MfG Georg V. (OSM=user_5359) Hi ! wieso Werbung - so sehen andere auch immer wieder Dinge die es in OSM gibt alles kann man nämlich nicht wissen ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing
Ein Punkt, der mich gelegentlich ohne Ergebnis zum Nachdenken bringt sind Multipolygone, die Highway-areas darstellen. Weiss jemand, ob aktuelle Router damit klarkommen (wenn die Tags nur in der Relation sind)? Vermutlich nicht. Leider sind die Online Router Monate im Datenrückstand so dass ich's grad nicht testen kann. ORS: 18-10-2011 YOURS: 28-06-2011 Cloudmade: ??? Ok, hab ein schönes Beispiel gefunden (Oude Markt Enschede): http://www.openstreetmap.org/browse/relation/1669112 Zumindest ORS bestätigt schonmal meine Vermutung: http://129.206.229.146/openrouteservice/index.php?start=6.896588,52.22121end=6.895124,52.22036pref=Pedestrianlang=de Kurzer Blick auf die kommerzielle Konkurrenz: Bei google sind Fläche und Wege separat eingezeichnet, somit Routing problemlos. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
Einmal habe ich die Relationen angemacht für viele Strassen in eine Gemeinde die von jemand anderes von Adresdaten vorgesehen waren, und alle addr: dann weggeholt van die Häuser. Hat er aber gemeckert das iOE (editor auf iPhone) keine Relationen unterstutzt... Dann mal wieder zurückgedreht, am wenigstens bis er fertig ist das alles ein zu tragen. Jo 2011/11/24, Jan Tappenbeck o...@tappenbeck.net: Am 24.11.2011 17:12, schrieb Georg Verweyen: Am 24.11.2011 16:51, schrieb Jo: Sonst sind viel zu viele Daten immer wieder wiederholt in die DB und ist es einfacher falsche/inkonsistente Daten im DB zu haben. Hallo Jo, Eigenwerbung da gibt es nette kleine Tools, die solche Fehler aufdecken: http://www.familieverweyen.de/txt_0055.php Für kleiner Datenauszüge (OSM-Datei 6MB) kommt man sogar ohne SW aus, da ich direkt auch ein (mehrsprachiges) Browser-Interface dazu geschrieben habe. /Eigenwerbung MfG Georg V. (OSM=user_5359) Hi ! wieso Werbung - so sehen andere auch immer wieder Dinge die es in OSM gibt alles kann man nämlich nicht wissen ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM in der SZ
Hallo, hab grad auf der Website der Süddeutschen Zeitung eine Bildstrecke mit einer Mapnik Karte entdeckt. In dem Artikeltext geht es um die zukünftig kostenpflichtigen Google Maps. OSM wird dabei allerdings nicht erwähnt, der einzige Hinweis findet sich fast unleserlich in dem Bild rechts unten, das ein Screenshot einer IPad app ist. http://www.sueddeutsche.de/geld/was-mit-sich-bringt-huch-schon-wieder-alles-anders-1.1196225-10 Gruß Sam ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM in der SZ
Am 24. November 2011 19:51 schrieb saml...@yahoo.de: hab grad auf der Website der Süddeutschen Zeitung eine Bildstrecke mit einer Mapnik Karte entdeckt. OSM wird dabei allerdings nicht erwähnt schade , der einzige Hinweis findet sich fast unleserlich in dem Bild rechts unten, das ein Screenshot einer IPad app ist. http://www.sueddeutsche.de/geld/was-mit-sich-bringt-huch-schon-wieder-alles-anders-1.1196225-10 Da muss man schon sehr genau hinsehen und wissen, was man lesen will, um das zu erkennen. Unter dem Bild steht: © dpa-tmn Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM in der SZ
Am Donnerstag, den 24.11.2011, 20:23 +0100 schrieb Martin Koppenhoefer: Am 24. November 2011 19:51 schrieb saml...@yahoo.de: hab grad auf der Website der Süddeutschen Zeitung eine Bildstrecke mit einer Mapnik Karte entdeckt. OSM wird dabei allerdings nicht erwähnt schade , der einzige Hinweis findet sich fast unleserlich in dem Bild rechts unten, das ein Screenshot einer IPad app ist. http://www.sueddeutsche.de/geld/was-mit-sich-bringt-huch-schon-wieder-alles-anders-1.1196225-10 Da muss man schon sehr genau hinsehen und wissen, was man lesen will, um das zu erkennen. Unter dem Bild steht: © dpa-tmn Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Die App sieht aus wie OffMaps, kanns aber gerade nicht prüfen. In der App wird das Copyright immer eingeblendet. Das nennt man Urheberrechtsverletzung, mal sehen ob die OSF sich da mit dpa anlegt. Ich empfinde es ausserdem sehr befremdlich, einen Artikel über Guggel mit einer OSM-Karte zu ilustrieren ohne dabei zu erwähnen, das es diese freie Alternative gibt. Klaus -- Psst. Meine Symbole sind dort: http://www.cybernautiker.de/ signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Anfrage Ostbayernbus/RBO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, ich habe mich im Landshuter Raum (Niederbayern) ein wenig mit den Lokalen Öffentlichen Verkehrsmitteln beschäftigt. Da das Linien Netz der Stadtwerke mittlerweile relativ vollständig ist beginne ich mich an seinen Rändern langsam in Ländliches Gebiet vorzutasten *G*. Das Netz hat hier ein wenig anderes Setup. Es kam mir die Idee eine Anfrage Ähnlich http://wiki.openstreetmap.org/wiki/Fuel_Station_Data_Germany an Ostbayernbus und/oder RBO zu schicken um eventuell von da Daten für einen Import oder zumindest etwas zu bekommen das beim Ziehen der Routen hilft. Um doppeltes zu vermeiden wollte ich nachfragen ob jemand weiß ob schon mal eine solche Anfrage gestellt wurde und wenn ja mit welchem Ergebnis. Wenn nicht würde ich meinen wäre es einen Versuch wert ;-) Gruß Tobias Ps: Hilfe jeder Art ist willkommen :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzqQpAAoJEGkKxZ+TJ35MFVQH/1rpOFVUoFR1Gum0I7ryETiO T+bv8LBV7SMLE61rGFc7fWJHiQwTo7fTEnKEKOJ8tVCkfFIb3akJw3W9vxyP+9vq D4auaTVnRfo0ZU8yI777U5bm93YIqaY+xsA3E7Xzu1D6PRC9n8eeZT/OVXLThNdP tHQg51EJBho/xBLFUGeJis1Ao2yIYO6H10zBYOMR7g+ut/xNnOsbYwFPp8Yy5K0c /X+p6PIZyJp3PXTMQrXG2zsOAojyjp3QhCeUNkkFBmg4oRp9s4g42v5sI8ymwP5t FrYeNAb2GXZRSsAkrASnGUL5uLTFamqQ5geovrw3JPQtC/cnioyXhUET+ktT5Y0= =DLyw -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfrage Ostbayernbus/RBO
Tobias Hobmeier wrote Um doppeltes zu vermeiden wollte ich nachfragen ob jemand weiß ob schon mal eine solche Anfrage gestellt wurde und wenn ja mit welchem Ergebnis. Hi Tobias, WENN jemand eine derartige Anfrage gemacht hätte UND die Spielregeln einhalten würde, stände es hier: http://wiki.openstreetmap.org/wiki/DE:Kommunikation mein Vorschlag: warte 1-2Tage ob sich jemand meldet, schicke dann die Anfrage raus und trage sie auf der Wiki-Seite ein. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Anfrage-Ostbayernbus-RBO-tp7029353p7029531.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: [bulk]: Bilder dauerhaft lagern
Am 24.11.2011 10:21, schrieb Wolfgang Barth: Am 24.11.2011 09:55, schrieb Jo: Was werden die davon machen wenn ich da anfänge Bilder mit Strassennamenschilder und Bushaltestellen hoch zu laden? Diese Art von Bildern ist für die Nachwelt nicht von Interesse. Die gehören da nicht hin. Ich bin nicht mal sicher ob diese Bilder für die Mapper-Gemeinde noch von Interesse sind, nachdem man sie in die Karte eingebaut hat. Stumpf abfotografierte Straßen- oder Bushaltestellenschilder sind eher nicht geeignet. Aufnahmen, die Gebäude oder Straßenzüge zeigen oder auch meinetwegen Haltestellen im natürlichen Lebensraum darstellen, können aber eventuell irgendwann für irgendjemanden einen historischen Wert haben. Sowas sollte aber unbedingt Geotags aufweisen und eine zumindest rudimentäre Bildbeschreibung erhalten, damit andere auch etwas damit anfangen können. Es ging ausdrücklich um Kulturdenkmäler und ähnliches. Alle Gebäude unter Denkmalschutz, Naturdenkmäler ... gehören dazu. Grenz- und Meilensteine sind für Wikimedia wohl schon grenzwertig. Wenn sie irgendeine Besonderheit zeigen - nur zu, warum denn nicht? Verwackelte Mobiltelefonknipsereien aber bitte draußen lassen, wer sollte sowas nachnutzen wollen? Ebenso ist Georeferenzierung möglich Sogar sehr erwünscht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Hallo, Am 21.11.2011 um 01:51 schrieb Garry: Hardware gibt es genügend die das könnte - es muss nur jemand die Software dafür schreiben. Die Chance dafür wird drastisch sinken wenn man die TMC-Daten aus OSM entfernt. Ich rede nicht davon die sinnvollen TMC Tags (Points) zu entfernen. Was wir aber nicht in OSM brauchen sind Verbindungen zwischen den TMC-Points. Das heißt die Anzahl der notwendigen TMC Tags würden auf 1 schrumpfen. Diesen einen Tag könnte man dann sogar so schreiben, dass er nicht mehr so abschreckend aussieht. MfG Andreas Hubel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM in der SZ
Am 24. November 2011 21:07 schrieb Klaus-Hermann Otto Stanislaus Plöger k.ploe...@gastradata.de: Da muss man schon sehr genau hinsehen und wissen, was man lesen will, um das zu erkennen. Unter dem Bild steht: © dpa-tmn Das nennt man Urheberrechtsverletzung, mal sehen ob die OSF sich da mit dpa anlegt. was ich meinte war, wenn man die Redaktion freundlich darauf hinweist, dass sie eigentlich (c) openstreetmap contributor, cc-by-sa hinschreiben müssen, dann machen sie das vielleicht. Wenn man ihnen unverschämt oder drohend kommt, dann entfernen sie vermutlich einfach das Bild. Im Prinzip freuen wir uns doch alle, wenn OSM im Kontext mit Google-maps-Gebühren in die Medien kommt (klar, die Freude hält sich in Grenzen solange wir mit keinem Wort erwähnt werden und unsere Karte mit unzureichenden Quellenangaben publiziert wird). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] openstreetmap Urheberrecht
Sehr geehrter Herr Avaresch! In der unten verlinkten Bilderstrecke befindet sich ein Bild zu der Überschrift Google Maps will Geld sehen mit dem Urheberrechtsvermerk ©dpa tmn, welches eine OpenStreetMap Karte zeigt. OpenStreetMap Karten stehen aber unter der Creative Commons Attribution-ShareAlike 2.0 Generic License einzusehen unter: http://creativecommons.org/licenses/by-sa/2.0/ Ich bitte Sie daher, den Urheberrechtsvermerk zu ändern. Der Link zu Ihrer Seite: http://www.sueddeutsche.de/geld/was-mit-sich-bringt-huch-schon-wieder-alles-anders-1.1196225-10 Mit freundlichen Grüßen Klaus-Hermann Otto Stanislaus Plöger signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überwachung von Koordinaten (Fix-Punkte) (Jan Tappenbeck)
Am 24.11.2011 16:46, schrieb Georg Verweyen: Am 24.11.2011 13:00, schrieb talk-de-requ...@openstreetmap.org: Gibt es vielleicht schon irgendwo ein (Perl)Tool mit dem eine definierte Menge von Punkte auf Koordinatenidentität (z.b. vergleich der Node-Koord. mit den zugehörigen Tags) geprüft werden kann. Oder auch versehentlich gelöschte Punkte listet. Hallo Jan, immer diese Wünsche nach einer bestimmten SW-Lösung. hi! danke für die Rückmeldung - aber ich frage immer in der ML um vielleicht etwas in Erfahrung zu bringen was es schon gibt und zweitens um nicht Arbeit doppelt zu machenn. Da es verschiedene Ansätze gibt, wäre es interessanter zu erfahren, was an Informationen existiert. Sollen die Überprüfungen in Zeitabständen stattfinden (Extrakt durchsuchen oder Overpass-API nutzen) oder zeitnah berichtet werden (Change Dateien durchflöhen). Sollen neue Elemente erkannt werden und/oder auch Tag-Value Modifikationen berichtet werden? Bist Du bereit eine Datenbank für die Informationen zu spendieren oder sind es nur x-hundert Punkte, die man auch leicht im Memory halten kann? Du siehst, ich habe mir dazu schon Gedanken gemacht (käme aber allenfalls in knapp 4 Wochen dazu, entsprechendes allgemein Verwendbares zusammen zubauen), aber die Notwendigkeit in meinen Umfeld ist noch nicht besonders hoch. Da hat das Thema DQ schon relevanter (http://www.familieverweyen.de/txt_0053.php ). Wenn Du aber da Wünsche hast und noch etwas Zeit bis zur Lösung hast (und Dich mit PHP anfreunden könntest), schick mir mal eine PM. MfG Georg V. Ich möchte aktuell einige Punkt in Lübeck einführen und diese irgendwie überwachen damit diese nicht verschoben / gelöscht werden. Frederik hat zwar geschrieben das diese extern gespeichert werden müßten aber a.) wo? b.) ein Bearbeitungsschutz gibt es derzeit nicht ! und deshalb muss man nach alternativen Suchen. SERVER: ich habe nur Webspace mit mysql und php bei 1und1 - ich glaube kaum dort einen Server für OSM aufsetzen zu können. Oder man kann mir andere Info geben. gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM in der SZ
Klaus-Hermann Otto Stanislaus Plöger schrieb am 24.11.2011 21:07: http://www.sueddeutsche.de/geld/was-mit-sich-bringt-huch-schon-wieder-alles-anders-1.1196225-10 Die App sieht aus wie OffMaps, kanns aber gerade nicht prüfen. In der App wird das Copyright immer eingeblendet. Das nennt man Urheberrechtsverletzung, mal sehen ob die OSF sich da mit dpa anlegt. Klaus Sehen wir zwei unterschiedliche Bilder oder haben die das geändert? Ich sehe da einen Screenshot von einer App, die eine OSM-Karte anzeigt und dazu die Lizenz einblendet. Dieser Screenshot selbst steht unter Lizenz, die darunter angezeigt wird. Wo fehlt da jetzt eine Lizenz? Dass die OSM-Lizenz so klein ist, kann doch wohl nicht allen Ernstes das Problem sein? Leicht irritiert, Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adress-Dialog über Shortcut
HI ! ALT+F4 ist nach der Liste nicht genutzt und oben gibt es eine Textzeile mit dem Hinweis auf manuell editieren. Aber mir erschließt sich kein Weg die Datenfelder zu editieren noch führt die Textzeile irgendwo hin!. Vielleicht weiß noch einer mehr. Gruß Jan .-) Am 24.11.2011 15:04, schrieb Jo: Ist die Tastenkürzel nicht zu sehen im Menu, wenn du die Funktion anrufst? Normalerweise kann man selber auch Tastenkürzel einstellen mit F12/Tastatursymbol/Keyboard Shortcuts (steht bei mir auf Englisch) Jo 2011/11/24 Jan Tappenbecko...@tappenbeck.net hi ! es muss doch irgendwie gehen das ich über eine Tastenkombi die Vorlage für die Adresserfassung geöffnet bekomme. Soweit man mir gesagt hat ist ein editieren der Seite mit den Tastenkürzel diesbezüglich nicht möglich - geht das dann vielleicht über die Makros ??? Über eine kurze Beschreibung würde vermutlich nicht nur ich mich sehr freuen. Gruß Jan :-) __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM in der SZ
On 25.11.2011 06:57, Sebastian Masch wrote: http://www.sueddeutsche.de/geld/was-mit-sich-bringt-huch-schon-wieder-alles-anders-1.1196225-10 Sehen wir zwei unterschiedliche Bilder oder haben die das geändert? Ich sehe da einen Screenshot von einer App, die eine OSM-Karte anzeigt und dazu die Lizenz einblendet. Dieser Screenshot selbst steht unter Lizenz, die darunter angezeigt wird. Wo fehlt da jetzt eine Lizenz? Dass die OSM-Lizenz so klein ist, kann doch wohl nicht allen Ernstes das Problem sein? Ich vermute es ist noch komplizierter. Die GUI von Programmen ist urheberrechtlich geschützt. Siehe die Diskussion in der Wikipedia um screenshots. Da der Inhalt zum größten Teil aus OSM-Karte besteht könnte hier das SA greifen. Das copyright würde dann verrmutlich CC-BY-SA osm App Redakteur lauten. Wenn jemand es genauer wissen will gibt es dafür die legal-talk Liste. Andere übernehmen gleich die Daten von uns in ihre maps. Finde ich viel schlimmer.. Das hier bei Bing riecht stark nach einem Edit von mir: http://www.bing.com/maps/?v=2cp=18.87055214139197~99.1365075328072lvl=18dir=0sty=hnwyw=1ss=yp.doi%20saket%2C%20thailandform=LMLTCC http://thaimap.osm-tools.org/?zoom=19lat=18.87069lon=99.13627layers=B00T Ist ein Service way zum District Office und anderen Verwaltungen mit Parkplatz. Warum ausgerechnet das bei Bing drin sein soll und andere Service ways nicht klingt nach viel Zufall. Aber: Ich will nicht wissen wie viel von Google oder Bing abgemalt wurde und jetzt in OSM steckt. Da sollte man nicht bei jeder Kleinigkeit mit dem Anwalt drohen. Ein freundlicher Hinweis reicht. In diesem speziellen Fall könnte ja sogar der Eindruck entstehen dass unsere Karte kostenpflichtig ist. Da wäre viel wichtiger das redaktionell zu korrigieren statt einen Copyrighthinweis anzubringen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überwachung von Koordinaten (Fix-Punkte) (Jan Tappenbeck)
Hallo, On 11/25/11 06:53, Jan Tappenbeck wrote: Frederik hat zwar geschrieben das diese extern gespeichert werden müßten aber a.) wo? Kommt drauf an, wie viele es sind. Da per definition ja keine Mitarbeit von Mappern gewuenscht ist, sondern nur existierende Fixpunkte abgebildet werden sollen, koenntest Du z.B. einfach ein KML-File auf Deinen Server legen, in dem die alle drin sind, und jeder, der sich dafuer interessiert, kann dieses KML mit drei Zeilen Code auf seiner OpenLayers-Karte einbinden. Das geht natuerlich nur fuer kleine Punktmengen, fuer groessere braucht es eine Datenbank. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [osm-ve] Clasificacion de carreteras
Lo recomendable es utilizar las 2 vías y el sentido respectivo Hernán, ¿qué significa usar 2 vías? te refieres a que cada canal es una vía(línea) sí es así, ¿por qué es una recomendación? Por ejemplo la A.V. Universidad(Mérida) es recomendable 2 vías(lineas), aunque no se tiene la imagen satelital, esto debido a la exactitud del gpx que se tenía cuando de monto. Las carreteras con 4 carriles 2 para cada sentido es recomendable una vía por sentido, las vías con islas es recomendable 2 vías por sentido. Esto esta atado a la calidad de datos que tengamos tanto satelital como en gpx. Respecto a la clasificación hay que tener cuidado, pues las primarias y las autopistas se ven a un zoom muy bajo y pueden saturar el mapa. Es por eso que en mérida solo tenemos una primaria y una segundaria. Ahora tengo dudas respecto al ruteo, pues desde las tapias hasta la vuelta siempre me envía por la panamericana y desde el cida a la vuelta me envía por la milagrosa, todavía no he visto el algoritmo del ruteo para dar prioridades, eso es otro cantar. ___ Talk-ve mailing list Talk-ve@openstreetmap.org http:// -- Cesar A. Carbonara R. C.I. Nº V.11.952.572 -- ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve
Re: [Talk-it] [osmosis] inclusione di tutte le way in un bbox
Il 11/23/2011 05:26 PM, Martin Koppenhoefer scrisse: Strano, ero convinto di si. Se vuoi avere anche le way che intersechino ma non hanno nodi dentro al tuo bounding box credo che tu abbia ragione. Invece se hanno nodi dentro il BB c'è una opzione di osmosis: Nell'esempio di comando di osmosis che uso c'e' completeRelations=yes, il quale implica completeWays. In realta' per quello che mi serve, e' meglio completeWays perche' con completeRelations vengono incluse anche ways ben lontane dal mio bounding box (ad esempio ways appartenenti a linee tramviarie o della metropolitana con rerlation con way che passano nel mio bbox). Cio' che serve a me invece e': - la way xxx ha 5 nodi. 3 nodi sono nel bbox, uno dei 2 restanti nodi fuori dal bbox fa parte di una way che non e' nel bbox. Osmosis non recupera (forse giustamente) questa way. Molto più veloce di Osmosis è cmq. il formato pbf con per esempio http://wiki.openstreetmap.org/wiki/Pbftoosm (c'è scritto che non viene mantenuto e che si deve utilizzare osmcut). Interessante. Appena ho tempo verifico se con questo tool so ottiene un risultato diverso. grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [osmosis] inclusione di tutte le way in un bbox
2011/11/24 emmexx emm...@tiscalinet.it: Cio' che serve a me invece e': - la way xxx ha 5 nodi. 3 nodi sono nel bbox, uno dei 2 restanti nodi fuori dal bbox fa parte di una way che non e' nel bbox. Osmosis non recupera (forse giustamente) questa way. secondome è giusto che non viene incluso questo way, che sta completamente fuori il tuo BBox. Altrimenti, dove ti fermi? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [osmosis] inclusione di tutte le way in un bbox
Il 11/24/2011 01:17 PM, Martin Koppenhoefer scrisse: secondome è giusto che non viene incluso questo way, che sta completamente fuori il tuo BBox. Altrimenti, dove ti fermi? Potrebbe essere una opzione da suggerire agli sviluppatori di osmosis: - non includere le way (ed i relativi nodi) troncate dal bbox - includere le way ma non i relativi nodi fuori dal bbox - includi le way (ed i relativi nodi) troncate dal bbox - includi le way (ed i relativi nodi) troncate dal bbox + le way intersecate da way appartenenti anche parzialmente al bbox. Faccio un esempio pratico dell'ultimo caso, quello che in realta' serve a me: Devo trovare quali way (vie) intersecano una bbox. Per i nodi di way che si trovano fuori dal bbox perdo questa informazione se le way intersecanti ma esterne non vengono incluse. Non credo sia complicato da fare per gli sviluppatori di osmosis. Possono fare come ho gia' dovuto fare io con xsl: si usa il bbox per ricavare gli id delle way, poi per ogni way si cercano i nodi e le relative way che li utilizzano facendo riferimento ad un file osm piu' grande del bbox. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
