[OSM-talk-nl] BAG import nacontrole
Ik kwam toevallig in Blerick een groot aantal unconnected nodes tegen. Na wat verder zoeken zag ik ook wat oude 3dshapes buildings nog over de nieuwere BAG gebouwen liggen. Ik neem dus aan dat hier een BAG import niet helemaal goed gegaan is. De BAG import daar was van juni, dus ik heb alles maar een beetje opgeruimd. keepright laat het mooi zien http://keepright.at/report_map.php?zoom=16lat=51.37323lon=6.14222layers=B0Tch=0%2C70%2C20show_ign=1show_tmpign=1 (zolang de data niet geupdate wordt). Toen ben ik verder gaan kijken. In Melick kwam ik ze ook tegen. In Herkenbosch waren alle adres nodes dubbel. Ik ben nu in Sittard bezig met unconnected nodes. Ik denk dat het een goed idee is om met zijn allen keepright even te gebruiken en zo wat overtollige nodes te verwijderen. Mijn settings op dit moment zijn om alleen missing tags en multiple nodes on the same spot te zien. Let me die laatste op dat je geen GSM masten verwijdert. Kan iemand dit ook even op het forum wil posten? Groeten, Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG import nacontrole
On 07/25/2014 12:11 PM, Maarten Deen wrote: Kan iemand dit ook even op het forum wil posten? Done: http://forum.openstreetmap.org/viewtopic.php?id=26440 Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] BAG import
Zo'n 5,5 maand na een discussie over de BAG import heeft Frederik Ramm afgelopen vrijdag een opmerking gemaakt over de import. Ben je geinteresserd in discussies over de trias politica, de handelwijze van dictators, functievermenging, governance, transparantie, de onvolwassenheid van OSM, beslissingsmethoden en nog veel meer, kijk dan naar de posts die sinds afgelopen vrijdag op het NL forum zijn gezet Cheers, Johan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Mijn import vanaf autocad en mijn ervaringen
Op Fri, 25 Mar 2011 20:02:58 +0100, schreef Lennard: Er zijn wel tools beschikbaar om vanaf (bepaalde) dxf'en naar iets openers te gaan. Okee, dat wist ik niet. Ik kon namelijk in eerste instantie niet direct iets vinden. (schijnbaar niet goed genoeg gezocht) 1. Node duplicates worden alleen gezien wanneer ze exact gelijk zijn. Dit gaat al snel fout met de precisie van een double. (is overigens makkelijk op te lossen) Afronden op de maximale precisie die OSM gebruikt, en dan vergelijken. Ik zat meer te denken aan alle nodes die binnen bv X cm van elkaar liggen. 2. Het originele bestand heeft iets te veel nodes in de polylines (zie fietspad bij rotonde) Vereenvoudigen? Je kunt in JOSM met verschillende parameters voor simplify (area) spelen, zodat je wel het verloop van een weg houdt, maar toch overbodige nodes kwijtspeelt. Inderdaad! Ik vond het altijd veel te rigoureus, echter, je kan het instellen! :) 0.1 lijkt een goede waarde. 3. OSM heeft lang niet voor alle data die ik kwijt wil tags beschikbaar. Bijvoorbeeld de stoep, asfalt oppervlakte en druppels. Stoep - zie tagging ML van de afgelopen dagen. Waar kan ik dat precies vinden? Asfalt - surface=asphalt Maar dit is alleen van toepassing op highways? Niet op areas? Verder moet je jezelf de vraag stellen of je alle data die je in je dxf hebt zitten wel kwijt *wilt* in OSM? Bijvoorbeeld die druppels. Tja, waarom geen druppels en wel stoepranden of bermen tussen weg en fietspad? Misschien lijkt het nu een beetje veel, maar het past in principe prima in osm (mits tagging beschikbaar) en het zou hele mooie ingezoomde kaarten kunnen opleveren. 5. De RD conversie is naar ETRS89, dus max. 30cm afwijking met WGS84. Dat kan beter! :) Het is maar hoe je het bekijkt. Opzich is de conversie van RD naar ETRS89 de beste beschikbaar (de procedure van kadaster) Echter WGS84 is iets verschoven in een bepaalde richting ivm het schuiven van de continentale platen. Maar hier heeft OSM zowiezo nog wat op te lossen. Neem bijvoorbeeld Japan. Die zijn enkele meters opgeschoven, hoe gaan ze dat corrigeren? Graag jullie commentaar. De code is voorlopig niet opensource vanwege rdnaptrans, maar bij interesse wil ik deze graag uitlenen ;-) Waarom geen (variant van) proj4 gebruiken? Geen id :) Ook nog nooit van gehoord. Ik zal er eens naar kijken. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Mijn import vanaf autocad en mijn ervaringen
Ik heb laatst een autocad bestand gekregen van een nieuw bedrijventerein. Omdat je deze niet 1-2-3 kan copy pasten naar osm, heb ik speciaal hiervoor een rd-dxf2osm tooltje geschreven. Dit tooltje zet van de gekozen layer alle lines,polylines en arcs om naar osm ways en nodes. Inclusief het omzetten van de RD coordinaten naar lat/ lon. Het resultaat van dit tooltje kan je openen in bv josm om vervolgens van alle ways een mooi geheel te maken. Het eerste resultaat (nog niet volledig af) is hier: http://www.openstreetmap.org/?lat=52.09076lon=4.73662zoom=16layers=M Een aantal problemen die ik tegenkwam: 1. Node duplicates worden alleen gezien wanneer ze exact gelijk zijn. Dit gaat al snel fout met de precisie van een double. (is overigens makkelijk op te lossen) 2. Het originele bestand heeft iets te veel nodes in de polylines (zie fietspad bij rotonde) 3. OSM heeft lang niet voor alle data die ik kwijt wil tags beschikbaar. Bijvoorbeeld de stoep, asfalt oppervlakte en druppels. 4. Erg veel werk om alles aan elkaar te knopen. OSM werkt met ways/areas, Autocad bestanden zijn een verzameling van lijntjes. 5. De RD conversie is naar ETRS89, dus max. 30cm afwijking met WGS84. Graag jullie commentaar. De code is voorlopig niet opensource vanwege rdnaptrans, maar bij interesse wil ik deze graag uitlenen ;-) Groetjes Matthijs ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Mijn import vanaf autocad en mijn ervaringen
On 25-3-2011 19:54, Matthijs Benschop wrote: Ik heb laatst een autocad bestand gekregen van een nieuw bedrijventerein. Omdat je deze niet 1-2-3 kan copy pasten naar osm, heb ik speciaal hiervoor een rd-dxf2osm tooltje geschreven. Er zijn wel tools beschikbaar om vanaf (bepaalde) dxf'en naar iets openers te gaan. 1. Node duplicates worden alleen gezien wanneer ze exact gelijk zijn. Dit gaat al snel fout met de precisie van een double. (is overigens makkelijk op te lossen) Afronden op de maximale precisie die OSM gebruikt, en dan vergelijken. 2. Het originele bestand heeft iets te veel nodes in de polylines (zie fietspad bij rotonde) Vereenvoudigen? Je kunt in JOSM met verschillende parameters voor simplify (area) spelen, zodat je wel het verloop van een weg houdt, maar toch overbodige nodes kwijtspeelt. 3. OSM heeft lang niet voor alle data die ik kwijt wil tags beschikbaar. Bijvoorbeeld de stoep, asfalt oppervlakte en druppels. Stoep - zie tagging ML van de afgelopen dagen. Asfalt - surface=asphalt Verder moet je jezelf de vraag stellen of je alle data die je in je dxf hebt zitten wel kwijt *wilt* in OSM? Bijvoorbeeld die druppels. 4. Erg veel werk om alles aan elkaar te knopen. OSM werkt met ways/areas, Autocad bestanden zijn een verzameling van lijntjes. Goed he? :) Ik heb er ook al heel wat uurtjes aan besteedt. 5. De RD conversie is naar ETRS89, dus max. 30cm afwijking met WGS84. Dat kan beter! :) Graag jullie commentaar. De code is voorlopig niet opensource vanwege rdnaptrans, maar bij interesse wil ik deze graag uitlenen ;-) Waarom geen (variant van) proj4 gebruiken? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import en eilanden
2010/11/19 rob...@elsenaar.info: Theun schreef: Dus de tag natural=water op de innerway verwijderen zou het probleem van de renderer vermoedt ik wel verhelpen. Daar ben ik falikant op tegen. We gaan toch zeker niet mappen om de renderer te pleasen? Of om fouten van de renderer recht te breien? Waar gaat het heen op deze wereld. In het verre verleden, voor de zomer, is mij met de paplepel in gevoerd dat dat NIT mag. Moet die mappen maker maar beter zijn best doen. Of heb ik het vroeger verkeerd begrepen? ;-) Ja, ik denk dat je het verkeerd begrepen hebt. Of, misschien nog waarschijnlijker, dat degene die dat tegen je zei het verkeerd begrepen heeft. Wat we NIET, NOOIT, ONDER GEEN BEDING moeten doen, is iets mappen op een wijze die een _slechtere_ beschrijving van de werkelijkheid geeft omdat de renderer (of een bepaalde render) het dan beter rendert. Dus als renderer X een university aangeeft als een kledingwinkel, maar een school wel gewoon als een school, ga je niet universiteiten als scholen taggen om te zorgen dat ze goed getoond worden. Wat we WEL moeten doen is taggen op een manier die het renderen 'gemakkelijker' maakt _wanneer dat voor de correctheid niet uitmaakt_. Daar hoort bijvoorbeeld bij dat we zoveel mogelijk voorkomen om verschillende tags voor hetzelfde type object te maken (dus geen highway=autoweg gebruiken als highway=trunk al hetzelfde aangeeft en veel meer wordt gebruikt), maar ook dat we, als er zoals hier meerdere constructies zijn om precies hetzelfde aan te geven, en een daarvan tot verwarring bij de renderers aanleiding kan geven, een andere gebruiken. -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] AND-import en eilanden
Beste mensen, Het viel mij op dat op de OpenFietsMap bepaalde eilanden niet zichtbaar waren, maar op bijv. Mapnik en Osmarender wel. Het bleek dat er bij de gegevens van het 'eiland' een tag 'natural=water' is opgenomen in plaats van 'natural=land' of landuse of niets. Hierna heb ik een stuk of wat eilanden gewijzigd, maar lang niet alles... Vervolgens kwam ik enkele wateren met eilanden tegen die vanuit de 3dShapes geïmporteerd zijn, maar dubbel opgenomen zijn. Eenmaal in de relation als eiland en eenmaal met landuse=grass. (voorbeeld: way/83929221) Is dat de bedoeling? Is er iemand die met scripts deze zaken kan rechtzetten? Groeten, Dirk ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import en eilanden
Dirk, Dank je voor de info. heb je een voorbeeld? Ik wil dit graag eens zien. Note: ik kan dit niet oplossen maar ik zal proberen te helpen. Groet, Frank Op 19 november 2010 14:23 schreef DTeelde dtee...@kpnmail.nl het volgende: Beste mensen, Het viel mij op dat op de OpenFietsMap bepaalde eilanden niet zichtbaar waren, maar op bijv. Mapnik en Osmarender wel. Het bleek dat er bij de gegevens van het 'eiland' een tag 'natural=water' is opgenomen in plaats van 'natural=land' of landuse of niets. Hierna heb ik een stuk of wat eilanden gewijzigd, maar lang niet alles... Vervolgens kwam ik enkele wateren met eilanden tegen die vanuit de 3dShapes geïmporteerd zijn, maar dubbel opgenomen zijn. Eenmaal in de relation als eiland en eenmaal met landuse=grass. (voorbeeld: way/83929221) Is dat de bedoeling? Is er iemand die met scripts deze zaken kan rechtzetten? Groeten, Dirk ___ 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] AND-import en eilanden
Bij de import van de AND-data is een oude manier van het aanmaken van multipolygons gebruikt. Het is nu de bedoeling dat inner ways van een multipolygon geen tagging krijgen, zie http://wiki.openstreetmap.org/wiki/Multipolygon_relation#Tagging. Komen ze wel voor dan zouden ze behandeld moeten worden als niet bestaand. Blijkbaar doet de renderer van de OpenFietsMap dat niet. Dus de tag natural=water op de innerway verwijderen zou het probleem van de renderer vermoedt ik wel verhelpen. Bij het importeren van de 3dShapes zal het AND water waarschijnlijk op de meeste plekken overbodig worden, maar ik weet niet wanneer dit voor heel Nederland klaar zal zijn.. 3dShapes: Bij de 3dShapes import worden de tags alleen op de relatie gezet en niet op outer en innerways. Het eiland dat binnen de multipolygoon valt wordt noch weer een keer toegevoegd met de tag die het binnenste deel beschrijft, of er zijn meerdere vlakken die het eiland opvullen, er is van alles mogelijk. Zo kun je ook een innerway hebben van hetzelfde type als de omliggende multipolygon (bijvoorbeeld een stuk grasland, omgeven door een sloot in een groter perceel grasland). Met de oude manier zou dat niet lukken. De way die je als voorbeeld hebt aangegeven is 2 weken geleden toegevoegd. Ik moet hier noch wel wat nabewerking doen, want het AND water staat er ook nog op. Hoop ik binnenkort (dit weekend) te gaan doen. Groeten Theun, ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import en eilanden
Theun schreef: Dus de tag natural=water op de innerway verwijderen zou het probleem van de renderer vermoedt ik wel verhelpen. Daar ben ik falikant op tegen. We gaan toch zeker niet mappen om de renderer te pleasen? Of om fouten van de renderer recht te breien? Waar gaat het heen op deze wereld. In het verre verleden, voor de zomer, is mij met de paplepel in gevoerd dat dat NIT mag. Moet die mappen maker maar beter zijn best doen. Of heb ik het vroeger verkeerd begrepen? ;-) Robert Citeren Theun theun.m...@gmail.com: Bij de import van de AND-data is een oude manier van het aanmaken van multipolygons gebruikt. Het is nu de bedoeling dat inner ways van een multipolygon geen tagging krijgen, zie http://wiki.openstreetmap.org/wiki/Multipolygon_relation#Tagging. Komen ze wel voor dan zouden ze behandeld moeten worden als niet bestaand. Blijkbaar doet de renderer van de OpenFietsMap dat niet. Dus de tag natural=water op de innerway verwijderen zou het probleem van de renderer vermoedt ik wel verhelpen. Bij het importeren van de 3dShapes zal het AND water waarschijnlijk op de meeste plekken overbodig worden, maar ik weet niet wanneer dit voor heel Nederland klaar zal zijn.. 3dShapes: Bij de 3dShapes import worden de tags alleen op de relatie gezet en niet op outer en innerways. Het eiland dat binnen de multipolygoon valt wordt noch weer een keer toegevoegd met de tag die het binnenste deel beschrijft, of er zijn meerdere vlakken die het eiland opvullen, er is van alles mogelijk. Zo kun je ook een innerway hebben van hetzelfde type als de omliggende multipolygon (bijvoorbeeld een stuk grasland, omgeven door een sloot in een groter perceel grasland). Met de oude manier zou dat niet lukken. De way die je als voorbeeld hebt aangegeven is 2 weken geleden toegevoegd. Ik moet hier noch wel wat nabewerking doen, want het AND water staat er ook nog op. Hoop ik binnenkort (dit weekend) te gaan doen. Groeten Theun, ___ 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] AND-import en eilanden
We worden toch niet opstandig ;) Ik kan me voorstellen dat je de verouderde tagging update zodat je beter bij de huidige standaard aansluit. Is iets anders dan tagging afwijkend van het tagging schema om de kaart in te kleuren... Zou natuurlijk beter zijn dat de renderer ook die oudere manier van taggen support. Maar kan me ook voorstellen dat het niet verkeerd is de tagging die nu als verkeerd (of minder goed) wordt beschouwd op enig moment aan te passen. theun, Theun schreef: Dus de tag natural=water op de innerway verwijderen zou het probleem van de renderer vermoedt ik wel verhelpen. Daar ben ik falikant op tegen. We gaan toch zeker niet mappen om de renderer te pleasen? Of om fouten van de renderer recht te breien? Waar gaat het heen op deze wereld. In het verre verleden, voor de zomer, is mij met de paplepel in gevoerd dat dat NIT mag. Moet die mappen maker maar beter zijn best doen. Of heb ik het vroeger verkeerd begrepen? ;-) Robert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import en eilanden
Is toch uitstekend? Opschonen van die oude meuk en je houden aan de afspraken die op Wiki worden beschreven. En ik ben niet opstandig, ik ben gewoon in vrijdagmiddagmood en dus voor een flink deel ontoerekeningsvatbaar. Hebben meer mensen daar last van? groet Robert -Oorspronkelijk bericht- From: Theun Sent: Friday, November 19, 2010 4:04 PM To: OpenStreetMap NL discussion list Subject: Re: [OSM-talk-nl] AND-import en eilanden We worden toch niet opstandig ;) Ik kan me voorstellen dat je de verouderde tagging update zodat je beter bij de huidige standaard aansluit. Is iets anders dan tagging afwijkend van het tagging schema om de kaart in te kleuren... Zou natuurlijk beter zijn dat de renderer ook die oudere manier van taggen support. Maar kan me ook voorstellen dat het niet verkeerd is de tagging die nu als verkeerd (of minder goed) wordt beschouwd op enig moment aan te passen. theun, Theun schreef: Dus de tag natural=water op de innerway verwijderen zou het probleem van de renderer vermoedt ik wel verhelpen. Daar ben ik falikant op tegen. We gaan toch zeker niet mappen om de renderer te pleasen? Of om fouten van de renderer recht te breien? Waar gaat het heen op deze wereld. In het verre verleden, voor de zomer, is mij met de paplepel in gevoerd dat dat NIT mag. Moet die mappen maker maar beter zijn best doen. Of heb ik het vroeger verkeerd begrepen? ;-) Robert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl --- Tekst ingevoegd door Panda GP 2010: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_928SPAM=truepath=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202010\AntiSpam --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import en eilanden
Hey, Leuk dat lullen in de ruimte, voorbeeld aub. Dan kunnen we kijken wat er mis is en kan ik ook mee praten ;) Groet, Frank Op 19 november 2010 16:58 schreef Robert Elsenaar rob...@elsenaar.info het volgende: Is toch uitstekend? Opschonen van die oude meuk en je houden aan de afspraken die op Wiki worden beschreven. En ik ben niet opstandig, ik ben gewoon in vrijdagmiddagmood en dus voor een flink deel ontoerekeningsvatbaar. Hebben meer mensen daar last van? groet Robert -Oorspronkelijk bericht- From: Theun Sent: Friday, November 19, 2010 4:04 PM To: OpenStreetMap NL discussion list Subject: Re: [OSM-talk-nl] AND-import en eilanden We worden toch niet opstandig ;) Ik kan me voorstellen dat je de verouderde tagging update zodat je beter bij de huidige standaard aansluit. Is iets anders dan tagging afwijkend van het tagging schema om de kaart in te kleuren... Zou natuurlijk beter zijn dat de renderer ook die oudere manier van taggen support. Maar kan me ook voorstellen dat het niet verkeerd is de tagging die nu als verkeerd (of minder goed) wordt beschouwd op enig moment aan te passen. theun, Theun schreef: Dus de tag natural=water op de innerway verwijderen zou het probleem van de renderer vermoedt ik wel verhelpen. Daar ben ik falikant op tegen. We gaan toch zeker niet mappen om de renderer te pleasen? Of om fouten van de renderer recht te breien? Waar gaat het heen op deze wereld. In het verre verleden, voor de zomer, is mij met de paplepel in gevoerd dat dat NIT mag. Moet die mappen maker maar beter zijn best doen. Of heb ik het vroeger verkeerd begrepen? ;-) Robert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl --- Tekst ingevoegd door Panda GP 2010: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_928SPAM=truepath=C :\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202010\AntiSpam --- ___ 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] AND-import en eilanden
Tnx, hoe vindt je die als ik vragen mag? Via JOSM, of zie je ze al op de kaart? Groet, Frank Op 19 november 2010 22:33 schreef DTeelde dtee...@kpnmail.nl het volgende: Hier is een voorbeeld te vinden: http://www.openstreetmap.org/browse/relation/1843 (versie 2) met ways http://www.openstreetmap.org/browse/way/6298379 (versie 1) http://www.openstreetmap.org/browse/way/8165586 (versie 1) Groeten, Dirk ___ 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] AND-import en eilanden
Ik ben relation 1850 (Zuidlaardermeer) als eerste tegengekomen. En daarna heb ik op de pagina voor deze relatie een aantal keren 'volgende relatie' gedaan. En de foutieve geladen in JOSM (Downloaden Object) en handmatig gewijzigd. Groeten, Dirk (Ik ben bang dat ik weer een nieuwe thread begin, sorry.) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] fietsrouteplanner? import
Hallo, Naar aanleiding van wijzigingen in Tilburg van 22 juni [1] door user fietsrouteplanner2. Gezien de naam van de gebruiker lijkt het erop dat deze data afkomstig is van het fietsrouteplanner project dat enige tijd geleden is aangekondigd [2]. Erg mooi dat we de data die daarvoor extra verzameld is terugkrijgen, maar toch het verzoek om iets nauwkeuriger te werk te gaan. Even een lijst van wat er in dat gebied (waarschijnlijk onbewust) fout is gegaan: - Op een flink aantal wegen en nodes was de tag highway=residental (ipv residential) geplaatst. Ook op stukken spoorlijn, nodes en bestaande doorgaande wegen. - foot=jes en bicycle=jes op wegen (moet =yes zijn, maar is ook nog eens overbodig op de meeste wegtypes en incorrect op gebouwen). - Veel kleine (een paar meter lange) ways, niet doen als er geen aanleiding voor is. Deze korte stukjes zijn namelijk niet of nauwelijks te onderhouden omdat je ze over het hoofd ziet bij het editen. - Ways die halverwege onderbroken zijn. Tenzij er een goede reden voor is, probeer ways aaneengesloten te houden en alleen te splitsen op een kruising of een scherpe bocht. Dus niet één node de hoek om gaan en dan splitsen. We zijn ondertussen al een maand verder en dus heb ik nog een paar van de laatste changesets bekeken. En daar zag ik gedeeltelijk hetzelfde. Ways die op een onlogische plek gesplitst zijn. Ways die elkaar kruisen zonder een verbings-node of een bridge=yes [3]. Ik Hoop dat dit verhaal niet te negatief overkomt en niet persoonlijk opgevat wordt. Deze data kan zeker een toevoeging zijn voor OSM. René [1] http://www.openstreetmap.org/browse/changeset/5049739 [2] http://lists.openstreetmap.org/pipermail/talk-nl/2010-March/010777.html [3] http://www.openstreetmap.org/?lat=51.08661lon=5.96496zoom=16 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsrouteplanner? import
Hoi René,bedankt voor je feedback - fietsrouteplanner2 is daadwerkelijk een van de studenten die door ons begeleid op vrij grote schaal fietsinfrastructuur en ontbrekende wegen toevoegen aan Openstreetmap tbv het fietsrouteplanner-project. Het blijft een uitdaging en verantwoordelijkheid voor ons hier goede begeleiding en controle uit te oefenen.Wij hadden zelf al topologische fouten opgemerkt en zijn begonnen deze te herstellen.Groeten, DirkHallo,Naar aanleiding van wijzigingen in Tilburg van 22 juni [1] door userfietsrouteplanner2.Gezien de naam van de gebruiker lijkt het erop dat deze data afkomstigis van het fietsrouteplanner project dat enige tijd geleden isaangekondigd [2]. Erg mooi dat we de data die daarvoor extra verzameldis terugkrijgen, maar toch het verzoek om iets nauwkeuriger te werk tegaan.Even een lijst van wat er in dat gebied (waarschijnlijk onbewust) foutis gegaan:- Op een flink aantal wegen en nodes was de tag highway=residental(ipv residential) geplaatst. Ook op stukken spoorlijn, nodes enbestaande doorgaande wegen.- foot=jes en bicycle=jes op wegen (moet =yes zijn, maar is ook nogeens overbodig op de meeste wegtypes en incorrect op gebouwen).- Veel kleine (een paar meter lange) ways, niet doen als er geenaanleiding voor is. Deze korte stukjes zijn namelijk niet ofnauwelijks te onderhouden omdat je ze over het hoofd ziet bij hetediten.- Ways die halverwege onderbroken zijn. Tenzij er een goede reden vooris, probeer ways aaneengesloten te houden en alleen te splitsen op eenkruising of een scherpe bocht. Dus niet één node de hoek om gaan endan splitsen.We zijn ondertussen al een maand verder en dus heb ik nog een paar vande laatste changesets bekeken. En daar zag ik gedeeltelijk hetzelfde.Ways die op een onlogische plek gesplitst zijn. Ways die elkaarkruisen zonder een verbings-node of een bridge=yes [3].Ik Hoop dat dit verhaal niet te negatief overkomt en niet persoonlijkopgevat wordt. Deze data kan zeker een toevoeging zijn voor OSM.René[1] http://www.openstreetmap.org/browse/changeset/5049739[2] http://lists.openstreetmap.org/pipermail/talk-nl/2010-March/010777.html[3] http://www.openstreetmap.org/?lat=51.08661lon=5.96496zoom=16___Talk-nl mailing listTalk-nl@openstreetmap.orghttp://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] fietsrouteplanner? import
Ik zie in de omgeving waar ik wel eens kom ook 'artifacten', bijvoorbeeld: http://www.openstreetmap.org/browse/changeset/5462135 Op deze manier at random door de changesets lopen schiet niet zo heel erg op. Is er een manier waarop ik de wijzigingen in een bepaald periode binnen een beperkt gebied kan opvragen? mvg, (een andere) René 2010/8/24 dbuss...@goudappel.nl Hoi René, bedankt voor je feedback - fietsrouteplanner2 is daadwerkelijk een van de studenten die door ons begeleid op vrij grote schaal fietsinfrastructuur en ontbrekende wegen toevoegen aan Openstreetmap tbv het fietsrouteplanner-project. Het blijft een uitdaging en verantwoordelijkheid voor ons hier goede begeleiding en controle uit te oefenen. Wij hadden zelf al topologische fouten opgemerkt en zijn begonnen deze te herstellen. Groeten, Dirk Hallo, Naar aanleiding van wijzigingen in Tilburg van 22 juni [1] door user fietsrouteplanner2. Gezien de naam van de gebruiker lijkt het erop dat deze data afkomstig is van het fietsrouteplanner project dat enige tijd geleden is aangekondigd [2]. Erg mooi dat we de data die daarvoor extra verzameld is terugkrijgen, maar toch het verzoek om iets nauwkeuriger te werk te gaan. Even een lijst van wat er in dat gebied (waarschijnlijk onbewust) fout is gegaan: - Op een flink aantal wegen en nodes was de tag highway=residental (ipv residential) geplaatst. Ook op stukken spoorlijn, nodes en bestaande doorgaande wegen. - foot=jes en bicycle=jes op wegen (moet =yes zijn, maar is ook nog eens overbodig op de meeste wegtypes en incorrect op gebouwen). - Veel kleine (een paar meter lange) ways, niet doen als er geen aanleiding voor is. Deze korte stukjes zijn namelijk niet of nauwelijks te onderhouden omdat je ze over het hoofd ziet bij het editen. - Ways die halverwege onderbroken zijn. Tenzij er een goede reden voor is, probeer ways aaneengesloten te houden en alleen te splitsen op een kruising of een scherpe bocht. Dus niet één node de hoek om gaan en dan splitsen. We zijn ondertussen al een maand verder en dus heb ik nog een paar van de laatste changesets bekeken. En daar zag ik gedeeltelijk hetzelfde. Ways die op een onlogische plek gesplitst zijn. Ways die elkaar kruisen zonder een verbings-node of een bridge=yes [3]. Ik Hoop dat dit verhaal niet te negatief overkomt en niet persoonlijk opgevat wordt. Deze data kan zeker een toevoeging zijn voor OSM. René [1] http://www.openstreetmap.org/browse/changeset/5049739 [2] http://lists.openstreetmap.org/pipermail/talk-nl/2010-March/010777.html [3] http://www.openstreetmap.org/?lat=51.08661lon=5.96496zoom=16 ___ 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] fietsrouteplanner? import
http://www.itoworld.com/static/osm_mapper.html Op 24 augustus 2010 22:55 heeft Rene Dohmen rdohmen+osm-talk...@gmail.com het volgende geschreven: Ik zie in de omgeving waar ik wel eens kom ook 'artifacten', bijvoorbeeld: http://www.openstreetmap.org/browse/changeset/5462135 Op deze manier at random door de changesets lopen schiet niet zo heel erg op. Is er een manier waarop ik de wijzigingen in een bepaald periode binnen een beperkt gebied kan opvragen? mvg, (een andere) René 2010/8/24 dbuss...@goudappel.nl Hoi René, bedankt voor je feedback - fietsrouteplanner2 is daadwerkelijk een van de studenten die door ons begeleid op vrij grote schaal fietsinfrastructuur en ontbrekende wegen toevoegen aan Openstreetmap tbv het fietsrouteplanner-project. Het blijft een uitdaging en verantwoordelijkheid voor ons hier goede begeleiding en controle uit te oefenen. Wij hadden zelf al topologische fouten opgemerkt en zijn begonnen deze te herstellen. Groeten, Dirk Hallo, Naar aanleiding van wijzigingen in Tilburg van 22 juni [1] door user fietsrouteplanner2. Gezien de naam van de gebruiker lijkt het erop dat deze data afkomstig is van het fietsrouteplanner project dat enige tijd geleden is aangekondigd [2]. Erg mooi dat we de data die daarvoor extra verzameld is terugkrijgen, maar toch het verzoek om iets nauwkeuriger te werk te gaan. Even een lijst van wat er in dat gebied (waarschijnlijk onbewust) fout is gegaan: - Op een flink aantal wegen en nodes was de tag highway=residental (ipv residential) geplaatst. Ook op stukken spoorlijn, nodes en bestaande doorgaande wegen. - foot=jes en bicycle=jes op wegen (moet =yes zijn, maar is ook nog eens overbodig op de meeste wegtypes en incorrect op gebouwen). - Veel kleine (een paar meter lange) ways, niet doen als er geen aanleiding voor is. Deze korte stukjes zijn namelijk niet of nauwelijks te onderhouden omdat je ze over het hoofd ziet bij het editen. - Ways die halverwege onderbroken zijn. Tenzij er een goede reden voor is, probeer ways aaneengesloten te houden en alleen te splitsen op een kruising of een scherpe bocht. Dus niet één node de hoek om gaan en dan splitsen. We zijn ondertussen al een maand verder en dus heb ik nog een paar van de laatste changesets bekeken. En daar zag ik gedeeltelijk hetzelfde. Ways die op een onlogische plek gesplitst zijn. Ways die elkaar kruisen zonder een verbings-node of een bridge=yes [3]. Ik Hoop dat dit verhaal niet te negatief overkomt en niet persoonlijk opgevat wordt. Deze data kan zeker een toevoeging zijn voor OSM. René [1] http://www.openstreetmap.org/browse/changeset/5049739 [2] http://lists.openstreetmap.org/pipermail/talk-nl/2010-March/010777.html [3] http://www.openstreetmap.org/?lat=51.08661lon=5.96496zoom=16 ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsrouteplanner? import
On Tue, 24 Aug 2010 22:21:50 +0200, dbuss...@goudappel.nl wrote: Hoi René, bedankt voor je feedback - fietsrouteplanner2 is daadwerkelijk een van de studenten die door ons begeleid op vrij grote schaal fietsinfrastructuur en ontbrekende wegen toevoegen aan Openstreetmap tbv het fietsrouteplanner-project. Het blijft een uitdaging en verantwoordelijkheid voor ons hier goede begeleiding en controle uit te oefenen. Wij hadden zelf al topologische fouten opgemerkt en zijn begonnen deze te herstellen. Ik had hetzelfde met fietsrouteplanner3. Die heb ik al eens een bericht gestuurd met opmerkingen over zijn mappen, maar nooit een reactie terug gekregen. Wat ik van deze user zie: - fietspaden bij kruisingen niet verbinden met de weg - fietspaden aanleggen naast bestaande (fiets)paden - veel was dubbel aangemaakt (zal wel een afgebroken import geweest zijn) - verbindingen waar het (fiets)pad de doortrekking van een doodlopende weg is niet maken. Ik Hoop dat dit verhaal niet te negatief overkomt en niet persoonlijk opgevat wordt. Deze data kan zeker een toevoeging zijn voor OSM. Dat is ook mijn idee. Alleen jammer dat je op de private messages geen reactie op feedback krijgt. Goed, nu ik weet hoe die wegen zijn gekomen zal ik ze gewoon corrigeren als ik ze tegen kom. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Foute import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 26-06-10 00:53, Cartinus schreef: On Friday 25 June 2010 22:16:36 Stefan de Konink wrote: 3) Heeft iemand iets gehoord over deze import voordat hij plaatsvond? Mijn IRC logs zegt zelfs dat Lennard de integratie query voor me heeft gefixed ;) O, jij droomt nog steeds dat wat op IRC zeggen communiceren is met de Community. Omdat jij niet op IRC zit betekent niet dat er geen community is. Maar droom lekker verder! Dat is waar het echt mis gaat. Er is zo te zien geen enkele poging gedaan om de nieuwe en oude data te integreren tijdens de import. Is wel gebeurd. Er is zelfs op alle nieuwe data een Fixme tag gezet, mits hij binnen een paar meter viel van een bestaande bushalte. Deze import bevatte veel meer data dan huidige data, en is zelfs als leidend te bestempelen omdat het wordt gebruikt voor de berekening van jouw OV-chip tarief. Zoals op het fan-tas-ti-sche IRC kanaal is besproken: iedere fout die gevonden wordt, is geld dat je teveel of te weinig betaalt. Ongeloveloze vette kwats. Er staat geen enkele FIXME op de nieuwe bushaltes in Utrecht e.o.. (Hard zoeken, dan kun je misschien die ene vinden die me hierin ongelijk geeft.) Ik heb even in Utrecht gekeken, en als het hebt over nodes die meer dan 10 meter uit elkaar liggen, dan is dat absoluut de bedoeling geweest. Want de rest van Nederland staan de heen en terug haltes binnen 10 meter van elkaar. So what? Alle data is door de handen van minimaal 4 mensen gegaan voor dat er iets is geïmporteerd. Dus de Community in Nederland is volgens jou ongeveer vier man groot en bevind zich op IRC . Nee hoor, vier man die de data hebben bekeken. Op een goeie dag zitten er minimaal 30 op IRC. Dan is het dus duidelijk waarom we zo'n moeite hebben met het bouwen van een fatsoenlijke Community. Nouja als je dit vanaf buiten bekijkt dan wil je niet eens meer wat bijdragen aan de Nederlandse OSM omdat je of de Tuinen Gestapo over je heen krijgt of meneer Cartinus die op de mailinglijst z'n plasje moet doen. ben aanwezig waar mensen daadwerkelijk wat doen. OSM is een crowd sourced mapping project. Wat dat onder andere inhoud, is dat je je helemaal suf kunt importeren, maar als je (bijna) niemand hebt die die data vervolgens onderhoud of bijwerkt, dan heb je vervolgens alleen maar een bak met bit-rot. Voor dat onderhoud zal men toch echt naar buiten moeten om in het veld te kijken hoe het er in het echt uit ziet. Maar ja dat veldwerk en de verwerking daarvan is volgens jou vast niets doen. Daarom is het coördineren van je imports met die veldwerkers vast ook niet nodig. ;) oh is dat het probleem ;) Dus als ik straks alle bushaltes die niet van mij zijn uit OSM gooi, en alle Nederlandse routes even via openov.nl toevoeg dan is iedereen weer blij? Wat naïef zeg :) En gezien ik geen berichtje heb gehad van iemand na de import, ben ik benieuwd of dit weer een van de op de man speel acties van je is, of dat je nog wat inhoudelijks hebt bij te dragen. Sorry tussen 19 juni (volgens de data zijn de nieuwe bushaltes toen verschenen) en gisteren (inmiddels eergisteren) heb ik niet naar de OSM data gekeken, dat doe ik namelijk niet iedere dag. Ik ben iedere dag met OSM bezig, dus daar moet ik ook maar mee stoppen? Het feit dat het een slecht uitgevoerde niet in de community ingebedde import was lijkt me inhoudelijk genoeg. Die import regels zijn inderdaad niet hard, want niets is dat in OSM. Ze zijn echter het resultaat van de ervaring die in de loop der jaren is opgebouwd. Het is van buiten Nederland niet moeilijk om te zijn dat het land waar ze zo dol zijn op imports de grootste moeite heeft om mappers in beweging te krijgen. Ditto de USA met z'n Tiger import. Er zijn helemaal geen 'regels' in OSM... het grappige is ook dat met de grote hoeveelheden automatische imports bitrot ook wordt opgelost. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkwl69sACgkQYH1+F2Rqwn1yvQCfRHxtmR63pJ32HU3xXKpjWe6N 6RkAnR0Q6UaCctHp4daFSgGDHC+uqD+G =r8Wt -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Foute import
On Saturday 26 June 2010 14:00:27 Stefan de Konink wrote: Er staat geen enkele FIXME op de nieuwe bushaltes in Utrecht e.o.. (Hard zoeken, dan kun je misschien die ene vinden die me hierin ongelijk geeft.) Ik heb even in Utrecht gekeken, en als het hebt over nodes die meer dan 10 meter uit elkaar liggen, dan is dat absoluut de bedoeling geweest. Want de rest van Nederland staan de heen en terug haltes binnen 10 meter van elkaar. en 4,6 meter is dat ook te ver (Afrikalaan)? en 3,5 meter is dat ook te ver (P+R Papendorp)? en 2,9 meter is dat ook te ver (Kanaleneiland)? Ben je niet gewoon vergeten die test aan te zetten tijdens de import? On Saturday 26 June 2010 14:00:27 Stefan de Konink wrote: Sorry tussen 19 juni (volgens de data zijn de nieuwe bushaltes toen verschenen) en gisteren (inmiddels eergisteren) heb ik niet naar de OSM data gekeken, dat doe ik namelijk niet iedere dag. Ik ben iedere dag met OSM bezig, dus daar moet ik ook maar mee stoppen? Kan iemand mij mischien uitleggen hoe je van wat ik zeg tot Stefan z'n conclusie kunt komen? Als ik Stefan leer begrijpen heb ik mischien minder problemen met met wat hij probeert te zeggen. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Foute import
On Saturday 26 June 2010 21:07:50 Cartinus wrote: Ben je niet gewoon vergeten die test aan te zetten tijdens de import? Oh, ik heb er één gevonden. Het blijkt minder dan één meter te moeten zijn. Geen wonder dat je zo goed als niets vind. Vrij zinloze test dus. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Foute import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 26-06-10 21:07, Cartinus schreef: Ben je niet gewoon vergeten die test aan te zetten tijdens de import? Nee hoor, ik heb zelfs het .osm bestand nog voor je. De fixme's staan er gewoon in. On Saturday 26 June 2010 14:00:27 Stefan de Konink wrote: Sorry tussen 19 juni (volgens de data zijn de nieuwe bushaltes toen verschenen) en gisteren (inmiddels eergisteren) heb ik niet naar de OSM data gekeken, dat doe ik namelijk niet iedere dag. Ik ben iedere dag met OSM bezig, dus daar moet ik ook maar mee stoppen? Kan iemand mij mischien uitleggen hoe je van wat ik zeg tot Stefan z'n conclusie kunt komen? Als ik Stefan leer begrijpen heb ik mischien minder problemen met met wat hij probeert te zeggen. Jij wilt duidelijk overleg over alle acties die een individu doet. Dus als iemand dagelijks met OSM bezig is kun je natuurlijk niet met iedereen overleggen die daar niet dagelijks aan werkt. Oh, ik heb er één gevonden. Het blijkt minder dan één meter te moeten zijn. Geen wonder dat je zo goed als niets vind. Vrij zinloze test dus. 262, de volgende zou 415 zijn. Maar daarmee krijg je al false positives. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkwmbVgACgkQYH1+F2Rqwn1ZWQCffNLtX2PS1swr6qh6T0DjFJuZ czYAoIsL5hA72tPjqRrh7FsrBViEUNjV =FyJU -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Foute import (was: Re: juridische status 3d shapes bestand)
On Friday 25 June 2010 13:32:27 Stefan de Konink wrote: Op 25-06-10 13:23, Cartinus schreef: Ik heb dit jaar duidelijk al veel meer gedaan dan alleen maar het importeren van bushaltes die al in OSM stonden. http://www.openstreetmap.org/user/Stefan de Konink/edits Achja ;) Laten we vooral wijzen op wat PIO's die toevallig worden gebruikt om OVChip tarieven te berekenen en toevallig ook haltenummers bevatten ;) Of al die edits die op de bestaande bushaltes zone informatie zette ;) http://wiki.openstreetmap.org/wiki/Import/Guidelines 1) Is alleen maar een waarschuwing, maar ik kom er later op terug. 2) Licentie zal wel OK zijn. (Hopelijk is dat ook te bewijzen.) 3) Heeft iemand iets gehoord over deze import voordat hij plaatsvond? 4) Weet iemand waar de wiki-pagina voor deze import te vinden is? 5) Dedicated account was blijkbaar niet nodig volgens Stefan. 6) Tag prefix: OK 7) Import gaat zo te zien in delen, dus server problemen zullen er wel niet zijn. 8) quote Don't screw up the data! Do not ignore existing data and import new data over the top. In general it is a bad idea to put data on top of data ..., but also you must always remember that existing data may be data that a real user cares about and is maintaining. You might try to determine this with automated/semi-automated methods, and treat the existing data accordingly. For example in areas where real users are working, you might decide to leave the existing data alone. /quote Dat is waar het echt mis gaat. Er is zo te zien geen enkele poging gedaan om de nieuwe en oude data te integreren tijdens de import. Als dat om één of andere reden echt allemaal met de hand moet en je wilt je community betrokken houden dan mobiliseer je die mankracht van te voren. Dus niet de data erin pleuren en hopen dat iemand anders het later nog wel eens een keer integreerd. (Denk aan punt 1) Voorbeelden dat dat niet alleen maar dromen is maar ook echt werkt: * Import bushaltes in Engeland: Gaat per regio en heeft speciale tool om de data te vinden. http://wiki.openstreetmap.org/wiki/Naptan * Landgebruik import in Frankrijk: Volautomatisch waar nog geen data was. Hapklare brokken voor de overige gebieden, zodat import en merge meteen na elkaar kunnen gebeuren. http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover In zekere zin is dit ook wat Ldp nu wel goed aan het doen is met de herclassificatie van wegen. Eerst een proefrenderer om de resultaten te bespreken, dan consensus zoeken. Tot slot pas uitvoeren (als de consensus er is). Dus je community betrokken houden kan ook in Nederland. Ten slotte voor de mensen die denken: Die paar bushaltes User:BugBlue is druk bezig met busroutes en alles wat daar aan vast hangt (zoals haltes). Ik weet niet hoever hij is met de rest van het land, maar de stad Utrecht en wijde omgeving was volgens mij wel af. Hij kon dat duidelijk wel: alleen die bushaltes toevoegen die nog ontbraken. Maar nu staan ze er dankzij Stefan dus allemaal dubbel in. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Foute import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 25-06-10 21:56, Cartinus schreef: 2) Licentie zal wel OK zijn. (Hopelijk is dat ook te bewijzen.) Valt niets aan te bewijzen. 3) Heeft iemand iets gehoord over deze import voordat hij plaatsvond? Mijn IRC logs zegt zelfs dat Lennard de integratie query voor me heeft gefixed ;) 4) Weet iemand waar de wiki-pagina voor deze import te vinden is? Geen idee :) 5) Dedicated account was blijkbaar niet nodig volgens Stefan. Nope, OSM is een anarchie! En ik ben de grote leider! *kuch* 7) Import gaat zo te zien in delen, dus server problemen zullen er wel niet zijn. Initieel 1 deel, maar ik had een probleem gevonden, waar escapes niet hebben gewerkt. Dat is waar het echt mis gaat. Er is zo te zien geen enkele poging gedaan om de nieuwe en oude data te integreren tijdens de import. Is wel gebeurd. Er is zelfs op alle nieuwe data een Fixme tag gezet, mits hij binnen een paar meter viel van een bestaande bushalte. Deze import bevatte veel meer data dan huidige data, en is zelfs als leidend te bestempelen omdat het wordt gebruikt voor de berekening van jouw OV-chip tarief. Zoals op het fan-tas-ti-sche IRC kanaal is besproken: iedere fout die gevonden wordt, is geld dat je teveel of te weinig betaalt. In zekere zin is dit ook wat Ldp nu wel goed aan het doen is met de herclassificatie van wegen. Eerst een proefrenderer om de resultaten te bespreken, dan consensus zoeken. Tot slot pas uitvoeren (als de consensus er is). Dus je community betrokken houden kan ook in Nederland. So what? Alle data is door de handen van minimaal 4 mensen gegaan voor dat er iets is geïmporteerd. Als je in een besluit proces betrokken wilt worden, ben aanwezig waar mensen daadwerkelijk wat doen. Ten opzichte van achteraf z e u r e n. Ten slotte voor de mensen die denken: Die paar bushaltes User:BugBlue is druk bezig met busroutes en alles wat daar aan vast hangt (zoals haltes). Ik weet niet hoever hij is met de rest van het land, maar de stad Utrecht en wijde omgeving was volgens mij wel af. Hij kon dat duidelijk wel: alleen die bushaltes toevoegen die nog ontbraken. Maar nu staan ze er dankzij Stefan dus allemaal dubbel in. Ik ben benieuwd waar BugBlue de informatie vandaan zou moeten hebben die in de cxx: prefix staat. Ik heb ze namelijk niet op bestaande nodes gevonden. En gezien ik geen berichtje heb gehad van iemand na de import, ben ik benieuwd of dit weer een van de op de man speel acties van je is, of dat je nog wat inhoudelijks hebt bij te dragen. Het hele busroute verhaal is namelijk *niet* opgelost, vrij simpel, iedere wijziging in een wegsloopt de 'render'-relatie namelijk. En trouwens waarom zeik je nu over de CXX import terwijl ik je nooit over de Veolia import heb gehoord? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkwlDqQACgkQYH1+F2Rqwn2JWQCeIgb/QimCzHRiJyM0RVaejsuc IHMAnRo7vdXHTb5AK3IFyAu4u3iDfS30 =9WOs -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Foute import
On Friday 25 June 2010 22:16:36 Stefan de Konink wrote: 3) Heeft iemand iets gehoord over deze import voordat hij plaatsvond? Mijn IRC logs zegt zelfs dat Lennard de integratie query voor me heeft gefixed ;) O, jij droomt nog steeds dat wat op IRC zeggen communiceren is met de Community. Dat is waar het echt mis gaat. Er is zo te zien geen enkele poging gedaan om de nieuwe en oude data te integreren tijdens de import. Is wel gebeurd. Er is zelfs op alle nieuwe data een Fixme tag gezet, mits hij binnen een paar meter viel van een bestaande bushalte. Deze import bevatte veel meer data dan huidige data, en is zelfs als leidend te bestempelen omdat het wordt gebruikt voor de berekening van jouw OV-chip tarief. Zoals op het fan-tas-ti-sche IRC kanaal is besproken: iedere fout die gevonden wordt, is geld dat je teveel of te weinig betaalt. Ongeloveloze vette kwats. Er staat geen enkele FIXME op de nieuwe bushaltes in Utrecht e.o.. (Hard zoeken, dan kun je misschien die ene vinden die me hierin ongelijk geeft.) ALLE bushaltes in Utrecht en omgeving staan er dubbel in vlak naast elkaar, er is dus geen enkele _werkende_ proximity test gedaan. En trouwens waarom zeik je nu over de CXX import terwijl ik je nooit over de Veolia import heb gehoord? Hoeveel Veolia bussen rijden er in Utrecht? Niet Veel! Hoeveel bushaltes uit die import staan er dus in Utrecht? Gokje: (bijna) geen! Aangezien over die import vast net zo uitgebreid is gecommuniceerd als deze, heb ik daar natuurlijk niets van gemerkt. Dan kan ik er ook geen commentaar op geven hé. So what? Alle data is door de handen van minimaal 4 mensen gegaan voor dat er iets is geïmporteerd. Dus de Community in Nederland is volgens jou ongeveer vier man groot en bevind zich op IRC . Dan is het dus duidelijk waarom we zo'n moeite hebben met het bouwen van een fatsoenlijke Community. ben aanwezig waar mensen daadwerkelijk wat doen. OSM is een crowd sourced mapping project. Wat dat onder andere inhoud, is dat je je helemaal suf kunt importeren, maar als je (bijna) niemand hebt die die data vervolgens onderhoud of bijwerkt, dan heb je vervolgens alleen maar een bak met bit-rot. Voor dat onderhoud zal men toch echt naar buiten moeten om in het veld te kijken hoe het er in het echt uit ziet. Maar ja dat veldwerk en de verwerking daarvan is volgens jou vast niets doen. Daarom is het coördineren van je imports met die veldwerkers vast ook niet nodig. En gezien ik geen berichtje heb gehad van iemand na de import, ben ik benieuwd of dit weer een van de op de man speel acties van je is, of dat je nog wat inhoudelijks hebt bij te dragen. Sorry tussen 19 juni (volgens de data zijn de nieuwe bushaltes toen verschenen) en gisteren (inmiddels eergisteren) heb ik niet naar de OSM data gekeken, dat doe ik namelijk niet iedere dag. Het feit dat het een slecht uitgevoerde niet in de community ingebedde import was lijkt me inhoudelijk genoeg. Die import regels zijn inderdaad niet hard, want niets is dat in OSM. Ze zijn echter het resultaat van de ervaring die in de loop der jaren is opgebouwd. Het is van buiten Nederland niet moeilijk om te zijn dat het land waar ze zo dol zijn op imports de grootste moeite heeft om mappers in beweging te krijgen. Ditto de USA met z'n Tiger import. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] AND import: highway=footway / pedestrian
Ik zie ze ook op bijvoorbeeld met een hek afgesloten bedrijven terreinen waarbij de wegen breed genoeg zijn voor twee vrachtwagens. Het gaat hier blijkbaar niet alleen om smalle wegen. Ook voor sommige voetgangers doorsteekjes (=footway) is in de AND import gebruik gemaakt voor pedestrian. Martijn van Exel wrote: Ha, Ik ben aan het mappen in Amsterdam-Noord en kom relatief veel highway=pedestrian tegen, waar volgens mij highway=footway zou moeten zijn getagged. Het gaat om AND-segmenten. Een voorbeeld: http://tile.openstreetmap.nl/?zoom=16lat=52.38896lon=4.9098layers=B00F waar langs de van der Pekstraat een 'highway=pedestrian' is, wat gewoon een trottoir is. Ik vraag me af welke criteria bij de AND-import zijn gebruikt om onderscheid te maken tussen highway=pedestrian en highway=footway. Een korte discussie op IRC leverde op dat footway toepasselijk is voor paden die te smal zijn om auto's door te laten ook al zou het mogen, terwijl pedestrian voor bredere paden / straten is waar wel autoverkeer door zou passen, maar waar voetgangers de dienst uitmaken. Zo lees ik het ook uit de Engelse map features-pagina. Klopt dit met de interpretatie bij de AND-import? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import: highway=footway / pedestrian
Dat zou dus, imho, niet moeten - al was het alleen maar omdat pedestrian echt als brede grijze weg wordt gerenderd in mapnik, en footway als stippellijntje. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ Op 13 feb 2008, om 14:24 heeft Lambertus het volgende geschreven: Ook voor sommige voetgangers doorsteekjes (=footway) is in de AND import gebruik gemaakt voor pedestrian. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import: highway=footway / pedestrian
On Wednesday 13 February 2008, Martijn van Exel wrote: Ik ben aan het mappen in Amsterdam-Noord en kom relatief veel highway=pedestrian tegen, waar volgens mij highway=footway zou moeten zijn getagged. Het gaat om AND-segmenten. [...] Klopt dit met de interpretatie bij de AND-import? Zie deze thread http://lists.openstreetmap.org/pipermail/talk-nl/2008-January/004190.html en mijn reactie http://lists.openstreetmap.org/pipermail/talk-nl/2008-January/004196.html Misschien moet het ergens duidelijker op de wiki komen te staan... -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
Ante Wessels wrote: Ik heb de kustlijn op de Belgische Schelde aan laten sluiten. http://www.openstreetmap.org/index.html?mlat=51.35944363666745mlon=4.238087545435507zoom=11 He? Is de kaart al gerenderd? Ziet er mooi uit! Hoop geprut omdat in BE er veel losse segmenten waren. De coastline gaat nu over in waterway=riverbank. We zullen zien of dat goed gaat. Ook de Schelde-Rijn verbinding aan laten sluiten (iets naar het oosten). Maas en Rijn zullen ook nog aandacht nodig hebben. Ik heb de kunstlijn bij Nieuwe Statenzijl gecorrigeerd en de Waal bij Spijk aangesloten op de Rijn. Omdat de landsgrens daar door de Waal gaat heeft AND geen data van de zuidelijke helft, maar op de grens loopt een natural=water. Wie daar de oude gegevens heeft mag dat aanvullen/verbeteren. Verder heb ik een paar eilandjes in de Waal gecorrigeerd (de way was helemaal doorgetrokken) en ik heb Baarle-Hertog/Baarle-Nassau gecorrigeerd (provinciegrens zag er erg slecht uit). Degene die oude gegevens van Delfzijl heeft mag de dijk van het Havenkanaal opnieuw intekenen, want die heeft AND blijkbaar niet. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] AND import almost completed, but...
Hi, I know the AND upload is basically complete but a few dozen objects still need to be uploaded, including a few bodies of water and administrative boundies. They didn't load the first time for various reasons (mostly people deleting dependant objects) and now I'm trying to fix them. Please people if you see a node or segment uploaded by AND that does not appear to be used *please* don't delete it!!! It may be used soon!! Thanks in advance, -- 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 import, voor zover mogelijk, klaar
Hoi, Jullie kunnen nu je slag slaan. Ik de grootste gedeelte van de nodes/segementen dat verwijdert waren gedurende de upload terug gezet, dus zit nu eindelijk bijna alle data in. Er zijn een aantal wegen dat ik niet de moeite voor ga doen om ze goed te maken. Ik denk dat ze in de buurt van de protected areas zijn, maar zeker weten doe ik het niet. API zal down zijn vanmiddag, om de quadtiles idee te implementeren. Dan zal hopelijk de rendering sneller gaan en kunnen wij NL goed op de kaart zetten in osmarender. Straten over zijn (nee, k weet verder niet waar ze zijn): Hoofdvaartsweg A270 (2 keer) Ruwe Putten Ter Warden Kerkakkers Smits van Oyenlaan Gerwenseweg Laar Broekdijk Geldropsedijk (2 keer) Eisenhowerlaan (2 keer) Wolvendijk Soeterbeekseweg Europalaan (2 keer) -- 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 import, voor zover mogelijk, klaar
Hoi, On 9/21/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: dus zit nu eindelijk bijna alle data in Fantastisch! Ik kon bijna niet wachten totdat ik aan de slag kon! Straten over zijn (nee, k weet verder niet waar ze zijn): Smits van Oyenlaan Gerwenseweg Laar Broekdijk Geldropsedijk (2 keer) Eisenhowerlaan (2 keer) Wolvendijk Europalaan (2 keer) Deze zijn (zo op het oog) allemaal op het grensgebied van Nuenen, dus Freek mag hier denk ik aan de slag... Nog een korte vraag: Ik heb op een aantal punten gezien dat de AND-data alleen een straat bevat, terwijl er ook een stukje 'straat' aan vast zit waaraan garageboxen liggen. Nu is de vraag: - Zijn dit soort 'zijweggetjes' interessant voor ons? - Als ik deze ga aanbrengen, dan moet ik het bestaande segment splitsen en een node invoegen, en dan een nieuwe node maken en een nieuw segment. Krijgen we dan problemen met de huisnummer-data? 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/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
On 9/21/07, Christ van Willegen [EMAIL PROTECTED] wrote: Nu is de vraag: - Zijn dit soort 'zijweggetjes' interessant voor ons? Ik denk het wel. Heel vaak hebben de garageboxen een huisnummer, en vallen dus onder een adres. Ook zijn er heel wat garageboxen verhuurd, waar zich kleinere bedrijfjes in hebben gevestigd. groeten, Danny ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
On 9/21/07, Christ van Willegen [EMAIL PROTECTED] wrote: Nu is de vraag: - Als ik deze ga aanbrengen, dan moet ik het bestaande segment splitsen en een node invoegen, en dan een nieuwe node maken en een nieuw segment. Krijgen we dan problemen met de huisnummer-data? Op zich, nee. Deze nodes aan de eindpunten hebben ook hun ID dus het is altijd wel terug te vinden. Het kan natuurlijk gebeuren dat wij misschien niet alle huisnummer data automatisch erin krijgen. Dan moet er wat met de hand gebeuren. Ik heb zelf helemaal niet naar de huisnummer data gekeken, dus ik weet niet hoe moeilijk dat zou zijn. 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 import, voor zover mogelijk, klaar
Aan Martijn en iedereen die heeft meegewerkt aan de monsterimport: bedankt! Echt een superactie. De eerste resultaten zien er prachtig uit. Op naar de volgende uitdaging :) Groet, Zoran Martijn van Oosterhout wrote: Hoi, Jullie kunnen nu je slag slaan. Ik de grootste gedeelte van de nodes/segementen dat verwijdert waren gedurende de upload terug gezet, dus zit nu eindelijk bijna alle data in. Er zijn een aantal wegen dat ik niet de moeite voor ga doen om ze goed te maken. Ik denk dat ze in de buurt van de protected areas zijn, maar zeker weten doe ik het niet. API zal down zijn vanmiddag, om de quadtiles idee te implementeren. Dan zal hopelijk de rendering sneller gaan en kunnen wij NL goed op de kaart zetten in osmarender. Straten over zijn (nee, k weet verder niet waar ze zijn): Hoofdvaartsweg A270 (2 keer) Ruwe Putten Ter Warden Kerkakkers Smits van Oyenlaan Gerwenseweg Laar Broekdijk Geldropsedijk (2 keer) Eisenhowerlaan (2 keer) Wolvendijk Soeterbeekseweg Europalaan (2 keer) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
Martijn van Oosterhout wrote: Hoi, Jullie kunnen nu je slag slaan. Ik de grootste gedeelte van de nodes/segementen dat verwijdert waren gedurende de upload terug gezet, dus zit nu eindelijk bijna alle data in. Allereerst: harstikke bedankt voor de import. Ik kan het nu niet controleren, maar eergisteren was er toch nog een groot probleem met de kustlijnen. Ik was naar de kust rond de Eemshaven aan het kijken en het viel me op dat de AND gemeentegrens samen lijkt te vallen (en dus dezelfde nodes gebruikt als) de kustlijn, maar toen ik de way van de gemeentegrens verwijderde was er volgens mij geen way voor de kustlijn. Het is ook op informationhighway te zien dat overal waar een tile kustlijn heeft, de tile ofwel volledig water ofwel volledig land is gerenderd. Nog maar even afwachten totdat de database weer online is. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
Wacht even, ik zat naar de verkeerde grenzen te kijken. Maar het zit toch fout. Ja, ik heb het net nog even kunnen controleren (wat is JOSM trag als je een klein beetje te veel inlaadt) en rond de Eemshaven worden de punten die de kust opmaken gebruikt voor (bijvoorbeeld): - AND_admin8=1458, name=Delfzijl - AND_admin1=1012, name=Groningen;GR - unwayed segments Dit zijn de gemeente- en provinciegrenzen en die vallen niet samen met de kustlijn. De werkelijke kust is opgemaakt uit - AND_admin0=1001, name=Nederland;NLD (en dat is een hele lange way, ik denk dat we die beter kunnen splitsten) - AND_admin0=1001, name=Nederland;NLD (ja, twee maal) - AND_o=1001, name=Nederland;NLD (ook een erg lange way) - AND_o=1001, name=Nederland;NLD (ten tweede male) - AND_o=1001, name=Nederland;NLD (ten derde male) - unwayed segments, dubbel, in twee richtingen Dus er is echt nog wel wat te doen. Waarom zijn ADN_admin0 en AND_o dubbel en driedubbel? Dat begrijk ik niet. Dat deze ways nu een grote way zijn (en ze lijken me echt helemaal rond te gaan, er wordt iig een hele grote area gedownload) maakt het wel makkelijk om ze in één klik te verwijderen of om te noemen naar coastline. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
On 9/21/07, Maarten Deen [EMAIL PROTECTED] wrote: De werkelijke kust is opgemaakt uit - AND_admin0=1001, name=Nederland;NLD (en dat is een hele lange way, ik denk dat we die beter kunnen splitsten) - AND_admin0=1001, name=Nederland;NLD (ja, twee maal) - AND_o=1001, name=Nederland;NLD (ook een erg lange way) - AND_o=1001, name=Nederland;NLD (ten tweede male) - AND_o=1001, name=Nederland;NLD (ten derde male) - unwayed segments, dubbel, in twee richtingen Nou de dubbele ways mogen weg. Het probleem lag aan het feit dat de uploader niet lang genoeg wachte voordat de server reageerde. Dat way uploaden duurde enkele minuten, en dacht ie dus dat het niet gedaan was. Later probeerde die het weer, dus... De unwayed sgments snap ik niet... Dat er segments in beide richting zijn is correct, daar hoeft niks aan gedaan te worden. (Anders ben je gelimiteert met welke kant de ways op gaan. Daar is in iedergeval nog werk ja Met vrienldeijke 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 import, voor zover mogelijk, klaar
On 9/21/07, Maarten Deen [EMAIL PROTECTED] wrote: Ik denk dat we dan even moeten coordineren wat we gaan doen zodat we niet teveel werk hoeven te doen. Is goed. Ik probeer nu even de kustlijn te laden zodat ik kan zien waar wij het over hebben. Ben je op IRC? Het voorstel om van een van de dubbele ways de kustlijn te maken, is dat een goede? De way omvat danwel heel Nederland, maar op de punten waar de Duitse en Belgische kust raken kan de way gesplitst worden en de rest kan weg. Kunnen daar problemen optreden? Nee, dat lijkt mij wel het juiste idee... Is het handig om ways van meer dan 10.000 segmenten te hebben? Niet echt, we moeten ze uiteindelijke splitsen zodat ze misschien maar 500 segmenten per stuk hebben... 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 import, voor zover mogelijk, klaar
On 9/21/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: Is goed. Ik probeer nu even de kustlijn te laden zodat ik kan zien waar wij het over hebben. Ok, gedaan. Ik stel voor om voor de buitengrens ways 7658297 , 7657914 gewoon te verwijderen. Way 7651990 moet opgesplitst worden. Dat stuk dat door de zee loopt, dat hebben wij niet nodig geloof ik. De rest maken wij gewoon natural=coastline and boundary=administrative. Klinkt dit 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] AND import, voor zover mogelijk, klaar
Martijn van Oosterhout wrote: On 9/21/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: Is goed. Ik probeer nu even de kustlijn te laden zodat ik kan zien waar wij het over hebben. Ok, gedaan. Ik stel voor om voor de buitengrens ways 7658297 , 7657914 gewoon te verwijderen. Way 7651990 moet opgesplitst worden. Dat stuk dat door de zee loopt, dat hebben wij niet nodig geloof ik. De rest maken wij gewoon natural=coastline and boundary=administrative. Klinkt dit goed? Lijkt me goed. Ik zit nu trouwens op IRC, alleen is het de eerste keer dat ik het gebruik (jemig, ik klink als een ouwe opa). Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
Martijn van Oosterhout wrote: On 9/21/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: Is goed. Ik probeer nu even de kustlijn te laden zodat ik kan zien waar wij het over hebben. Ok, gedaan. Ik stel voor om voor de buitengrens ways 7658297 , 7657914 gewoon te verwijderen. Way 7651990 moet opgesplitst worden. OK, op verzoek van Martijn dan: die 7658297 en 7657914 zijn nu weg. Volgende stap wordt dat opdelen. Maar dan moet ik eerst even het beginpunt van die weg vinden. Martijn? Enig idee waar ik die het beste kan zoeken ongeveer? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
On 9/21/07, Maarten Deen [EMAIL PROTECTED] wrote: Lijkt me goed. Ik zit nu trouwens op IRC, alleen is het de eerste keer dat ik het gebruik (jemig, ik klink als een ouwe opa). Wij zitten het op #osm.nl te coordineren, op dezelvde server als #osm. Dit splitsen wordt lastig 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 import, voor zover mogelijk, klaar
Martijn van Oosterhout wrote: On 9/21/07, Maarten Deen [EMAIL PROTECTED] wrote: Lijkt me goed. Ik zit nu trouwens op IRC, alleen is het de eerste keer dat ik het gebruik (jemig, ik klink als een ouwe opa). Wij zitten het op #osm.nl te coordineren, op dezelvde server als #osm. Maar dan op #osm-nl :-) anders verdwalen de mensen weer zo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
Mark Huizer wrote: Martijn van Oosterhout wrote: On 9/21/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: Is goed. Ik probeer nu even de kustlijn te laden zodat ik kan zien waar wij het over hebben. Ok, gedaan. Ik stel voor om voor de buitengrens ways 7658297 , 7657914 gewoon te verwijderen. Way 7651990 moet opgesplitst worden. OK, op verzoek van Martijn dan: die 7658297 en 7657914 zijn nu weg. Volgende stap wordt dat opdelen. Maar dan moet ik eerst even het beginpunt van die weg vinden. Martijn? Enig idee waar ik die het beste kan zoeken ongeveer? Inmiddels is 7658685 voorzien van een boundary=national, en opgesplitst in 44 wegen van ca 500 segmenten, tijd voor de coastline. Hopelijk zijn de renderers daarna gelukkiger. En oh ja, JOSM wordt niet vrolijk van wegen van 22000 segmenten Mark ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import, voor zover mogelijk, klaar
En ook de coastline (7651990) is nu opgesplitst in 53 losse wegen van ca. 500 segmenten. Enige voorzichtigheid daarbij, aangezien ik daar een aantal warnings over unordered ways kreeg. Maar aangezien we daar ook dingen met dubbele segmenten moeten oplossen heb ik die even geignored. En om de discussie gaande te houden :-)... Volgens mij is 7763946 nu een overbodig gedeelte van de coastline geworden, tenminste 90% van die way, bij zeeland en groningen zal er even zorgvuldig geknipt moeten worden. Of vergis ik me nu en heeft dat stuk nog nut? Anyway, morgen kijk ik wel weer verder. Kijken of het renderen nu beter gaat Mark ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] AND import nearly complete
As the astute people will have noticed the AND import is nearly done. What is going to happen is that it's going to hit around 99.99% (it may round up) and it's going to go back and check the file again to upload all the ones that failed the first time around. This is going to take some time (probably several hours). However, only about 1400 objects failed or got skipped so for all intents and purposes the upload is complete when it hits 99.99%. [EMAIL PROTECTED] is backlogged right now so rerendering NL is not going to go very quickly. Mapnik has whatever was there when the planet dump finished. For some areas that's not much, for other areas it's amazing. But when [EMAIL PROTECTED] does render something it looks *awesome*: http://www.openstreetmap.org/?lat=52.66081471390682lon=4.810981585342551zoom=12layers=0BF 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
Re: [OSM-talk-nl] AND import
On 9/19/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote: On 9/19/07, Danny Maas [EMAIL PROTECTED] wrote: Ziet er uit alsof het de borden met afslag hoorn betreft. gewoon gewerken als AND klaar is met importeren lijkt mij. Nou, wij willen wel de points als motorway_junction behouden, ze zijn er voor en reden. Lijkt mij beter dat de renderer ze minder laat opvallen. Bijvoorbeeld in amstelveen zie je ze op zoom-12 al: http://www.informationfreeway.org/?lat=52.2910303538lon=4.85317062817106zoom=12layers=B000F000 Misschien de renderer ze kleiner maken is beter. Ook goed. Maar het zijn niet de enige foutjes die er in zitten. Zo zie ik dat mijn eigen woonwijk in Assendelft nog steeds op woonwijk in aanbouw staat. Die is al sinds 2001 klaar, en ook kloppen er een aantal straten niet qua ligging e.d. Ook zitten er plekken in die parkeerplaatsen en benzinestations op elkaar plaatsen, en meer van dat soort dingetjes. Er is dus nog genoeg te doen qua nalopen en up-to-date maken van de data, die dus (in mijn geval) meer dan 6 jaar oud is. Dat beantwoord weer een gedeelte van het vraagstukje en wat nu?. Maar eerst wil ik graag een melding zien van Import Completed!. Groeten, Danny ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] AND import
op irc merkte latexx vreemde gele bolletjes op in Hoorn (NL) http://www.informationfreeway.org/?lat=52.64822301674405lon=5.037577822421491zoom=15layers=B000F000 dit is een motorway_junction van de AND import, deze heeft een name tag = hoorn misschien eens nakijken wat we hiermee doen ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import
On 9/19/07, Danny Maas [EMAIL PROTECTED] wrote: Ziet er uit alsof het de borden met afslag hoorn betreft. gewoon gewerken als AND klaar is met importeren lijkt mij. Nou, wij willen wel de points als motorway_junction behouden, ze zijn er voor en reden. Lijkt mij beter dat de renderer ze minder laat opvallen. Bijvoorbeeld in amstelveen zie je ze op zoom-12 al: http://www.informationfreeway.org/?lat=52.2910303538lon=4.85317062817106zoom=12layers=B000F000 Misschien de renderer ze kleiner maken is beter. -- 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 import en de zeegrenzen
On Friday 14 September 2007, Remco van Zuijlen wrote: On Fri, Sep 14, 2007 at 09:31:11PM +0200, Maarten Deen wrote: Maar nu had ik dus ook een gedeelte van Groningen met de kust, en het valt me op dat de kustlijn overal opgebouwd is uit twee segmenten tussen twee nodes. En de segmenten wijzen allebei de andere kant uit. Dit was bij alle segmenten van de kustlijn die ik gedownload had, toch wel bijna van Noordpolderzijl tot de Eemshaven. ik zie het in mijn woonplaats Bussum ook. En dat is dus niet alleen bij kustlijnen, ook bij bv. stukjes hei, of de gemeentegrens tussen Naarden en Bussum. Nahja, hebben we wat te doen als alles erin staat. Dit gebeurd iig bij gemeentegrenzen: de grenzen van alle gemeenten lopen dezelfde kant op, dus op de grens zelf lopen twee ways tegen elkaar in. Dit is dus niet iets dat gerepareerd moet worden, het is goed zo (m.i.). -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import en de zeegrenzen
On Friday 14 September 2007 22:33:47 Remco van Zuijlen wrote: On Fri, Sep 14, 2007 at 09:31:11PM +0200, Maarten Deen wrote: Ik zat nog even naar Borkum te kijken en vooral waarom daar een tile niet goed als zee wordt gerenderd. Dus ik download een wat groter gedeelte en zie Nederland verschijnen en realiseer me dat het waarschijnlijk vanwege de AND import komt. Hoewel, daar zijn nog geen ways... Maar nu had ik dus ook een gedeelte van Groningen met de kust, en het valt me op dat de kustlijn overal opgebouwd is uit twee segmenten tussen twee nodes. En de segmenten wijzen allebei de andere kant uit. Er is een kustlijn beschikbaar: http://people.vrijschrift.org/~ante/osm/ 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 import en de zeegrenzen
On 9/14/07, Maarten Deen [EMAIL PROTECTED] wrote: Maar nu had ik dus ook een gedeelte van Groningen met de kust, en het valt me op dat de kustlijn overal opgebouwd is uit twee segmenten tussen twee nodes. En de segmenten wijzen allebei de andere kant uit. Dit was bij alle segmenten van de kustlijn die ik gedownload had, toch wel bijna van Noordpolderzijl tot de Eemshaven. Het klopt wel, want het is aan de ene kant de landgrens en aan de andere kant de kustlijn. Het zal wel redelijk vaak gebeuren en hoeft niet gecorregeerd te worden (over enkele maanden bestaan segmenten helemaal niet meer, dus is het probleem helemaal opgelost). 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 import en de zeegrenzen
On Fri, Sep 14, 2007 at 09:31:11PM +0200, Maarten Deen wrote: Ik zat nog even naar Borkum te kijken en vooral waarom daar een tile niet goed als zee wordt gerenderd. Dus ik download een wat groter gedeelte en zie Nederland verschijnen en realiseer me dat het waarschijnlijk vanwege de AND import komt. Hoewel, daar zijn nog geen ways... Maar nu had ik dus ook een gedeelte van Groningen met de kust, en het valt me op dat de kustlijn overal opgebouwd is uit twee segmenten tussen twee nodes. En de segmenten wijzen allebei de andere kant uit. Dit was bij alle segmenten van de kustlijn die ik gedownload had, toch wel bijna van Noordpolderzijl tot de Eemshaven. ik zie het in mijn woonplaats Bussum ook. En dat is dus niet alleen bij kustlijnen, ook bij bv. stukjes hei, of de gemeentegrens tussen Naarden en Bussum. Nahja, hebben we wat te doen als alles erin staat. ik zag net ineens ook dat alle segmenten in Bussum aangemaakt zijn tussen de nodes, een uurtje terug ofzo waren alleen de nodes nog zichtbaar in JOSM. Waarbij me ook opviel dat bepaalde eenrichtingsstraten de pijlen de verkeerde kant op staan, maar ik kan me nu ook herinneren dat die dan bij de way de tag oneway=-1 krijgen, dus ik wacht die ook even af. Remco Ik ben benieuwd hoe dat er straks uit komt te zien. Maarten -- Remco van Zuijlen [EMAIL PROTECTED] ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import progressie
On 9/7/07, Gerco-Kees Bloemsma [EMAIL PROTECTED] wrote: Wow, 9 dagen uploaden, dat is nog eens wat anders.. Ik zou haast denken dat een cd-tje sturen per post nog sneller gaat, maar dat zal wel niet gaan, technisch (niet verkeerd opvatten hoor, ik kan me goed voorstellen dat dit nu een keer de meest efficiente methode is, het gaat natuurlijk ook niet alleen om uploaden van informatie, maar vooral om het mergen met de database) Het AND data zit in dezelvde ruimte als de database. Het moet wel door twee servers (www en db2) voordat het bij de database komt. Het helpt ook niet dat de TIGER import nu ook bezig is. Misschien komt er ooit een snellere manier maar voor ons is dit wel snel genoeg geloof ik. Met vriendleijke 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 import progressie
Het is wel een goed idee om onze landelijke fietsroutes ook aan te geven op de een of andere manier. Lijkt mij persoonlijk hardstikke handig. Maar dat zal dan wel eerst uitgezocht moeten worden wat dat voor het copyright enzo betekend.. Weet iemand of we zomaar die LF-routes op kunnen nemen? http://www.fietsplatform.nl/routes/routes.asp Er rust geen copyright op LF-routes, want de route kan niet worden gecopieerd :-) Het lijkt mij onwaarschijnlijk dat de merkaam gedeponeerd is. Bovendien zijn ze bewegwijzerd hetgeen de weg vrijmaakt om ze op te nemen in een kaart. Naast de fietsroutes is er nog het fietsknooppuntennetwerk http://www.fietsen123.eu/index.php?option=com_contenttask=viewid=30. Ontwikkeld door een Belgische mijnbouwingenieur (in mijnstelsels gebruikten ze een vergelijkbaar systeem) Inmiddels is deze manier van bewegwijzeren in grote delen van nederland en duitsland geintroduceerd. Leuk om op te nemen, lijkt mij. Groeten, Renier ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND import informatie
On Fri, 7 Sep 2007, Zoran Kovacevic wrote: http://dev.openstreetmap.org/~kleptog/and.txt lol Linkje naar Postkrediet er bij? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] AND import informatie
Ik heb wat paginas gemaakt voor meer directe informatie: http://dev.openstreetmap.org/~kleptog/and-progress.png http://dev.openstreetmap.org/~kleptog/and.txt De eerste is een image, de tweede is gewoon tekst. Dus kan iedereen zelf kijken als ze willen weten hoe lang nog. Het is ook te zien op: http://www.openstreetmap.nl/archives/34-AND-data-import-is-gestart.html 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-import: Wat doen we met reeds ingevoerde data?
Floris Looijesteijn wrote: is dat even toeval :D Nou inderdaad! Dus vraag beantwoord :) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
Laten we het eerst even op wegen houden, POI kan later nog wel... Even een paar losse flodders: Iemand had opgemerkt dat we misschien niets moesten importeren binnen een straal van x00 meter rondom bestaande data. Dat is een goed idee maar betekend veel handwerk. Het lijkt erop dat AND data echt alleen met de auto toegankelijke wegen bevat. Elk fietspaadje of voetgangersgebied 'mist'. Maar daarvan hebben we er natuurlijk al veel in OSM. Is het een optie om alles te importeren en daarna dubbele wegen met de hand weg te halen? Het gaat nooit precies over elkaar heen liggen dus dit moet in JOSM vrij goed te doen zijn. Iemand goede ideeen? floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] AND-import: Welke tags overnemen/negeren/toevoegen aan OSM?
Er zijn twee losse datasets, een de POI (met ook tankstations bijvoorbeeld) en de wegen. Belangrijkste is in eerste instantie de wegendb. Veel discussie is al op de wiki gezet, oa hier: http://wiki.openstreetmap.org/index.php/AND_Data/AND-tag-mapping-to-OSM Laat uw licht er eens over schijnen :) Ik denk dat we op een gegeven moment misschien gewoon moeten importeren en later kunnen we altijd nog dingen toevoegen via de AND-id's die voorlopig ook nog opgeslagen worden. groet, floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
Floris Looijesteijn wrote: Laten we het eerst even op wegen houden, POI kan later nog wel... Even een paar losse flodders: Iemand had opgemerkt dat we misschien niets moesten importeren binnen een straal van x00 meter rondom bestaande data. voor Losser (net begonnen) zou ik zeggen: importeer alles maar, dan kijk ik er wel naar. Data van AND is wrs vergeijkbaar beter dan van mezelf, Voor Assen kan ik me voorstellen dat je dat jij niet wilt. je hebt het over 100den meters, misschien is tientallen meters een idee? Je hebt vast geen gemeente data of zo er in zitten?, zodat je kan differentieren per gemeente? Groets, Ikke ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
Floris Looijesteijn schreef: Iemand had opgemerkt dat we misschien niets moesten importeren binnen een straal van x00 meter rondom bestaande data. Dat is een goed idee maar betekend veel handwerk. Dat was ik. Een voordeel is dat we dan snel een groot deel van de data gewoon kunnen importeren. We moeten (volgens mij) sowieso de overlappende data anders behandelen dan de data in lege gebieden (zie onder), en misschien moeten we wachten op een volgende JOSM-versie. Is het een optie om alles te importeren en daarna dubbele wegen met de hand weg te halen? Het gaat nooit precies over elkaar heen liggen dus dit moet in JOSM vrij goed te doen zijn. Dan krijg je dus in de renderers dubbele segmenten; en dat kan best lang duren, want we moeten een heleboel met de hand bijwerken. En in JOSM zelf zijn dubbele wegen niet heel goed te onderscheiden van wegen met gescheiden rijbanen, of een weg met een fietspad ernaast. Ik zie daar twee oplossingen voor: A) Importeer (alleen in het overlappende gebied) de AND-data als segmenten; dan kan je ze in JOSM duidelijk onderscheiden en worden ze ook niet gerenderd. OF B) Wacht tot JOSM meerdere data-layers kan gebruiken; upload de AND-data niet, maar stel ze ter beschikking (in stukjes) als .osm files, en laat de merge handmatig uitvoeren door vrijwilligers (door ons allemaal, dus). Methode B) is eleganter, en misschien makkelijker uitvoerbaar; maar je bent wel afhankelijk van de JOSM-programmeurs. (Ik heb ergens gelezen dat ze bezig zijn met die meerdere data-layers erin te programmeren, maar ik kan dat nu zo snel niet vinden.) Eugene ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
Ik ben geen programmeur, maar dit lijkt mij het meest logische: Wegen met dezelfde richting (enkele vrijheidsgraden inbouwen) en binnen een bepaalde straal niet importeren of met een speciale tag importeren, zodat ze makkelijk terug te vinden zijn. De fiets- en voetpaden moeten niet vergeleken worden met de AND data lijkt mij. Met sportieve groet, Foppe Benedictus Floris Looijesteijn schreef: Laten we het eerst even op wegen houden, POI kan later nog wel... Even een paar losse flodders: Iemand had opgemerkt dat we misschien niets moesten importeren binnen een straal van x00 meter rondom bestaande data. Dat is een goed idee maar betekend veel handwerk. Het lijkt erop dat AND data echt alleen met de auto toegankelijke wegen bevat. Elk fietspaadje of voetgangersgebied 'mist'. Maar daarvan hebben we er natuurlijk al veel in OSM. Is het een optie om alles te importeren en daarna dubbele wegen met de hand weg te halen? Het gaat nooit precies over elkaar heen liggen dus dit moet in JOSM vrij goed te doen zijn. Iemand goede ideeen? floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
Eugene van der Pijll wrote: Floris Looijesteijn schreef: Iemand had opgemerkt dat we misschien niets moesten importeren binnen een straal van x00 meter rondom bestaande data. Dat is een goed idee maar betekend veel handwerk. Dat was ik. Een voordeel is dat we dan snel een groot deel van de data gewoon kunnen importeren. We moeten (volgens mij) sowieso de overlappende data anders behandelen dan de data in lege gebieden (zie onder), en misschien moeten we wachten op een volgende JOSM-versie. Is het een optie om alles te importeren en daarna dubbele wegen met de hand weg te halen? Het gaat nooit precies over elkaar heen liggen dus dit moet in JOSM vrij goed te doen zijn. Dan krijg je dus in de renderers dubbele segmenten; en dat kan best lang duren, want we moeten een heleboel met de hand bijwerken. En in JOSM zelf zijn dubbele wegen niet heel goed te onderscheiden van wegen met gescheiden rijbanen, of een weg met een fietspad ernaast. Ik zie daar twee oplossingen voor: A) Importeer (alleen in het overlappende gebied) de AND-data als segmenten; dan kan je ze in JOSM duidelijk onderscheiden en worden ze ook niet gerenderd. OF B) Wacht tot JOSM meerdere data-layers kan gebruiken; upload de AND-data niet, maar stel ze ter beschikking (in stukjes) als .osm files, en laat de merge handmatig uitvoeren door vrijwilligers (door ons allemaal, dus). hmmm kan je de een niet als wms-layer tonen, net als die landsat beelden? Dat zou je eigenlijk met beide willen doen: Als wat we in osm hebben al vrij uitgebreid is, wil je daar aanpassingen doen op basis van de AND data, als er nog weinig in OSM zit, wil je juist wat je hebt overbrengen op de AND data. In combinatie met 'kleine' osm bestanden, lijkt me dit een mooie optie. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
Foppe Benedictus schreef: Ik ben geen programmeur, maar dit lijkt mij het meest logische: Wegen met dezelfde richting (enkele vrijheidsgraden inbouwen) en binnen een bepaalde straal niet importeren of met een speciale tag importeren, zodat ze makkelijk terug te vinden zijn. Dat is makkelijker gezegd dan gedaan... Neem bijvoorbeeld parallelwegen; als wij zo'n weg nog niet hebben, en AND wel, zal hij er toch uitgefilterd worden omdat hij zo dicht bij de hoofdweg ligt. Hetzelfde geldt voor wegen met gescheiden rijbanen. En rotondes: als wij die met 4 nodes hebben, maar AND heeft daar 8 nodes, dan komen minstens 4 segmenten qua richting niet overen met die van ons. Hetzelfde geldt voor (scherpe) bochten. Het kan allemaal wel, maar als je daar allemaal rekening mee moet houden, dan gaat het programmeren nog wel eventjes duren. De fiets- en voetpaden moeten niet vergeleken worden met de AND data lijkt mij. Mee eens. Eugene ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
On Mon, July 16, 2007 1:42 pm, Milo van der Linden wrote: hmmm kan je de een niet als wms-layer tonen, net als die landsat beelden? Dat zou je eigenlijk met beide willen doen: Als wat we in osm hebben al vrij uitgebreid is, wil je daar aanpassingen doen op basis van de AND data, als er nog weinig in OSM zit, wil je juist wat je hebt overbrengen op de AND data. In combinatie met 'kleine' osm bestanden, lijkt me dit een mooie optie. Kleine osm bestanden leveren veel afstemmings en vastknopen problemen op. Hoe groter de gebieden vanuit 1 bron, hoe efficienter, maar dus ook wel weer hoe grover wat keuze van bron betreft. Omdat in een stad alles verknoopt is, kunnen steden mogelijk het beste uit 1 bron komen. Ik zou best een stad waar we veel aan gewerkt hebben, zoals Amsterdam of Den Haag willen kunnen vergelijken, AND en OSM. 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-import: Wat doen we met reeds ingevoerde data?
Kan de data naar een .osm file geexporteerd worden? Als je die in (geografische) stukken hakt kun je ze in JOSM laden, data van de server erbij en dan combineren. Maarten -Original Message- From: Floris Looijesteijn [EMAIL PROTECTED] To: talk-nl@openstreetmap.org Sent: 16-07-07 12:20 Subject: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data? [knip] Is het een optie om alles te importeren en daarna dubbele wegen met de hand weg te halen? Het gaat nooit precies over elkaar heen liggen dus dit moet in JOSM vrij goed te doen zijn. Iemand goede ideeen? floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
Ik snap niet wat jullie met een binary compare bedoelen in deze
situatie. Kan iemand dat even toelichten?
Er is nog wel een ander belangrijk punt: De data die in de AND
db zit lijkt van hoge kwaliteit te zijn. Beter bijvoorbeeld dan
de data op Google maps. Als ik de straatdata van Googlemaps
vergelijk met de satelliet foto's van Google en dan daarnaast
de AND import leg zie ik bijvoorbeeld fietspaadjes die in Google
maps gewoon doorgetrokken zijn als weg maar in de AND
data op de juiste plek onderbroken zijn.
floris
- Original Message -
From: Berend Dekens [EMAIL PROTECTED]
To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org
Sent: Monday, July 16, 2007 4:09 PM
Subject: Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde
data?
Kunnen we niet de 50 meter regel en een binary compare combineren?
Als het gebied leeg is, importeren we alle wegen waarbij we markeren dat
de wegen uit de AND dataset komen. Zodra we in gemapped gebied komen,
knippen we die wegen er uit en houden de uitgeknipte wegen apart (dus
wat niet in de OSM server gaat, gaat in een apart bestand met de rest).
Wat mij betreft verknip je die bestanden in sectoren en prak je die
online op de OSM site. Als we dan met de hand de wegen gaan aansluiten
kunnen we ook zien hoe de AND kaart in dat gebied er uit zag en zo de
merge bepalen uit beide datasets.
Door tevens elk 'afgeknipte' weg te taggen ('ANDpartial=true
bijvoorbeeld) kunnen we zelfs statistieken bijhouden hoeveel wegen nog
moeten worden vastgemaakt aan de oude data.
Berend
Floris Looijesteijn wrote:
Laten we het eerst even op wegen houden, POI kan later
nog wel...
Even een paar losse flodders:
Iemand had opgemerkt dat we misschien niets moesten importeren
binnen een straal van x00 meter rondom bestaande data.
Dat is een goed idee maar betekend veel handwerk.
Het lijkt erop dat AND data echt alleen met de auto toegankelijke
wegen bevat. Elk fietspaadje of voetgangersgebied 'mist'. Maar
daarvan hebben we er natuurlijk al veel in OSM.
Is het een optie om alles te importeren en daarna dubbele wegen met
de hand weg te halen? Het gaat nooit precies over elkaar heen liggen
dus dit moet in JOSM vrij goed te doen zijn.
Iemand goede ideeen?
floris
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
De term is hier ook niet helemaal correct maar in principe test je of een straat/node/whatever op veilige afstand zit en dan prak je em in OSM, zoniet dan laat je hem er uit. Ik bedacht me net dat dit zwart-wit scenario bijvoorbeeld lange straten richting gemapped gebied ook weg zou laten... Het is dan beter om de way op een node af te snijden zodra the dicht bij komt - dan krijg je dus een grijs segment van ways die buiten het gemappede gebied beginnen en daarna te dicht bij de rest komen. Dergelijke straten moeten dan worden geknipt op de zoveel meter grens. Berend Floris Looijesteijn wrote: Ik snap niet wat jullie met een binary compare bedoelen in deze situatie. Kan iemand dat even toelichten? Er is nog wel een ander belangrijk punt: De data die in de AND db zit lijkt van hoge kwaliteit te zijn. Beter bijvoorbeeld dan de data op Google maps. Als ik de straatdata van Googlemaps vergelijk met de satelliet foto's van Google en dan daarnaast de AND import leg zie ik bijvoorbeeld fietspaadjes die in Google maps gewoon doorgetrokken zijn als weg maar in de AND data op de juiste plek onderbroken zijn. floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
On Mon, July 16, 2007 7:50 pm, Floris Looijesteijn wrote: Ik snap niet wat jullie met een binary compare bedoelen in deze situatie. Kan iemand dat even toelichten? Er is nog wel een ander belangrijk punt: De data die in de AND db zit lijkt van hoge kwaliteit te zijn. Beter bijvoorbeeld dan de data op Google maps. Als ik de straatdata van Googlemaps vergelijk met de satelliet foto's van Google en dan daarnaast de AND import leg zie ik bijvoorbeeld fietspaadjes die in Google maps gewoon doorgetrokken zijn als weg maar in de AND data op de juiste plek onderbroken zijn. Als het om consistentie en efficientie gaat zou het kunnen zijn dat - osm opslaan - vervangen door AND - fietspaden en voetpaden uit osm toevoegen - osm als achtergrond ter vergelijking een pijnlijke maar goede oplossing is. 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-import: Wat doen we met reeds ingevoerde data?
Floris Looijesteijn wrote: Ik snap niet wat jullie met een binary compare bedoelen in deze situatie. Kan iemand dat even toelichten? Er is nog wel een ander belangrijk punt: De data die in de AND db zit lijkt van hoge kwaliteit te zijn. Beter bijvoorbeeld dan de data op Google maps. Ja maar wij hebben zelf data verzameld en die is veel beter, dus om die zomaar te vervangen... ;-) Groets, Jaap-Andre ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] AND-import: Wat doen we met reeds ingevoerde data?
- Original Message - From: Jaap-Andre de Hoop [EMAIL PROTECTED] Floris Looijesteijn wrote: Ik snap niet wat jullie met een binary compare bedoelen in deze situatie. Kan iemand dat even toelichten? Er is nog wel een ander belangrijk punt: De data die in de AND db zit lijkt van hoge kwaliteit te zijn. Beter bijvoorbeeld dan de data op Google maps. Ja maar wij hebben zelf data verzameld en die is veel beter, dus om die zomaar te vervangen... ;-) dat was eigenlijk inderdaad het punt wat ik dus niet zeker weet. AND heeft z'n data waarschijnlijk verkregen door langmetingen, dus die zullen in principe wel nauwkeuriger zijn. floris Groets, Jaap-Andre ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
