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 | 5.70589,50.84988,0 (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 http://maps.zuijlen.eu/osm/and/postgis/ Remco --
[OSM-talk-nl] Het verschil tussen 020_r_r en 0202_nosr_r
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). 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] Zijn wij zeker van de AND conversie?
Martijn van Oosterhout wrote: > 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. Het zijn dus geen gemeentegrenzen maar dorpsgrenzen. Het lijkt me bedoeld als area om een bebouwd oppervlak te kunnen renderen, want ongeveer waar de bebouwde kom eindigt daar ligt dit area. Erg accuraat is het niet, want gedeeltes van de bebouwde kom liggen er niet in (nieuwbouwwijk van een jaar of 5 oud, de wegen zijn er wel), en wat ook opvallend is dat de genoemde gehuchten ook begrensd zijn, terwijl die dus echt niet herkenbaar zijn in het echt. Maarten ___ 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?
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 ___ 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:33 +0200, Floris Looijesteijn wrote: > >> 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. > > > > zoals and het verteld heeft zou er in dit geval geen connectie mogen zijn. > dat zou althans de bedoeling moeten zijn. mark's import script kan dit > volgens mij ook niet zelf 'verzonnen' hebben. dus dit lijkt me inderdaad > gewoon een fout... 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. groet, Marc ___ 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?
>> 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. > zoals and het verteld heeft zou er in dit geval geen connectie mogen zijn. dat zou althans de bedoeling moeten zijn. mark's import script kan dit volgens mij ook niet zelf 'verzonnen' hebben. dus dit lijkt me inderdaad gewoon een fout... groet, floris ___ 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?
>> 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...? > Eindelijk iets waar ik me misschien nuttig kan maken :) Ik hang hier aan het netwerk van de TU te Delft en heb hier een 100mbit met 100Gb upload per maand. Er hangt al een compu aan die de hele dag aan staat die zou ik hier best voor kunnen gebruiken. Vraag me alleen af wat er nodig is aan ram/cpu om de boel te renderen. gr Joris ___ 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?
Joost Overes 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). AUB niet grote gebied opvragen graag > >:/) [knip] > Na de echte conversie, aannemende dat die niet veel verschilt van de > data hierboven, zal het verbeteren/aanpassen/fouten er uit halen van de > map nog de nodige tijd in beslag gaan nemen. 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!). Wat me ook opvalt, en daar hebben we op de 3e mappingparty in Amsterdam kort over gesproken, is hoe wegen elkaar kruisen. Pak maar eens http://www.openstreetmap.org/index.html?mlat=51.3865&mlon=6.0483&zoom=14 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 zijn wel dingen die er uit moeten. 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. Segmenten die van van Venlo tot Kessel reiken of van Roermond tot Maastricht en dus ook totaal niets met de echte loop van de Maas te doen hebben. En dat zal leuke effecten geven bij het renderen. Allemaal die dingen zullen er uit gehaald moeten worden, maar al met al is het veel completer dan wat er was, en die paar dingen vallen heus wel op en zijn denk ik ook relatief snel gecorrigeerd. 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. Wat mij betreft: (rekening houdend met de exclusion zones) gaan met die banaan! Maarten ___ 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, Ante Wessels <[EMAIL PROTECTED]> wrote: > Wat mij opvalt: > > In > http://www.openstreetmap.org/index.html?mlat=52.37315193434371&mlon=4.882281029897563&zoom=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 Dit is inderdaad hetzelvde probleem, dus morgen zal dat er weer goed er uit zien. Het is inderdaad alleen een (1) object, maar in principe zal alleen een keer "Split Way" nodig zijn. Wij zouden dit ook kunnen doen voor het upload. En over het andere probleem, ik heb programmatisch ongeveer 680k+ van AND nodes kunnen identificeren. Morgen zal je dus voor de meeste nodes de FROM en TO correct kunnen identificeren. Vreemde genoeg heb ik nog geen een "inverted" weg kunnen vinden (waar de AND_FROM_NODE niet overeen komt met de node bij het begin van de shape in the shapefile). Dus de omgekeerde eenrichtingsverkeren kan ik niet begrijpen. 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 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.37315193434371&mlon=4.882281029897563&zoom=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.51042582801174&mlon=4.930033229525526&zoom=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.99884822579567&mlon=5.768615577445432&zoom=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] 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 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] 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, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > AND=10005031 (De Grote Plas) > http://www.openstreetmap.org/index.html?mlat=52.0208599378&mlon=4.37841741062495&zoom=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] AND conv: residential versus unclassified
On 8/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > In NL we have two parties, the Residentials and the Unclassifieds. Actually, you missed the third group: people like me who beleive that residential=(unclassified+abutters=residential) and as such the tag should be abolished altogether. And that perhaps the abutters tag should be abolished also, in favour of areas. > Now with the AND import coming soon, we have to decide how to converse AND > local streets, to residential or unclassified. We firstly, the AND contains areas describing industrial zones and such so you can easily see where people live. This is a far better solution than tag roads. And secondly, unless you see a way to look at the data and determine one way or the other, we have to make either *all* streets unclassified or *all* street residential. I think you'll agree that the former choice is obviously better. > So, is there actually an intelligent design behind residential versus > unclassified, or is it just survival of the fittest? Can we look for > guidance, or will there be no answer? Well, as far as the renderers are concerned, they agree with the third position, have for months and don't appear to be changing their mind. In the long run though, I don't think it matters. Have a nice day, -- 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
[OSM-talk-nl] AND conv: residential versus unclassified
In NL we have two parties, the Residentials and the Unclassifieds. The Residentials believe local roads should be tagged as residential, whether people live there, or whether there are shops or industry as well. The Unclassifieds reject this believe, according to them streets can only be tagged as residential if people live there, but not if there are shops or industry. Then the unclassied tag has to be used. It is easy to see where the different groups live, looking at the ratio residential / unclassified streets. Now with the AND import coming soon, we have to decide how to converse AND local streets, to residential or unclassified. So, is there actually an intelligent design behind residential versus unclassified, or is it just survival of the fittest? Can we look for guidance, or will there be no answer? 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, Lambertus <[EMAIL PROTECTED]> wrote: > 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. Maar als wij een server opstellen met de oude data dan kan je in JOSM gewoon de oude en de nieuwe data in apart layers tegelijk kijken en dan makkelijk vergelijken. 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?
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?
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?
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
