Re: [OSM-talk-nl] 3dshapes and AND user and ODbL
> In het verlengde hiervan, is er interesse in een kaart die laat zien > wat er overblijft zonder 3Dshapes (en afgeleide en dus tainted data)? > Ik zou dat wel willen zien en ik heb het idee dat het niet zo heel > moeilijk te maken is? Ik had een tijdje geleden zo'n kaart gemaakt, en zal vanavond eens kijken of hier nog leven in zit. http://mijndev.openstreetmap.nl/~ldp/users-agreed/ Dit is echter een zeer simplistische benadering, en kijkt totaal niet naar de history van objecten, maar alleen naar de laatste user. Bij-effect is wel dat 3dShapes en AND er niet in voorkomen. Daarnaast is er ook nog een overlay gemaakt door iemand anders, die wel naar de history kijkt, en lijntjes groen/geel/rood maakt, om de ODbL-compliance weer te geven. Dit was echter weer een eenmalige import, dus wordt niet dynamisch bijgewerkt. URL heb ik niet paraat. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenWandelKaart
> > Lennard .... Ldp ... What's in the name. > Als het Knipperen maar werkt. ;) Zolang het maar niet zo'n relatie wordt ... :) We moeten binnenkort dan eens kijken wat voor ideeën je hebt, en of ze realiseerbaar zijn binnen mapnik. Ik ben wel hoofdzakelijk een IRC-gebruiker, zeker om snel te brainstormen, maar je mag natuurlijk altijd en alvast een lijstje mailen met je punten. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] NL tileserver updates
> Als je nu een fatsoenlijke distributie pakt waarbij je niet alles zelf > hoeft te compileren, we leven tenslotte niet meer in 1990... :p Gelukkig compileren we zelf, zodat we makkelijker en sneller bij kunnen blijven, zonder van derden en hun RPM'etjes afhankelijk te zijn. :p -- Lennardd ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Maxspeed overlay voor Nederland?
> Helaas weet ik niet dat er een NL variant is maar zou het erg > interessant vinden omdat zo'n overlay het makkelijker maakt de data > compleet te krijgen. Binnenkort zullen we deze, als het aan mij ligt, wel hebben. Ik zou deze graag op de nieuwe server plaatsen. @Skinkie: dit was dus mijn projectje waar ik het een tijdje geleden op irc over had. :) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wandelroutes op tile.openstreetmap.nl
Ben Laenen wrote: > wel, ik was alleszins niet degene die het upstream heeft gebracht. Ik > heb de code naar een paar mensen gestuurd, maar weet niet wie de > schuldige is. Niet dat ik het erg vind hoor, maar 'k had het liever wat > opgekuist eerst :-) Als opencyclemap.org dit stuk niet gebruikt, kunnen we dan wellicht iets beters maken, en er een zaak van maken binnen de OSM-gemeenschap? Of het huidige blijven ondersteunen, maar ook nieuwe functionaliteit toevoegen. > De opencyclemap werkt anders, die gebruikt een paar extra sql queries > onafhankelijk van osm2psql die na het invoeren uitgevoerd worden. Inside info, of is dit ook ergens gedocumenteerd? Zo heb ik me bijvoorbeeld afgevraagd waar hij zijn oneway-informatie vandaan haalt. >> Taggen voor de renderer? :-) > taggen in welke kleur de markeringen of bordjes zijn is toch niet taggen > voor de renderer? Nee, vandaar de smiley. > Ja, de route_pref_color is wat van die rommel van mij die er beter eerst > uit gegaan was. Voor mijn rendering had het zijn nut nochtans. Maar ik > veronderstel dat niemand weet waar het voor dient :-) Ik had hem wel door. Met niet al te complex samenhangende routes zijn 4 kleuren genoeg om te zorgen dat rakende netwerken verschillende kleuren hebben. > Kort samengevat: een lokale fietsroute kreeg een extra nummer mee. Elk > nummer kreeg dan een eigen kleur op de kaart (en de kleuren worden > gekozen door degene die de kaarten rendert zodat ze inpassen in de > andere kleuren op de kaart). Als lokale routes dus overlappen kon je zo > het onderscheid maken. Juist, mijn vermoeden bevestigd. > Dat valt trouwens wel meer onder taggen voor de renderer... Maar er is > niet veel anders mogelijk omdat je verkortingen bijvoorbeeld ook > dezelde kleur wil houden dan de hoofdroute. En zoals het nu is, is er geen verband tussen de hoofdroute en de verkorting(en). Het zijn verschillende relaties. Uiteindelijk zul je of iets heel slims in tagging moeten verzinnen, of enkele trucs toepassen. > Ja, hier rond Antwerpen hebben de meeste lokale fietsroutes die tag, om > logische redenen :-) Ik zeg: dat is geen afspiegeling van de rest van de osm-dekking. :-) >> dat dan op een uniforme en te behappen manier, zodat je niet een >> explosie aan rendering rules nodig hebt. > Dat laatste is bij mijn weten niet mogelijk met mapnik, maar prove me > wrong :-) Cascadenik, of custom python rendering, zouden het wat meer te behappen moeten maken. Denk ik, want ik heb het niet geprobeerd. Uiteindelijk is het aantal rules dat mapnik gebruikt dan net zo groot, alleen is het dynamisch opgebouwd. Er is nu ook een mapnik trac ticket om een asymmetrische offset aan een LineSymbolizer te geven. Ik denk dat het hiermee beter mogelijk wordt om verschillende routes over dezelfde weg te visualiseren. En zo zijn er wel meer ontwikkelverzoeken binnen mapnik, die handig kunnen zijn voor dit soort kaarten. Uiteindelijk zou ik ook graag zien dat mapnik iets meer intelligente of scripted beslissingen zou kunnen nemen, gegeven een aantal tags. Dat zal het aantal benodigde renderregels flink kunnen verminderen, in zulke complexe taggingen als we nu hebben. Het zal niet van morgen zijn, maar wie weet in 1.0.0. > Maar je komt wel al ver als je gewoon de basiskleuren hebt (blue, green, > yellow, brown, red, orange, black, purple), en wat betreft combinaties, > er zijn ook maar een paar die voorkomen > als "white-red", "yellow-red". 't Zijn redelijk veel regels, maar > voorlopig is er niks beters. Vergeet alleen geen regel in de stylesheet > om naar een default kleur te gaan als je de kleur niet herkent... Heb je wellicht de mogelijke waarden voor een route_color tag gedocumenteerd op de wiki? Indien niet, is er iets op te zetten? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wandelroutes op tile.openstreetmap.nl
Ben Laenen wrote: > Ja, dankzij het feit dat iemand mijn snel-snel ineengeklutste code om > die fietsroutes te behandelen heeft doorgespeeld naar de code van de > internationale osm2pgsql :-p . En vooruitziende mens dat ik was had ik > meteen ook de wandelroutes erbij gezet... En ik dacht dat er ook nog > wel wat meer rommel zo in osm2pgsql is terecht gekomen :-D Aha! De schuldige! :-) Inderdaad, extra/andere functionaliteit in osm2pgsql hangen is niet zo moeilijk, zolang we het huidige maar niet slopen. Immers, wij zijn vast niet de enigen die hiervan gebruik maken; zie ook de opencyclemap. > aanpassen om bijvoorbeeld een "colour" tag te lezen. En het lezen van > een colour tag is de grootste truuk om de routes leesbaar te maken op > de kaart. Taggen voor de renderer? :-) Er zit nu wat colour handling in osm2pgsql: De tag 'preferred_color' wordt nu gelezen, gekeken of deze in de range [1-4] valt, en dan in pg weggeschreven als route_pref_color. Indien buiten de range, of niet aanwezig, dan wordt het een 0. Ik vraag me af of er veel routes voorzien zijn van 'preferred_color=[1-4]'. En tevens of dit wel afdoende is. Met 4 mogelijke kleuren moet je als mapper zelf een kleur kiezen die op de snijdende/rakende routes niet voorkomt, en de kleur hoeft niet de werkelijke routekleur te zijn. Een renderen moet immers zelf 4 unieke kleuren aan de codes 1-4 hangen. Ik zou het wel mooi vinden om bij de routes die 'op de weg' voorzien zijn van een duidelijke kleurstelling (bv. wit/rood, geel/rood, geel/blauw, of een enkele kleur), deze ook op de kaart te krijgen. En dat dan op een uniforme en te behappen manier, zodat je niet een explosie aan rendering rules nodig hebt. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] bounderies
Eugene van der Pijll wrote: > Lambert Carsten schreef: >> Ik kwam een raar verloop tegen van de gemeente grens in Amsterdam: >> >> http://www.openstreetmap.org/?lat=52.33308&lon=4.92431&zoom=16 > > Wat is daar vreemd aan? Juist. Wat is de definitie van raar? Heb je de grenzen in Baarle-Nassau/Baarle-Hertog al eens bekeken, Lambert? Heb jij dan kennis van een echte grenscorrectie in dat gebied, die nu niet op de kaart staat? In dat geval zou je correct handelen door hem te corrigeren, maar anders kan de huidige 'rare' grens net zo goed de juiste zijn. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Crossing roads
peter welten wrote: > Alleen met zwaailicht en sirene. Maar voetgangers mogen het ook zonder > zwaailicht en sirene. Nee, en een terugkerend misverstand. Politie*ambtenaren* (dus niet de dienstvoertuigen zelf) hebben een ontheffing van het hele RVV1990. Ook te voet, te fiets, te paard, of in hun privevoertuig. Zolang het maar voor de uitvoering van hun dienst noodzakelijk is. En voetgangers mogen normaal niet het treinspoor volgen. Daar heb je weer een Spoorwegwet voor, die dat verbiedt. Bij tramsporen ligt dat wat subtieler. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] verschil OSMrenderer / Mapnik, lauwersmeer ziet er wat vreemd uit.
Matthijs Benschop wrote: > Er zijn wel meer gekke dingen mbt water aan de hand: > > Zie utrecht en links van woerden: > http://www.openstreetmap.org/?lat=52.079&lon=4.9768&zoom=13&layers=0B00FTF > > En verdwenen water in mapnik: > http://www.openstreetmap.org/?lat=52.0999&lon=4.8731&zoom=14&layers=B000FTF Kijk ook eens boven Amsterdam en bij Muiden. De [EMAIL PROTECTED] client gebruikt het oceantiles bestand , waarin wordt bijgehouden wat de basis van een tile is, land/ocean/mixed, en ik vermoed dat dit de oorzaak is? Oftewel: iemand heeft deze tiles op ocean gezet. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] QA admin_level=2
Skywave wrote: > Hier is bestand zoals ik het dan zou uploaden: > http://skywave0.googlepages.com/osmborders.zip . Als niemand er bezwaar > tegen heeft dacht ik er over om voor de volgende planet dump de import > te beginnen. Als het gebeurt, geef dan alsjeblieft een seintje als je Zeeland hebt gedaan, want dan kan ik de import opnieuw terugcorrigeren. :-) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppunten en naamgeving
René Affourtit wrote: > Als voorstel voor de netwerk relatie: > - Alle rcn_ref nodes van het betreffende netwerk. > - Alle (rcn) route relaties die geheel of gedeeltelijk in dat netwerk liggen. > Je kan dan met een (1) relatie het hele netwerk pakken, inclusief de > verbindingen naar omliggende netwerken. Ik wist niet zeker of nested relations kunnen, maar inderdaad, als dat kan, kunnen de routes erbij. Je bent dan nog steeds in staat om alleen de knooppunten of alleen de routes uit de relatie te halen, mocht je die om een of andere reden apart nodig hebben. > Die opmerking van mij dat de name makkelijk was voor in de editor > sloeg (achteraf) natuurlijk nergens op. Ik snap het wel, want ik dacht in het begin ook zo. Totdat ik een lijst met een half dozijn of meer relaties met dezelfde naam had (in JOSM), en concludeerde dat de naam niks toevoegt in dit geval. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsknooppunt
Lambert Carsten wrote: > Mijn probleem is dat bij het kruispunt er een heleboel 'fietsknooppunten' > zijn > als gevolg van gescheiden fietspaden. Wanneer de fietspaden accuraat > weergegeven worden heb je op een standard kruispunt al gauw 4 'nodes' waar de > fietsroutes keuzemogelijkheden hebben. In bovenstaand geval heb je dan ook > nog een brug over de amstel waardoor het knooppunt nog verder uit elkaar > getrokken wordt. Ai, 1 van de uitgebreidere mogelijkheden dus. > Als de 'centrale' node van het kruispunt de rcn_ref krijgt, dan is dat nét de > node waar geen enkele fietsroute precies overheen gaat. Pak ik gewoon een van > de fietsnodes dan zal dat op een gerenderde kaart er prima uitzien maar route > planners zullen mogelijk ervan in de war raken. Juist, voor de routeplanners werkt dat niet. Ik tag dus inderdaad elk subknooppunt apart. > Dat ziet er prima en logisch uit, maar daar is er maar één node bij ieder > kruispunt. Geen gescheiden fietspaden, blijkbaar. Kom je toch al minder tegen in Vlaanderen, maar dat is een ander verhaal. > Nee, inderdaad, ik ben geen fietsroutes aan het fietsen, maar probeer een > nuttige track te genereren en zoveel mogelijk informatie te verzamelen m.b.v. > een fototoestel. Toch zou (en zal) ik die stukjes route ook moeten invoeren. Moeten niet, mogen uiteraard wel. :) > Is de oplossing via relations om een relation te maken met type=junction en > als member alle betreffende nodes (dus daar waar gekozen kan worden) op te > nemen? Zo ja, moeten dan de ways die die nodes verbinden daarin ook worden > opgenomen? En verder gewoon rcn_ref=61 (en dus NIET name=61 of ref=61)? Een type=junction relation is nog maar een voorstel, waarvan ik totaal niet weet of deze al ondersteund wordt door routers, maar als ik mag gokken is het antwoord: nee. De node(s) alleen taggen met rcn_ref=61, dat is genoeg. Wat ik nu doe, stel het volgende idee: 7080-8090 Het uitgangspunt is dat je op een knooppunt afrijdt, en bij het eerste het beste knooppuntbordje de route naar het volgende knooppunt gaat volgen. Zo zijn de knooppunten (zoals ik ze ken) ook bebordt. Dus als je van 70 naar 80 rijdt, ga je bij het linker bordje 80 al de route naar 90 volgen, maar als je van 90 naar 70 gaat, ga je bij het rechter bordje 80 de route naar 70 volgen. Relatie 1 loopt dus van 7080-80, waarbij het stukje 80-80 een forward of backward role krijgt -- afhankelijk van de onderliggende way(s)! -- zodanig dat je die alleen van rechts naar links kan volgen. Relatie 2 loopt van 80-8090, waarbij het stukje 80-80 ook een forward of backward rol krijgt, tegenovergesteld aan die van Relatie 1. Een routeplanner die je van 70 naar 80 leidt, zal dus bij het linker bordje de conclusie moeten trekken dat a) je op 80 bent en b) dat je het resterende stukje van de relation niet kan fietsen, want dat is tegen de richting in. Uit die conclusie zal dan moeten volgen dat je vanaf dat moment de route/relation naar 90 gaat volgen. Als je een complexer knooppunt hebt, zoals in jouw geval, kun je dit ook op bovenstaande wijzen taggen, maar het is wel wat meer werk. (Met dank aan Eimai, die me de juist tips gaf) PS: Mocht ik er nu grandioos naastzitten met mijn interpretatie, laat jezelf dan horen! Beter ten halve gekeerd dan ten hele gedwaald. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] On demand WMS refresh
Robin Harmsen wrote: > Als dit geautomatiseerd kan (en eventueel ook elke x uur of x dag al gebeurd) > dan is het natuurlijk ook mogelijk ergens een knopje te maken (achter een > login zodat het niet te vaak gebeurt) om het script te activeren dat de diff > download en importeert. Je kunt ook op http://www.informationfreeway.org/ inzoomen tot niveau 12 en dan met 'r' een rerender van [EMAIL PROTECTED] aanvragen. Dan heb je redelijk snel een update van die tile in de osmarender layer. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Antennedata geimporteerd!
Gert Gremmen wrote: > Als we inderdaad de zendrichting kenden, dan konden we > daar ook daadwerkelijke zendbereik bij plotten. De zendrichting is gekend, op de site van het antenneregister. Zoom in op een antenne, en klik links op het i icoontje. Rechts onder Zoekresultaten staan de antenne's, met een linkje Details erachter. Daarin staat de hoogte en het aantal antennes, en kun je doorklikken naar een diagram van de straling en bereik. Alhoewel dat laatste wel tot een bepaalde grenswaarde zal zijn, en het bereik effectief nog iets verder reikt. Het zijn wel plaatjes, maar wellicht is er via het antenneregister ook aan ruwe data te komen? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
