Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
Martijn van Oosterhout wrote: Hoi, Ik heb gemerkt dat er weinig discussie of aanpassingen zijn geweest met betrekking tot de conversie over de laatste week. Dit kan of betekenen dat of wij denken dat het perfect is, of dat niemand er naar kijkt. Als wij er zeker van zijn kan het zijn dat wij deze week al beginnen met uploaden, maar als er twijfels zijn kunnen wij wachten tot volgende week. Dus de vraag: go or no go? In de discussie lees ik dat controle vnl. via JOSM plaatsvindt. Is het mogelijk om b.v. een slippy map/SVG van de geconverteerde AND data te renderen/bekijken? Ik weet dat dat een hoop van de data(-kwaliteit) niet toont, maar het geeft toch wat visuele cues en is wat sneller te bekijken. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
Martijn van Oosterhout wrote: Ik heb ook wat highway=layby. Wat is dat. AFAIK is dat een vluchthaven, simpele parkeerplaats of passeerplaats op een smalle weg. De definitie is zeer ruim volgens de wiki: http://wiki.openstreetmap.org/index.php/Proposed_features/Lay-by ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
Stefan de Konink wrote: On Tue, 28 Aug 2007, Martijn van Oosterhout wrote: On 8/28/07, Lambertus [EMAIL PROTECTED] wrote: Dus draai ik dan maar mijn duimen en hoop dat er niet al te veel van mijn werk in (vooral) Apeldoorn en omgeving ongedaan raak. Mocht er toch veel verloren gaan dan zal ik proberen daarover niet te veel te zeuren :-) Op zich gaat niks verloren, de oude data zal blijven op een andere server, dus je later dat gewoon weer oproepen en weer uploaden. Zelfs op de OSM servers toch? Het hele project is toch een database met transacties? Ja, de wijzigingen zullen in de OSM servers bestaan blijven voor zover ik weet, alleen is er (nog) geen mogelijkheid om met de huidige tools en API in het verleden te kijken of om verschillende versies van de data met elkaar te vergelijken. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
On 8/28/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: AND=10005031 (De Grote Plas) http://www.openstreetmap.org/index.html?mlat=52.0208599378mlon=4.37841741062495zoom=13 (plak de URL in JOSM) Die plas is niet een gesloten way Ik heb geconstateert dat dit in een fout is in the conversie naar de database en dat het niet voorkomt in de echte OSM data. Met vriendelijke groet, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
On 8/29/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: Ik heb geconstateert dat dit in een fout is in the conversie naar de database en dat het niet voorkomt in de echte OSM data. Hmm, sterker nog, de conversie script voor and.openstreetmap.nl werkt op een beetje andere manier dan hoe de uiteindelijke upload zal werken. Dus de wegen zullen wel op dezelvde plaats zijn maar de precieze relatie tussen segmenten en wegen zal iets anders zijn... Ik zal in iedergeval de echte bug eruit halen. Met vriendelijke groet, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
On 8/28/07, Marc Kessels [EMAIL PROTECTED] wrote: in de AND data kan ik de node-to en node-from ids niet terug vinden in de nodes data. Ik bedoelde een conversie(/export) probleem binnen AND, dat was een optie die één van de mensen bij AND open hield. Met specifieke voorbeelden kunnen wij of AND misschien uitzoeken in wat voor gevallen dit gebeurd. zo'n beetje elke weg, maar hier even een one-way straat, die de segmenten in de goede richting heeft, maar toch een oneway=-1 heeft: Ok, ik heb een beetje hiernaar gekeken en ik denk dat het probleem is dat the nodes data niet alle nodes bevat, maar alleen POIs. Het goede nieuws is dat wij waarschijnlijk wel zelf de nodeIDs kunnen bepalen. Met een kleine verandering heb ik al: way toID refers to not present AND ID=39490 way fromID refers to not present AND ID=39520 Verder zijn de nodeIDs in 020_r_p en 020_nosr_p duplicated, dus vraag ik mij af of die kolom wel de nodeID is, of dat wij eigenlijk ergens anders moeten zijn. Als ik wat vind, hoor je het wel. Natuurlijk als AND de data direct kan geven is dat nog beter... Met vriendelijke groet, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND conv: residential versus unclassified
I'm using tertiary and secondary for the larger roads inside a city/town: the 'singel' in Enschede is a major traffic way and is more important then the roads in the suburban areas. But even in those residential areas, there are roads that count as a preferred way to be used in route planning. Those roads are tagged by me as tertiary. Other roads are residential. Roads that are small and not really designed for motor traffic are classified as unclassified (you can drive there but you only want to go there if there is no other route). The separation in roads is low and hard to distinguish but it is important to get it right imho. I plan to use the data to use in a homebrew route planner. This will only work properly if the map contains level info like I just explained. Otherwise you will get routes through residential areas because its shorter (which will only take longer due to traffic and road bumps etc) - and effectively render it useless. For the people complaining about how it gets rendered: it not a matter of how it looks (that can be altered) but if the data has value. By degrading all roads in residential areas to residential or unclassified you effectively kill any opportunity to use the data for anything else than render pretty pictures Just my 2 cents... Berend P.S. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
On Tuesday 28 August 2007 21:10:57 Martijn van Oosterhout wrote: Ok, ik heb hem geupdate met de laatste versie uit SVN, dus iedereen kan kijken naar hun gebied. (Stel JOSM in op http://and.openstreetmap.nl/api). Dank! Wat mij opvalt: In http://www.openstreetmap.org/index.html?mlat=52.37315193434371mlon=4.882281029897563zoom=14 en ver daarbuiten is al het water verbonden, AND=10007637. Dat is dan zo. Maar er lopen ook lijnen die er helemaal niet horen te lopen. (Zichtbaar bij uitzoomen.) Willekeurige verbindingen tussen nodes. Met mappaint wordt het een rare waterpartij Vergelijkbaar http://www.openstreetmap.org/index.html?mlat=52.51042582801174mlon=4.930033229525526zoom=15 Noordhollands kanaal, AND 10007935. Dit is mogelijk verbonden met een probleem dat Martijn al zag, gaten in water: Die plas is niet een gesloten way http://www.openstreetmap.org/index.html?mlat=50.99884822579567mlon=5.768615577445432zoom=14 Hier tekent mappaint wel water in bij het Julianakanaal (natural=water), maar niet bij de Maas (waterway=river). Dat kan iets van mappaint zijn... Ook hier weer verstorende lijnen. Sraten lopen tot het volgende kruispunt, ze zijn heel kort (en vervolgen als nieuwe way). Op zich niks mis mee, maar anders dan we het tot nog toe deden. (Ik neem aan dat dit ook nodig is om AND data te bewaren.) Wat betreft pedestrian die ook oneway is, in Rotterdam kwam de verklaring naar voren dat het mogelijk eerder eenrichtingsverkeerwegen waren, pas later alleen voor voetgangers. Niet alle pedestrians hebben het, dus dat kan. vriendelijke groet, cordialmente, Ante ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
On 8/29/07, Maarten Deen [EMAIL PROTECTED] wrote: Ik heb even naar mijn woonomgeving Helden gekeken, en het meeste ziet er goed uit, er zijn wat kleine dingetjes. Zo is elk gehucht (dat alleen maar in naam bestaat maar in het echt niet als zodanig te herkennen is) aangegeven, inclusief town area, dat is wat overdreven. Ook is het naburige dorp Panningen een beetje ruim bedeeld met een area, ten koste van Helden (en dat kunnen we niet hebben natuurlijk!). Ik dacht dat de echte gemeente grenzen erin zitten, maar misschien is dat niet zo. Daar zie je een B-weg (de secondary is al erg flatteus) die een autosnelweg kruist. Op de kruispunten van de wegen staan nodes. IMHO is dat volkomen fout, want je suggereert hier een fysieke verbinding tussen de wegen. In de realiteit gaat de secundaire weg met een brug over de autosnelweg. Dat is inderdaad een echt probleem en dat *moet* opgelost worden. Ik ben erg bezig met het kleine correcties maken aan het programma, en ik nader (langzaam) een mogelijke oplossing voor dat probleem. Hopelijk kan ik dat vanavond implementeren en kunnin wij morgen de resultaten zien. Wat me ook opvalt (JOSM downloadt bij mij een vreemd groot gebied met die URL) is dat de Maas een paar hele vreemde segmenten heeft. Waterwegen hebben een groot problem, maar dat lag aan de database conversie, niet aan AND2osm. Morgen zal dat ook opgelost moeten zijn. (Het duurt 1uur om de database te updaten, dus ik doe het niet al te vaak). Het zou leuk zijn als er een map gerenderd kan worden van de huidige data, om zulke zaken op te lossen voordat het geheel als officiele data in openstreetmap terecht komt, maar het ligt eraan hoe lang dat duurt of dat echt nodig is. Dat zou fantasitch zijn, maar ik heb niet de harde schijf/cpu/netwerk bandwidth om ziets op te zetten, maar misschien iemand anders...? Met vriendelijke groet, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Zijn wij zeker van de AND conversie?
On Wed, 2007-08-29 at 18:48 +0200, Maarten Deen wrote: Marc Kessels wrote: probleem is gewoon dat in de AND Data er een node bestaat op de plek waar twee wegen over elkaar heen gaan. In het script ging ik er van uit dat punten die op dezelfde plek lagen, samengevoegd mochten worden, en dat is dus verkeerd gedacht door mij... Ik wacht even de correctie/reactie van Maarten Deen af, voordat ik er zelf werk in ga steken. Wil je graag dat ik het in openstreetmap corrigeer, of begrijp ik je opmerking niet goed? Maarten oeps, foutje, ik bedoelde Martijn van Oosterhout, want die is er mee bezig (zie de mail van Martijn : Dat is inderdaad een echt probleem en dat *moet* opgelost worden. Ik ben erg bezig met het kleine correcties maken aan het programma, en ik nader (langzaam) een mogelijke oplossing voor dat probleem. Hopelijk kan ik dat vanavond implementeren en kunnin wij morgen de resultaten zien. ) groet, Marc ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Het verschil tussen 020_r_r en 0202_nosr_r
On Wed, Aug 29, 2007 at 07:15:43PM +0200, Martijn van Oosterhout wrote: Behalve dat de ene groter is dan de andere. De rede dat ik vraag is dat het lijkt alsof node 9314 in 020_r_r hetzelvde punt is als node 705044 in 020_nosr_r. En niet hetzelvde is als punt 9314 in 020_r_r. Met andere woorden, twee sets punten met dezelvde nummers maar verschillende coordinaten. Ik heb de wiki afgekeken maar ik zie geen beschrijvingen van wat de individuele bestanden bevatten, maar misschien heb ik iets gemist. (Dit veroorzaakt de warnings aan de einde van 2AND, dus als wij dit oplossen dan is de conversie in iedergeval op die front goed). ik heb trouwens met shp2pgsql (zit bij postgis) de AND data in een postgis database gezet. paar voorbeeldjes: and=# \dt List of relations Schema | Name | Type | Owner +--+---+--- public | a| table | tw public | admin0 | table | tw public | admin1 | table | tw public | admin8 | table | tw public | c| table | tw public | ce | table | tw public | f| table | tw public | geometry_columns | table | tw public | gf | table | tw public | i| table | tw public | in | table | tw public | nosr_p | table | tw public | nosr_r | table | tw public | o| table | tw public | pk | table | tw public | r_p | table | tw public | r_r | table | tw public | spatial_ref_sys | table | tw public | w| table | tw (19 rows) (die '020_' is er vanaf geknipt) and=# select gid,fnode_,tnode_,length,astext(the_geom) from r_r limit 5; gid | fnode_ | tnode_ | length| astext -+++-+ 1 | 10908 | 10907 | 0.0013073637596322 | MULTILINESTRING((5.70278 50.75826,5.70342 50.7594)) 2 | 10907 | 10906 | 0.0027153084539343 | MULTILINESTRING((5.70342 50.7594,5.70469 50.7618)) 3 | 10906 | 10905 | 0.00090824005637098 | MULTILINESTRING((5.70469 50.7618,5.70512 50.7626)) 4 | 10905 | 10904 | 0.0061644844960668 | MULTILINESTRING((5.70512 50.7626,5.70535 50.76301,5.70728 50.76667,5.70772 50.76758,5.70798 50.76806)) 5 | 10904 | 10903 | 0.00038948684188414 | MULTILINESTRING((5.70798 50.76806,5.70817 50.7684)) (5 rows) and=# select nd_9,astext(the_geom) from r_p where nd_9 = 'Maastricht'; nd_9| astext +- Maastricht | POINT(5.70589 50.84988) (1 row) and=# select nd_9,askml(the_geom) from r_p where nd_9 = 'Maastricht'; nd_9|askml +-- Maastricht | Pointcoordinates5.70589,50.84988,0/coordinates/Point (1 row) and=# select gid,rd_10,astext(the_geom) from nosr_r where rd_10 = 'Rokin'; gid | rd_10 | astext +---+-- 216894 | Rokin | MULTILINESTRING((4.89322 52.3719,4.89331 52.37225)) 216897 | Rokin | MULTILINESTRING((4.89286 52.37228,4.89286 52.37246,4.89295 52.37272)) 216921 | Rokin | MULTILINESTRING((4.89206 52.36933,4.89216 52.36952,4.8923 52.36995,4.89257 52.37068,4.89277 52.37141,4.89282 52.37165,4.89286 52.37228)) 216922 | Rokin | MULTILINESTRING((4.89331 52.37225,4.89286 52.37228)) 217145 | Rokin | MULTILINESTRING((4.89262 52.3681,4.89243 52.36829)) 217171 | Rokin | MULTILINESTRING((4.89293 52.37086,4.89306 52.37134)) 217191 | Rokin | MULTILINESTRING((4.89341 52.36746,4.89322 52.36759,4.89262 52.3681)) 217199 | Rokin | MULTILINESTRING((4.89243 52.36829,4.89211 52.36863,4.89196 52.36906)) 217221 | Rokin | MULTILINESTRING((4.89284 52.37044,4.89293 52.37086)) 217249 | Rokin | MULTILINESTRING((4.89306 52.37134,4.89322 52.3719)) 217263 | Rokin | MULTILINESTRING((4.8923 52.37035,4.8924 52.37077)) 217343 | Rokin | MULTILINESTRING((4.89278 52.37012,4.89284 52.37044)) 217349 | Rokin | MULTILINESTRING((4.89214 52.36999,4.8923 52.37035)) 217366 | Rokin | MULTILINESTRING((4.89264 52.36922,4.89256 52.36928,4.89264 52.36964,4.89278 52.37012)) 217375 | Rokin | MULTILINESTRING((4.89192 52.36945,4.89214 52.36999)) 217403 | Rokin | MULTILINESTRING((4.89264 52.36922,4.89217 52.36924,4.89206 52.36933)) 217404 | Rokin | MULTILINESTRING((4.89196 52.36906,4.89206 52.36933)) (17 rows) etc.. misschien ook een leuke basis om osm output mee te genereren voor mensen die niet zo bedreven zijn met shapefiles maar wel met sql. De sql bestanden zijn te vinden op
