Re: [OSM-talk-nl] Sluiskiltunnel geopend.
On 25-5-2015 12:19, Martien Scheepens wrote: De oude weg is nu een primary met wegennummer N61 én N62. Wat is de huidige status van de weg? Moet N62 niet opgeruimd worden? Heeft de weg überhaupt nog een nummer? (Ik ben nog nooit in Zeeland geweest, dus ik ken de situatie niet) De dubbelnummering van de oude weg (Hoofdweg) over de draaibrug is inderdaad opgeheven. Deze is nog wel de N61. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Sluiskiltunnel geopend.
On 25-5-2015 9:31, St Niklaas wrote: Mooi werk, wie beheert het geheel, de weg en de toeritten ? De NV Westerscheldetunnel. De (mintgroene) kleurstelling van de wegaankleding, zoals lichtmasten en andere bovengrondse elementen, is ook dezelfde als van de Westerscheldetunnel. Sinds vannacht rijdt het verkeer door de Sluiskiltunnel. Het wachten voor de brug bij Sluiskil is daarmee voorbij.Het betekent ook dat u informatie over de Sluiskiltunnel kunt inwinnen bij de NV Westerscheldetunnel. Gisteren werd de Sluiskiltunnel opgeleverd door aannemerscombinatie BAM-TBI aan de BV KKS. De BV droeg de tunnel over aan de provincie Zeeland die op haar beurt het beheer en onderhoud overdroeg aan de Westerscheldetunnel. http://www.sluiskiltunnel.nl/de-sluiskiltunnel/nieuws/sluiskiltunnel-open-voor-het-verkeer?id=152 -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Sluiskiltunnel geopend.
Op 20 mei 2015 21:13 schreef Tijmen Stam mailingli...@iivq.net: De op- en afritten van de Sluiskiltunnel staan nog als under construction, terwijl deze gisteren geopend is. Kan iemand met lokale kennis eens kijken of deze ongeveer goed liggen en dan de construction-tags verwijderen? Aanstaande zaterdag middernacht gaat de tunnel pas daadwerkelijk open. Je kunt er nu nog niet doorheen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Grensgeschil Eems-Dollard
Beste allen, In het Eems-Dollardgebied is al eeuwenlang een grensgeschil tussen Nederland in Duitsland over het verloop van de rijksgrens. De grens die al jarenlang in OSM stond is de Nederlandse interpretatie van deze grens. De Duitsers hebben nu hun idee van de grens ook in OSM gezet. Nu wordt er op het OSM forum een consultatie gedaan van de Duitse community (op het forum) aan ons, hoe hiermee om te gaan. Met deze mail wil ik jullie ook op de hoogte brengen van deze vraag. NL topic: http://forum.openstreetmap.org/viewtopic.php?id=24840 DE topic: http://forum.openstreetmap.org/viewtopic.php?id=24796 -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] planet.openstreetmap.nl
On 4-2-2014 19:55, Colin Smale wrote: De Benelux-downloads vanaf http://planet.openstreetmap.nl/ zijn sinds 13 januari niet meer bijgewerkt terwijl er voorheen dagelijks een nieuwe versie verscheen... Het is nu weer helemaal bijgewerkt. De oorzaak was het stopzetten van de updates tijdens onderhoud en het vergeten daarna weer aan te zetten. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] rwn_ref in de database
On 31-1-2014 17:03, Rob Goethals / SNP wrote: PS. Ik vul de postgis-database mbv osm2psql en krijg dan tabellen zoals planet_osm_line, met daarin ook een kolom rwn_ref. Hierin staat het knooppunt echter niet. De knooppunten, de naam zegt het al, zitten in planet_osm_point. Je moet dan wel de default.style aanpassen, zodat osm2pgsql ze ook daadwerkelijk importeert. Nu je de kolom al ziet in je eigen db, zal je dat waarschijnlijk al gedaan hebben. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] Gebruik layer=-1 voor landuse
On 16-10-2013 8:52, Georges De Gruyter wrote: Het antwoord is gekomen, heb nog op de ongerijmdheid gewezen van zijn vergelijking met tunnel en brug en gevraagd om de discussie verder via de mailing list te voeren : In Nederland is elke landuse=residential met layer=-1 getagt. Dat lijkt me ook logisch want als je bijvoorbeeld een landuse=cemetary of garages of zo hebt, dan wil je niet dat die onder de residential gerendered wordt. Die anderen zijn belangrijker dan de residential. En de residential onderbreken of een gat maken voor de andere landuses is compleet onnodig en zorgt voor veel overbodige data. Ik zie dat niet anders dan een layer toevoegen aan een tunnel of een brug. Daar wil je ook taggen voor de renderer zodat die goed rendert. Een grote landuse is veel overzichtelijker en handiger om mee te werken, in alle opzichten. In Nederland zijn de gebieden met landuse=residential al in een heel vroeg stadium geïmporteerd, in de tijd van de AND-import. Toen was het blijkbaar nodig, of de toenmalige renderers (bijv. osmarender) ondersteunden het niet, om met de hand de landuse te ordenen. Osmarender sorteerde bijvoorbeeld alles per layer en renderde dan de objecten in volgorde waarin ze in de .osm file stonden, dus met oplopende ID's. De huidige methodiek van renderers, in ieder geval die ik ken en gebaseerd zijn op mapnik en/of de standaard kaart op OSM.org, is om te sorteren van grootste oppervlakte naar kleinste (binnen een layer klasse). Als je het in die volgorde rendert, zal het grootste gebied (een bebouwde kom met landuse=residential) altijd onder kleinere gebieden (een grasveld, een kerkhof) komen. Het argument van layer=-1 voor landuse=residential heeft dus zijn oorsprong in het verre verleden. Met de huidige generatie renderers (en manieren om met data om te gaan) is het m.i. niet relevant meer. In NL had de uit de AND-tijd overblijvende landuse=residential allang ontdaan kunnen zijn van layer=-1. Als dat gedaan is, is er alleen indien de landuse=residential valt binnen een nóg groter vlak landuse (bijv. een bos) nog maar een probleem. Echter, daar hebben we tegenwoordig multipolygon's voor, waardoor we een gat kunnen maken in het grotere vlak. En ten slotte, we zouden ook weer kunnen terugkeren op een hele oude discussie, die van landuse als fysieke eigenschap vs. landuse als functie-omschrijving. Het is jammer dat dit in de begindagen niet direct onderscheidend is gemaakt in de tagging. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] Vertaling van OSM labelnamen
On 6-10-2013 16:30, Pander OpenTaal wrote: Tweede vraag, waa zijn de bronbestanden van de vertalingen te vinden? Voor de website staan die op translatewiki. Zie ook http://wiki.openstreetmap.org/wiki/Website_Internationalization -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Crowdsourcing...
On 13-6-2013 19:01, Frank Steggink wrote: Het mooie aan crowdsourcing is dat je veranderingen in de werkelijkheid binnen een paar dagen in de kaart kunt verwerken. Het minder mooie aan crowdsourcing is dat deze wijziging een paar dagen later weer door iemand anders ongedaan wordt gemaakt... Gebaseerd op immer achter de feiten aanlopende lufo's ? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] Initial stuck to the name
On 11-1-2013 20:43, Ben Laenen wrote: Zoals hierboven gezegd: notulen van de gemeenteraad. Dat zal natuurlijk moeilijk op te zoeken zijn voor de meeste straten, maar je kan bijvoorbeeld eens vragen of ze een officiële straatnamenlijst willen ter beschikking stellen. Nog een verlate reactie, maar Ben heeft gelijk. En met wat Google-kennis (het gebruik van site:* ) kun je al heel gericht zoeken zonder al over een officiële straatnamenlijst te beschikken. We weten dus dat er een L. Claeslaan bestaat. Echter, een gemeente werd niet genoemd. Zoeken op osm.org levert 1 hit: Zoutleeuw. http://osm.org/go/0EqYH_5K Zoek dan eens met Google op claeslaan site:zoutleeuw.be. Et voila: Veel hits met Louis Claeslaan. Als je zoekt op l. claeslaan site:zoutleeuw.be kom je ook hits tegen waarbij deze weg in 1 adem genoemd wordt met de Elstraat en Dungelstraat. We kunnen er dus nu gevoeglijk wel vanuit gaan dat L. staat voor Louis. Weer een afkorting in OSM weggewerkt. Aan Guy de eer om deze in te voeren. :) -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] Vertaling van nominatim termen
On 15-3-2013 13:48, Maarten Deen wrote: Waar kan de vertaling van Nominatim aangepast worden? Wordt dat gedekt door de trac tickets, of is dat alleen voor generieke Nominatim zaken (niet specifiek voor de search bij de kaart)? De vertaling wordt gedaan in TranslateWiki. Ik heb het daar nu aangepast naar 'Straat'. Dit zou dan binnen enkele weken terecht moeten komen op de OSM website. PS: living_street was al vertaald als 'Woonerf'. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Mapnik at zoom=19
On 27-1-2013 17:23, Martin Koppenhoefer wrote: current XML would render sufficiently well when you remove the minscale_zoom=18 filters. If convincingly implies different The minscale_zoom18 essentially translates to 'infinity' in the current stylesheet setup: !ENTITY minscale_zoom18 The difference between z18 and z19, apart from scale considerations, is non-existent. Apart from taking storage requirements into account, you could well switch to z19 today. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
On 6-1-2013 15:51, Dave F. wrote: On a related topic; if a field has a barrier tag it changes colour rendering at zoom 16: That's because having a landuse on it as well pushes it into the polygon table. It's subsequently rendered as a barrier area, ie. with the barrier=hedge fill. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Voertuigklassen
On 10-10-2012 21:37, Ben Laenen wrote: Case in point: I still have to find the first road in Belgium tagged with access=destination that explicitely adds bicycle=yes and horse=yes (oh yes, http://www.openstreetmap.org/browse/way/26740921 You're welcome. :) I did that for a while, back then. Then it got tedious and I always forget horse=yes these days. except a road where I added it myself because it had an extra uitgezonderd fietsers sign below the uitgezonderd plaatstelijk verkeer. That extra sign is quite unneccesary. 2.47. De opschriften uitgezonderd plaatselijk verkeer of plaatselijke bediening duiden op een openbare weg die slechts toegankelijk is voor de voertuigen van de bewoners van die straat en van hun bezoekers, de voertuigen voor levering inbegrepen; ook voertuigen voor onderhoud en toezicht, wanneer de aard van hun opdracht dit rechtvaardigt, de prioritaire voertuigen bedoeld in artikel 37 en fietsers en ruiters, hebben er zonder uitzondering toegang. 2.47. Les termes excepté circulation locale ou desserte locale désignent une voie publique qui n'est accessible qu'aux véhicules des riverains de cette rue et des personnes se rendant ou venant de chez l'un d'eux y compris les véhicules de livraison; y sont aussi admis sans exceptions les véhicules des services d'entretien et de surveillance, lorsque la nature de leur mission le justifie, les véhicules prioritaires visés à l'article 37 et les cyclistes et les cavaliers. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] Centrumverbinding fietsknopennet
Als je er nog state=connection bijzet, dan is het helemaal goed. In België zijn deze al wel getagd. -- Lennard - Reply message - Van: dbuss...@goudappel.nl Aan: OpenStreetMap NL discussion list talk-nl@openstreetmap.org Onderwerp: [OSM-talk-nl] Centrumverbinding fietsknopennet Datum: do, sep. 6, 2012 13:47 Beste, in het fietsknopennetwerk Brabant is er een bijzonderheid die tot nu toe niet is getagd in OSM: de centrumverbinding. Op de officiele kaarten zijn deze geel getekend (groen de 'gewone' fietsknopenroute). Het gaat om verbindingen vanuit het (buiten de steden/dorpen liggende) netwerk met een centrale punt. Dorp in zijn deze aangegeven met een bord 'centrum', dorp uit staat een verwijzing naar de volgende nummer. Voorbeeld zie google streetview http://maps.google.nl/maps?q=diessenhl=nlll=51.473044,5.177822spn=0.017268,0.104628sll=51.630698,4.958954sspn=0.0764,0.209255hnear=Diessen,+Hilvarenbeek,+Noord-Brabantt=mz=14layer=ccbll=51.473038,5.177855panoid=PkpWl_PasXFftPjAaq9figcbp=11,87.38,,1,4.58 Ik wil deze graag taggen omdat ze horen bij het fietsroutenetwerk en nu missende schakels zijn waar alle op osm baserende routeplanners (waaronder de onze ;-) rare routes genereren. Mijn voorstel is het aanmaken van een relatie met waardes network: rcn note: centrumverbinding [naam plaats] route: bicycle type: route Op die manier worden de verbindingen in de bestaande toepassingen (b.v. openfietskaart) als fietsknopennetwerk gerenderd (en dat is beter dan nu waar ze volledig ontbreken), maar wie wil kan uit de data halen dat het om een centrumverbinding gaat en deze anders weergeven. Mee eens? Groeten Dirk Disclaimer De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending.___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:14, Ivo De Broeck wrote: Erg is dat, in Potlach zijn ze gewoon correct. En nu Potlach moet de note NIET tonen. Wanneer gaat het eindelijk doordringen dat er internationale afspraken zijn. Potlach is bij mijn weten de enige die deze normen 100% invult. De hiking ipv foot is daar een mooi voorbeeld. Blijkbaar had men nog niet opgemerkt dat 'foot overal in het rood werd weergeven in de wiki en Potlach ongevraagd hiking invult. Tja Tag-verschuivingen zijn in het verleden ook vaak via attritie gegaan, totdat het de moeite loonde om de laatste paar % dan maar in 1x om te zetten. In de wiki zetten dat een tag verouderd is, is echt niet genoeg om het ook zo te laten zijn. De data is leidend, niet de wiki. Verder is er geen mechanisme om mappers van de oude tag in te lichten over elke verandering. Soms ontdekt men dan bij toeval dat iemand ooit in de wiki eens iets heeft neergezet en dat een editor met wat basisinstellingen een andere tag gebruikt voor zoiets als een wandelroute. Tip: Potlatch heeft naast de presets ook prima mogelijkheid om tags naar eigen keuze in te vullen. Zo kun je dus ook met Potlatch route=foot invullen. Je bent niet afhankelijk van wat Potlatch voorschotelt. JOSM is een prachtige tool voor mensen die weten waar ze mee bezig zijn. Potlach is de ENIGE tool voor mappers (kijk bv eens bij building, de gebruikers kan onmiddellijk de juiste soort building kiezen zonder nonsens in te vullen of vijf avonden te studeren om te proberen de wiki (vooral de Belgische) te ontcijferen. building=yes Voila, klaar. Vraag: zijn we nog goed bezig? Dat mag ieder voor zich beantwoorden. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:37, Jan-willem De Bleser wrote: Ge brengt me wel op een gedacht: we hoeven het niet te sorteren, alleen de eindpunten te detecteren. Stel dat je alle wegen doorloopt van de relation en telkens hun eindpunt toevoegt aan een lijst. Deze Je legt met deze methode ook wel meer load op de API. Die is al niet zo vlotjes op complexe relaties met veel revisies. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:43, Jo wrote: Lol, zal ik ze er overal terug inzetten dan? 't Is eigenlijk een kleinigheid. En daarna ga je dan de note tag afschaffen, want redundant? Zo gauw je JOSM en Merkaartor en welke editors hebben we nog meer hebt aangepast zodat die ook de eindpunten zelf vinden. :P Hoe kan een notitieveld van 1 mapper aan de anderen nu ooit redundant zijn? -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 29-8-2012 23:46, Jan-willem De Bleser wrote: Je legt met deze methode ook wel meer load op de API. Die is al niet zo vlotjes op complexe relaties met veel revisies. Sorry, ik volg even niet. Er werd gesproken over het bijkomend inladen van ways om maar de eindpunten te kunnen vinden. Dit in het geval niet de volledige lijst met leden was ingeladen. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland
On 28-8-2012 21:06, Jo wrote: Als ik zo'n paaltje tegenkom en ik volg 1 route, dan zou ik graag ook het begin van die andere routes ingeven, maar ik weet dan niet waar het paaltje aan de andere kant staat. Welk nummer erop hoort te staan, weet ik natuurlijk wel en dat kan ik dus al in de note tag vermelden. Dit is exact de reden waarom ik voorstander ben van het (ook) gebruiken van de note tag. Bij het mappen van zo'n netwerk moet je op een knooppunt toch altijd kiezen voor 1 van de routes, maar de andere kun je alvast als beginnetje aanmaken in OSM, met de note tag als hint. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland, bedankt Jo
On 23-8-2012 15:22, Jan-willem De Bleser wrote: - Verkeerde nummers, zoals relation bicycle rcn -60 die op node 75 eindigt, komen voor omdat de code niet op de juiste manier het eindpunt van de relation bepaalt, maar eerder gokt. Ik heb een voorstel gedaan voor een wijziging in de code dat dit hopelijk zal oplossen. Nu zijn we alweer bezig om deze kwestie voor 1 specifieke editor proberen op te lossen, terwijl een simpelere en meer pragmatische oplossing al jaren in gebruik is: het tonen van een door de mappers zorgvuldig ingevulde note tag. Gaan we nu voor elke editor verzoeken indienen om deze 'name' te ontdekken in de data en te tonen? Want als Potlatch deze manier zonder fouten doet, zullen Potlatch-mappers geen note meer zetten. Consequentie zal dan zijn dat er toch scripts moeten blijven draaien die de note invullen. Naast de editor toont de webinterface van OSM ook niet deze synthetische naam. Terwijl ook daar het tonen van een notitieveld bij afwezigheid van naam en referentie ook de kortste, simpelste en meest pragmatische oplossing is. Het is mij verder om het even welke methode gekozen wordt, als het maar voor elke gebruiker van de data op eenzelfde manier zichtbaar is. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] wandelnetwerk zuid-dijleland, bedankt Jo
On 23-8-2012 21:56, Jan-willem De Bleser wrote: Maar de note tag hoort toch niet getoond te worden? Daar heebben de Potlatch2 devs gelijk in, dat note bedoeld is voor de surveyor en niet de kaartgebruiker. En wie gebruikt de editors? En wie niet? ... Juist: surveyors/mappers resp. kaartgebruikers. Die laatste categorie kijkt naar de gerenderde kaarten. Deze tonen de note toch al niet. Je vraagt nu dat note anders wordt behandelt voor Benelux dan voor de rest van de wereld. Daarbovenop is de note zoals die nu ingevuld wordt redundante informatie, en als we de softwaremakers zover krijgen dat ze die niet meer nodig hebben, des te beter. Je moet *alle* softwaremakers zover krijgen dat ze code ontwikkelen om uit de data deze synthetische naam te destilleren. Dat is me nogal een vraag. Het meest pragmatische oplossing is een naam verzinnen voor die routes, want dat wordt al getoond. Het meest pragmatische oplossing is echter niet noodzakelijk de juiste. Daarmee wordt die naam dan ook getoond in kaarten. Is dat dan gewenst? Ik denk dat we niet zomaar uit zullen geraken. Deze discussie zal nog regelmatig terug kunnen komen. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Missing Maxspeed in Brussels
On 6-8-2012 20:18, Joren DC wrote: I made some big changes in my area yesterday (14:00); According to the wiki it will update every day at 17:00 for the past day. No changes seen so far. I'll wait a bit longer, because this map is very useful in order to keep an overview of the missing speed limits. I'm experimenting with JOSM and trying to make a 'speed limit'-layer if possible. Of course, having maxspeed displayed in JOSM isn't very hard, and done before: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Maxspeed_tagging Also, for the Benelux, we have our own maxspeed overlay, which is updated continually: http://maxspeed.openstreetmap.nl/ http://maxspeed.openstreetmap.nl/?zoom=12lat=50.8562lon=4.38844layers=B -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Coastline Update
On 1-4-2012 3:40, Paul Norman wrote: Just be careful to not accidentally upload the .osm that indicate the problems. You should modify it to have upload='false' in there. Then JOSM will discourage you from uploading that file. osm version='0.6' upload='false' See http://josm.openstreetmap.de/ticket/4043 -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Toponym
Frank Steggink wrote: Dan gebruik je landuse:AND. Ik dacht dat je de name-tag van AND wilde bewaren. Achteraf gezien was dat beter geweest. En het is niet internationaal te gebruiken. Ik kan me niet voorstellen dat deze situatie (gebied opgebouwd uit losse stukjes) in het buitenland niet voorkomt, zeker nu we Bing lufo's mogen gebruiken. Wat er ook verandert, het is toch mooi als dat internationaal te gebruiken is? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-GB] Hatfield Tunnel not appearing as a tunnel
On 23-3-2012 3:55, mick wrote: A relation tagged as a motorway will render as such. What would then happen is that the tunnel way is actually rendered, but then the non-tunnel motorway relation is rendered on top of that. Perhaps its time to review the rendering, many motorways have sections that pass through tunnels and should be rendered to show this. I found it off-putting when my Navman failed to indicate a tunnel the first time it happened. What exactly do you believe is wrong with that rendering, currently? And what does Navman have to do with the default map on osm.org? -- Lennard ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Hatfield Tunnel not appearing as a tunnel
On 24-3-2012 1:00, mick wrote: The rendering of 'tunnel' should over-ride 'motorway' showing that the motorway passes through a tunnel. And so it does. But then someone creates a relation, tags it as non-tunneled motorway as well, adds a whole bunch of motorway ways including tunneled sections to it, and hey presto: that someone has overridden the override. Don't blame the renderer for bad tagging. You can certainly blame it for lots of things, but not that. -- Lennard ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] osm2pgsql hstore (was: Wind turbines no longer rendered on mapnik layer)
On 16-2-2012 19:25, Graham Jones wrote: grumble Why create a key generator:power_source rather than just use power_source. power_source is much more generic so you could re-cycle it for things like district heating, but generator:power_source is only ever going to be used for generating stations, and needs a new column in the database. /grumble. I think I just prefer more generic, re-usable keys rather than trying to invent a new one for each situation This is a core problem with the public_transport=* scheme as well. This tag in and of itself is fine, but the whole additional shebang that is train=yes/no, bus=yes/no, subway=yes/no, etc etc is so dreadful (in the context of the rendering chain) that every time I read #2798 I feel the urge to run away screaming. http://trac.openstreetmap.org/ticket/2798 -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wind turbines no longer rendered on mapnik layer
On 15-2-2012 17:06, Morten Kjeldgaard wrote: I received the following reply at 10.14.44 GMT+01:00: Hi mok0, Thanks for the notice, and I'm currently submitting a changeset where everything with generator:source=wind also has power_source=wind specified as well. Also, I'll take a look into the mapnik style sheet to see how this can be updated to remove the depreciated tags. Aside from the existence of generator:source=wind this demonstrates he hasn't quite understood it yet. The new scheme should be added[1] to the stylesheet, but the old scheme should not be removed. At least not before the overwhelming majority of existing objects are compatible with the new tagging, or after some extensive time has passed to allow this tag change to propagate. [1] Has now been done, but not deployed yet. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Snelheidslimieten
On 13-2-2012 9:57, Sander Deryckere wrote: Je kan ook even op de maxspeed kaart kijken om te checken welke wegen een maxspeed tag gekregen hebben, en welke die zouden moeten krijgen (als de maxspeed niet af te leiden is uit de omgeving dmv algoritmes). http://www.itoworld.com/product/data/ito_map/main?view=124 (deze kaart vraagt wel wat tijd om te laden). Als dat te langzaam is, is er ook nog http://maxspeed.openstreetmap.nl/ (Hoewel ook die weleens langzaam kan zijn :)) -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] losse wegdelen of een geheel?
On 15-1-2012 22:34, drek wrote: Kan iemand mij vertellen of het voor osm handiger is om een straat uit meerdere delen te laten bestaan, of dat een straat uit één gedeelte de voorkeur heeft? Het maakt voor OSM niet uit welke methode je toepast. De methode waarbij elk stukje tussen kruisingen/aftakkingen een eigen way is, is voornamelijk afkomstig vanuit de AND-import. Je kunt deze stukjes zonder problemen samenvoegen wanneer ze identiek zijn. De AND-id mag je wissen. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] losse wegdelen of een geheel?
On 16-1-2012 8:22, Maarten Deen wrote: Ik ga nu iets heel vies zeggen, maar als je wegen opsplitst wordt de naam ook opnieuw gerenderd. De naam wordt normaliter in het midden van de weg gezet, dus bij ver inzoomen kan het gebeuren dat je bij een lange weg geen naam ziet. (tagging voor de renderer, bah!) Het argument contra is dat je bij allemaal korte stukjes kans loopt helemaal geen namen te zien, omdat het label dan langer zou zijn dan de way en niet wordt gerenderd. Overigens worden de namen van residential/unclassified wel herhaald, elke 300 tot 400 pixels. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] rendle
On 11-1-2012 19:33, Sander Deryckere wrote: Met de nieuwe CT geef je als mapper idd alle rechten aan de OSMF. Het heeft dus niets met de licentie op zich te maken maar wel met de CT. Je geeft de rechten niet aan de OSMF. Je verleent de OSMF een eeuwigdurende, niet herroepbare, etc., _licentie_ op jouw data. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] Gemeentelijke herindeling in Noord-Holland
On 6-1-2012 18:19, Frank Steggink wrote: Het gaat hierom: De gemeente Hollands Kroon - een samenvoeging van de voormalige gemeenten Anna Paulowna, Niedorp, Wieringen en Wieringermeer - is de jongste fusiegemeente in Nederland. Is hier al iemand mee bezig? http://www.openstreetmap.org/browse/changeset/10258974 http://woonplaatsgrenzen.openstreetmap.nl/?zoom=10lat=52.86994lon=5.00638layers=B0F Was OSM weer de snelste met de updates op de kaart? :-) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Gemeentelijke herindeling in Noord-Holland
On 6-1-2012 21:29, Frank Steggink wrote: Ook deze update was wel een persmomentje waard ;) Shame on me dat ik niet eens de moeite nam om het in de kaart te checken! Ik doe deze updates al enige jaren. Deze was nog erg makkelijk, want er waren geen grenscorrecties nodig, of een voormalige gemeente die over twee andere gemeenten werd verdeeld. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Het IJ leeggepompt!
On 2-1-2012 12:07, Frank Steggink wrote: Ook hier zie ik geen fout in JOSM. Bij het opnieuw renderen van het gebied wordt de Westhaven nu wel goed gerenderd, behalve het stukje bij ADM. Misschien kan hier Lennard of iemand anders even naar kijken, aangezien hij het renderingproces beter begrijpt. Er zit blijkbaar iets fout. Misschien een Mapnik-update? Ik pas nu niks aan aan de data. Deze way zit niet in de mapnik db op tile.openstreetmap.nl en rendert bij ons dus ook niet. Aangezien deze way op osm.org ook niet rendert, vermoed ik dat deze niet goed in de diffs heeft gezeten. Dat kan ook verklaren waarom deze dan wel weer verschijnt als er een nieuwe update op die way gemaakt wordt. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Bushaltes en GSM antennes
On 18-12-2011 1:19, Stefan de Konink wrote: Ja, dat is dus het grootste probleem. Er is geen changeset viewer en de wijzigingen voor 0.6 staan niet in changesets. Van de wijzigingen voor 0.6 zijn synthetische changesets gemaakt, door edits die 'bij elkaar lagen' (per mapper, in tijd en/of ruimte) in een changeset te stoppen. http://www.openstreetmap.org/browse/changeset/1 -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [OSM-talk-be] Fietsknooppuntennetwerken, hun complexiteit en begrijpelijke misverstanden eromheen
On 24-11-2011 22:20, Jo wrote: Verder is er in Oostende een stel bruggen met een gelijkaardige situatie, maar dan op de route, niet tussen de gesplitste knooppunten in. Het is zeer waarschijnlijk dat er in Nederland ook van dat soort situaties gevonden kunnen worden. Uiteraard zijn die in NL ook te vinden: http://www.openfietskaart.nl/?zoom=15lat=51.33094lon=3.8202layers=BTTT http://osm.org/go/0EmKK5EQ--?layers=C Zelfs drie sluizen op een rij. Ga je dan ook 3^2 routes aanleggen? Op dit moment ligt daar heel pragmatisch een enkele route over het sluizencomplex, tussen 25 en 28. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk NL De Meierij
On 12-11-2011 0:29, Jo wrote:
De olifant is daar langsgeweest en heeft dat punt enkel in Meetjesland
behouden. Het ligt ook net in België, heeft 2 verbindingen met
Het ligt exact op de grens.
minder dan ik had gehoopt :-) Het zou leuk zijn om een foto van het
bordje te zien, als daar de naam van het Nederlandse netwerk opstaat,
Foto's lukten niet meer i.v.m. tegenlicht (het bord was zwart op de
foto), maar aan de NL kant van het punt hangt een NL knooppuntbord
('Fietsnetwerk Zeeland') en aan de B kant een B bord ('Meetjesland').
Overigens, om een of andere reden hebben ze in Zeeland besloten om het
knooppuntnummer zelf niet op het bordje te zetten. Hier staat dus op de
knooppunten enkel een bord met de nummers van en de pijlen naar de
daaropvolgende punten. Dat terzijde. Geen idee of dat in heel NL
gemeengoed is.
Het gaat voor mij namelijk tegen alle logica in dat knooppunten tot
meerdere netwerken kunnen behoren. Weeral een veronderstelling die
voor mij vanzelfsprekend was, die ik blijkbaar moet opgeven. Al mijn
'heilige huisjes' gaan aan diggelen :-)
Ik wil er nog wel 1 aan diggelen gooien hoor!
http://osm.org/go/0EjbuSc1?layers=C
Situatie: een 'gesplitst knooppunt', dus 2x hetzelfde nummer, maar dan
op enige afstand van elkaar. In dit geval een 200-tal meters. Het
westelijke punt is 'Meetjesland', het oostelijke bord toont 'Waasland'.
De toeleidende borden laten duidelijk zien dat dit wel degelijk
hetzelfde knooppunt is. Vanaf de eerste '82' die je tegenkomt staan
namelijk al de nummers van knooppunten die voorbij de tweede '82' liggen.
Dit is vast weer een uitdaging om in je script te verwerken? :-)
--
Lennard
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk NL De Meierij
On 12-11-2011 0:41, Jo wrote: mij betreft mogen ze samen. Ik heb ook al een paar keer voorgesteld om de hiërarchie van de collections uit te breiden, maar daar krijg ik geen reactie op. Vlaanderen/Provincies/Regio's/Regio's onderverdeeld (zoals ze nu zijn) Ik zie daar niet direct praktisch nut in. De lands- en provinciegrenzen zitten in OSM. Vaststellen in welk land of provincie een netwerk valt moet daarmee afdoende mogelijk zijn. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk NL De Meierij
On 11-11-2011 9:00, Jo wrote: aangezien er een paar streken gelijkaardige namen hebben. Voornamelijk (De) Kempen, maar ook Limburg, Brabant en zelfs (Zeeuws-)Vlaanderen. Ik ben toch benieuwd hoe je Oost Zeeuws-Vlaanderen en West Zeeuws-Vlaanderen gelijkaardig ziet aan Kust, Meetjesland en Waasland? PS: ik had ergens gehoopt dat er iemand interesse zou vertonen in wat ik aan het doen ben. Zoveel interesse dat ze mee zouden gaan doen om al die netwerken in orde te beginnen zetten met behulp van het Python script dat ik gemaakt heb. Het duurt veel langer om alle netwerken in Nederland af te lopen, dan dat het in België geduurd heeft. Ik had interesse, maar om eerlijk te zeggen ben je in mijn ogen van start gegaan als een dolle stier in een porceleinwinkel, door al te gaan knutselen aan bestaande situaties, met je eigen interpretatie en veranderingen, zonder dat minstens (hier) eens voor het voetlicht te brengen voordat je dat ging doen. Had je dat anders aangepakt, zou het proces toch al heel wat vlotter hebben gelopen. Ook het arbitrair opknippen van netwerken in kleinere brokken en het verzinnen van eigen netwerken was niet handig. Om het toch nog positief te houden: je bent gelukkig op sommige punten teruggekomen en hebt betere inzichten gekregen. :) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsroutenetwerk NL De Meierij
On 11-11-2011 22:05, Jo wrote: Ik had het vooral over Kempen. Ik vind Zeeuws-Vlaanderen nogal gelijken op Oost-Vlaanderen en West-Vlaanderen, maar je hebt gelijk. Ze hebben dan wel 11 karakters gemeen, maar het is toch een land van verschil. :-) In België waren er nog geen netwerken en ik had geen kaarten, ben te arm om ze te kopen en wilde ook niet in de verleiding komen om daarvan te gaan kopiëren. Als je met 'netwerken' netwerkrelaties bedoelt: die waren er wel degelijk. Zelf had ik in ieder geval die van Meetjesland en Waasland aangemaakt. Uiteraard ging ik daarbij uit van de (in mijn ogen) logische veronderstelling dat elk knooppuntnummer slechts eenmaal per netwerk voorkomt. Daar ben ik inderdaad al op moeten terugkomen. Een vraag hier had veel werk voorkomen. Als er iemand is, die echt zin heeft, om die netwerken met dezelfde naam maar met Oost, Zuid e.d. bij elkaar te gaan voegen, dan moet die dat maar doen. Ik wilde daar 'hapklare' brokken van maken. Relaties met 300 leden laten zich vlot bewerken. Niet vlot? Dan nog, dat is een technische zaak en moet niet leidend zijn bij de indeling van netwerken. Ik denk dus wel dat ik het een en ander gerealiseerd heb, ondanks de misschien onhandige wijze waarop. Tegen dat ik/we klaar zijn, zullen ze allemaal op een consistente wijze gecodeerd zijn. Ik zal niet ontkennen dat het zeker wat oplevert, na wat valse starts. En dan de nameskwestie, tja. Ik heb pogingen ondernomen om note ook in Potlatch te laten weergeven, maar die willen daar niet van weten. Voor Het idee was vast te 'duits' voor ze (Duitse mappers verzinnen de gekste dingen) en ze erop wijzen 'dat JOSM het wel kan' helpt ook niet echt bij de makers van andere editors. :-) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppuntenrelaties in Nederland
On 3-10-2011 22:21, Jo wrote: (en om me bij te staan bij het aanmaken van networkrelaties, want die hadden we nog niet). Die waren er al wel enkele. Er wordt een rapport aangemaakt dat kan gepost worden op de wiki: http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Cycle_Routes/Node_Network Ik zou zeggen: draai het eens voor de Nederlandse knooppuntennetwerken en zet het op de wiki, zodat we kunnen zien wat het voor NL kan betekenen. Is het nodig dat de knooppunten zelf, ook deel uitmaken van de routerelaties? Ze zitten al in de networkrelaties en maken deel uit van de routerelaties via de ways. Ik had dat bedacht, omdat je dan vaak wel al de nodes toe kunt voegen, zelfs als je de complete route nog niet hebt. Ook om het een script niet al te moeilijk te maken, doordat je dan niet de ways hoeft na te kijken op het aanwezig zijn van rcn_ref nodes. Als er twee knooppunten vlak bij elkaar liggen met hetzelfde nummer, dan heb ik die in België verbonden met hun eigen routerelatie (note=45-45). En alle 'externe' relaties komen slechts toe op 1 van deze knooppunten. Kan dat in Nederland ook zo? Wat in België werd gedaan door enkelen is ook dat stuk opnemen in de resp. routerelaties, maar het stuk tussen de gelijkgenummerde nodes zo taggen met forward/backward-roles, dat dat stuk maar 1 kant op gevolgd kan worden. name vs note. Ik heb in België grotendeels de name tag verwijderd, voornamelijk als hij dezelfde informatie bevatte als de note tag. Hoe gaat dat in Nederland? Grotendeels idem. Let er wel op dat er enkele knooppuntennetwerken zijn die *wel* een naam gebruiken voor routes. Oostelijk van Nijmegen bijvoorbeeld, ZIMKH. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppuntenrelaties in Nederland
On 4-10-2011 0:00, Jo wrote: Maar de ways waar die knooppunten deel van uitmaken, die kan je toch altijd al toevoegen. Als je weet hoe de route toekomt op dat knooppunt. Ik ging uit van de situatie die ik weleens tegenkwam: je zit op een knooppunt en gaat een kant op. De andere kant kun je immers niet gelijktijdig volgen, maar je ziet al wel naar welk ander knooppunt het gaat. Thuisgekomen zie je dat dat andere knooppunt al in OSM zit, en je voegt dan dat punt toe aan de 'stub' routerelatie die je aanmaakte voor de route die je niet gevolgd hebt. In principe kun je dit ook af met een note=xx-yy. Het stelt ook niet zoveel voor om op zoek te gaan naar de rcn_ref nodes. Als je dat niet doet, weet je ook niet of er meer dan 1 node met rcn_ref is. (wat toch wel een indicator is dat er iets fout zit met zo'n routerelatie) Uiteindelijk moet je inderdaad de nodes van de ways toch overlopen om te kunnen bepalen of ze een ononderbroken keten vormen. Het werd door relatief velen zo gedaan. Ik heb die weggehaald (onder andere omdat het mijn test voor voorwaartse/terugwaartse continuïteit verstoort en vooral omdat het gewoonweg niet nodig is). Ook omdat ik ze eventueel, als daar echt om gevraagd zou worden, ook weer terug kan 'herstellen', zoals ze waren. Sowieso werkte je met een ander forward/backward-idee dan wij. :-) Dit is dan wel het enige dat je grondig veranderd hebt. Al het andere is creëren van nieuwe relaties. Uit de naamgeving van de network relaties kan niet worden afgeleid dat het om fietsknooppuntenrelaties gaat. De wandelnetwerken zijn daar wel duidelijker in. Ik heb er al een paar gewijzigd die bij de grens liggen. Is het OK als ik dat doortrek naar de rest. En zo ja, is het dan beter om voluit te gaan: Een van de uitgangspunten in OSM is dat er niet afgekort wordt. Of je dit ook toepasbaar wilt verklaren op zulke lange woorden als Fietsknooppuntennetwerk weet ik niet. :) Let er ook op dat er geen landelijke overeenstemming is over hoe de netwerken precies te noemen: Fietsknooppuntensysteem 'FIKS' Fietsknooppuntennetwerk Knooppuntennetwerk Fietsroutenetwerk 'FRN' Knooppuntroutes -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] There are new coastline shapefiles
On 2-10-2011 10:42, Michal Migurski wrote: This should be an improvement over the previously shapefiles, which are almost 18 months out of date: http://wiki.openstreetmap.org/wiki/Coastline_error_checker#New_hosting_required The coastlines as used on osm.org are not 18 months out of date. They are regenerated more often. At an educated guess this happens every few weeks. The coastline error checker slippy, however, is a bit under the weather. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] There are new coastline shapefiles
On 2-10-2011 11:09, Michal Migurski wrote: The one from http://hypercube.telascience.org/~kleptog/ says April, 2010. Once service from that site become spotty, generation of the coastline shapefiles was moved locally, to the osm.org server. The one from http://tile.openstreetmap.org/processed_p.tar.bz2 says July 2011, which is better. I only recently learned about this second one, and the wiki page for the error checker still says that the files come from Hypercube and that they need new hosting. What should the wiki say to reflect the newer-more-up-to-date data source? At least they're documented in the Mapnik page: http://wiki.openstreetmap.org/wiki/Mapnik#World_boundaries But seeing as there are often multiple places where a single fact is documented in the wiki, it doesn't surprise me that older references linger. :) The de facto source of relative current coastline shapefiles for the past year or two is tile.openstreetmap.org, and you could update references to hypercube to point there. The coastline error checker slippy, however, is a bit under the weather. What is the coastline error slippy? The slippy map. The map you (used to) see when you go to http://coastline.openstreetmap.nl/ -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Fietsknooppuntennetwerk/Cycle node network
That is OK for JOSM, but a list like this (at the bottom) is simply not meaningful. http://www.openstreetmap.org/browse/changeset/917?relation_page=3 This is much clearer. Then ask for that page to display a note=* tag when a name=* is absent, like JOSM does. But why would you start making collection relations when a scheme already exists? See here: http://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging Which as far as I can see meets your needs and relations conforming to that scheme have been in the database for over a year. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] BAG (Was: Diverse vragen)
On 29-8-2011 23:44, Floris Looijesteijn wrote: ik zie wel mogelijkheden voor een update script. ik zeg niet dat ik het ga maken :) maar het is wel mogelijk. Inderdaad, dat lijkt me ook. Een BAG ID is het meest voor de hand liggende, maar ook een vergelijking op geometrie kan. Je krijgt te maken met onaangeraakte objecten en aangepaste objecten. Bij die laatste hangt het dan weer af van wat er aangepast is: tags of vorm. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] Problems with JOSM's unwanted behaviour.
But If you click on the last node of your way, then press Alt while adding the next node, then you end up with a new way that share its first node with the previous way. Exactly, and that was what he was told in the ticket. I entirely disagree with the suggestion to disable autocontinuation, and am very content with the way JOSM currently works in that respect. The example in the ticket (starting from a node in the middle of a way produces a continuation) is convoluted as well. It *doesn't* do a continuation of that way. That's also impossible in the data model. In the example (in the ticket) that node is also the endpoint of *another* way, and it does do a contination of *that*. However, it's made out to appear that selecting a non-endpoint node of a way and then drawing from that will produce a continuation. Not so. In short: use the modifier key when drawing a new way from an existing endpoint node. Don't go through all the hoopla of extending a way, then splitting it, deleting the tags, applying new tags. That only makes life difficult and indeed obfuscates the way history. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Problems with JOSM's unwanted behaviour.
In the example (in the ticket) that node is also the endpoint of *another* way, and it does do a contination of *that*. However, it's made out to appear that selecting a non-endpoint node of a way and then drawing from that will produce a continuation. Not so. No, you didn't understand the examples. I never sayed that a road was boken up in the middle and then continued. It is just when you start a I was not saying that either. [...] This is exactly what happens when editing at node 803205990. This is exactly what I described. As most often, you intend to add a new road, the default behaviour should be like that. I think it comes down to being of another mindset. For me, clicking an end node to continue that way seems the natural thing to do. If it so happens that end node is part of a crossing, so be it. I have to remember to use ALT if I want to start a new way at the crossing. Of course, I could be entirely spoilt from having worked this way in JOSM for years. I thought Potlatch did the exact same thing. What is the handling in Merkaartor for this situation? (Count once your ways when editing and compare extended existing versus added new ways) That's not a fair comparison. Often enough when adding new ways, you are *not* at a junction with another way endpoint. You might be starting a new way in the middle of nowhere, or branching off of another way, but *not* at a junction. In my experience, when adding new ways, starting one at an 'endpoint junction' is the exception. The splitting and additional obfuscating happens, while this seems the obvious way for most users of getting out of this unexpected alongation. For some messy results see my examples Verstrekenstraat and Jachtdreef. I can actually agree with your other point, being that when splitting a way, the existing ID should stay with the longest fragment. You might modify your JOSM ticket to emphasize that part, or perhaps even better: start a new ticket with just that request (with a reference to the current ticket). -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] Paden Scheveningse Bosjes
On 11-7-2011 15:44, Frank Fesevur wrote: Ik neem aan dat ik met de revert changeset plugin in JOSM de boel ongedaan kan maken, maar hoe krijg ik dan die POIs weer terug? Is dat handwerk (dan vrees ik dat ook die info zal verdwijnen) of is er wat slimmers te bedenken. De reverter plugin is inderdaad wat je nodig hebt. - Download een ruim gebied om die paden. - Met JOSM Search: -- changeset:8582281 (replace selection) -- type:node | type:relation (remove from selection) - Verwijder handmatig alle overige ways uit de selectie die niet met die paden in de Scheveningse Bosjes te maken hebben. - Blijven 3 ways over: 67331247, 119629626, 39018904 - JOSM Search: child selected (add to selection) - Nu heb je die 3 ways en alle nodes daarvan geselecteerd. - Start de reverter plugin, voer 8582281 in en kies de laatste optie: Revert selection and restore deleted objects - Controleer, upload. Heb ik dus net gedaan, maar misschien hebben anderen ook wat aan het stappenplan. Mocht er dus meer te reverten zijn voor die gebruiker. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Paden Scheveningse Bosjes
On 10-7-2011 20:33, Frank Fesevur wrote: Wat is het handigste om te doen? Terugdraaien is niet het moeilijkste. Er zitten wel veel meer edits in die changeset dan het commentaar Memorial place added doet vermoeden. Er zijn ook veel POI's toegevoegd (versie 1) of gewijzigd (v2+). Het beste kun je met de gebruiker contact opnemen om te vragen wat de kern van zijn edit was, voordat we de hele changeset gaan reverten. Ik vraag me hierbij dan af of een gebruiker in zijn allereerste changeset daadwerkelijk zoveel nieuwe POI info toevoegt, of dat er iets anders gespeeld heeft. Wellicht is hij aan het speledingen geweest in Potlatch, zonder het idee dat dat allemaal toegevoegd zal worden aan OSM. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Boeien nederlandse kust
On 27-6-2011 20:54, ZeilDude wrote: Is er een tag oid om aan te geven dat een object automatisch wordt gegenereerd en bijgehouden? Oftewel menselijk ingrijpen/updaten is niet nodig (wellicht gewenst) tenzij dat in de bron gebeurt (welke OSM-DB dan niet is)? Voor gemeentegrenzen die we direct door een gemeente aangeleverd hebben gekregen, hebben we toendertijd authoritative=yes gebruikt. Ik hoop ook dat als jullie updates gaan verwerken binnen OSM, terwijl iemand een boei heeft verschoven, jullie serieus kijken wat er daar aan de hand was. Het kan toch net zo goed zijn dat de brondata fout was? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] the map on osm.org - airstrips showing only at zoom 10
On 25-6-2011 8:35, John Smith wrote: Wasn't there some discussion about that before, how important airports such as LAX should show sooner than regional airports which should show up sooner than grass airstrips. Oh, more than once. Nothing (that I know of) came of that. http://trac.openstreetmap.org/ticket/1835 -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] the map on osm.org - airstrips showing only at zoom 10
On 24-6-2011 4:25, Robin Paulson wrote: mappers in NZ have recently imported a lot of grass airstrips into OSM. it appears the airstrips only render at zoom 10 on the mapnik render of the map at osm.org, which looks like this: http://www.openstreetmap.org/?lat=-37.243lon=175.014zoom=10layers=M is there any particular reason for this, osm.org map maintainer? No, not at all, except that it can be considered a bug. There hadn't been many airstrips tagged before this import happened, and only now is it plainly obvious the zooms are buggy for them. I've actually had this reported to me somehow, some time ago, but forgot about it. There was no trac ticket created either. Would be helpful if you could do that. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] bulk_upload.py consistently results in 500 server error
On 19-6-2011 18:54, Grant Slater wrote:
Yes the reason the upload was was failing was due to a Precondition
Fail error (aka deleted node or similar)
Would now be a prudent time to ask the TS ('KKL Import') why he is
uploading such a huge dataset[1] in one operation? To me that sounds
like just asking for trouble, and trouble is what he got.
If you upload 600k nodes, before you get on to uploading the ways that
use those nodes, you should absolutely _not_ be surprised when someone
comes along and deletes one of those nodes before you upload the
relevant way. The chances of something like this happening rise
immensely with time and the amount of floating nodes you're accumulating.
[1] ~600k nodes, ~4k ways, 280 relations
--
Lennard
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] bulk_upload.py consistently results in 500 server error
On 19-6-2011 21:56, KKL Import wrote: Yes you are right, I've learned it the hard way. All the changes are now reverted and in the next attempt I'll be uploading self-contained chunks of data each time. I've had this same thing happen once or twice on an upload. I simply found the deleted node, undeleted it, and resumed the upload. Nuking 600k nodes and then reuploading them (creating new nodes in the db) is not the most elegant way of doing things, either. :-/ -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Workshop Trage Wegen
On 9-6-2011 21:40, Wouter Hamelinck wrote: * First of all, please try to avoid mapping in the Haaltert region the until that day. Now there remains a lot to be done (it is just out of the old good quality Google image area). For newcomers it is more fun if their work shows clearly on the map. I seriously hope you actually meant just out of the old good quality BING image area ? * If I remember well OSM-be has some loggers available for mapping parties and the like. I could not find a page on the wiki about it. Anyone has information? If they are available and could be used for the workshop, how can I get them. I am commuting between Ghent and Brussels so I can easily pick them up in any those two cities. http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GPS_Devices -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Airspace Co.
However, I would suggest that this is not a particularly hard problem to solve; the editor can hide all nodes with a certain tag or put them in a different layer. Currently, available editors don't do that. JOSM does that. Particularly well, too. Have a look at the Filter stuff. Can't speak at all about Merkaartor. Potlatch doesn't do it, but it seems it's a feature just waiting for a developer. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Hoe gecombineerde bruggen te mappen?
Zoals een collega van me al zei, ways zouden een relatie met een brug moeten hebben, zodat dingen als 'de brug is dicht' ook invloed kunnen hebben op de wegen er overheen. Die relatie is er al. Behoorlijk sterk ook. 'Brug' is namelijk een eigenschap die we direct op wegen zetten. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] omtagging motorway_links door It's so funny
On 7-6-2011 21:17, Colin Smale wrote: T.a.v. motorway_link op parallelbanen met doorgaande functie (bijvoorbeeld op de A2 langs Utrecht) heeft hij/zij de praktijk omgedraaid. Vroeger stond in de wiki dat parallelbanen (niet zijnde op- en afritten en verbindingsbogen) ook gewoon motorway waren. Voortaan zijn dat dus motorway_links. Zie: Say's who? http://wiki.openstreetmap.org/wiki/NL:Map_Features#Wegen Ah, hij is zèlf degene die deze wijziging in de wiki heeft gezet. Ik zie ook geen basis voor deze wijziging in de engelstalige pagina's. Tot nu toe is het mij niet gelukt om hem/haar te laten deelnemen aan een openbare discussie over zijn acties en de rationale erachter. En dat is jammer, want ik ben persoonlijk niet zo gecharmeerd van het taggen van parallelwegen met motorway_link. Dat is misschien goed en wel als die parallelwegen maar over een korte afstand bestaan om daarna bij de hoofdrijbaan te komen, maar wanneer dit vele kilometers duurt, vind ik het in ieder geval gewoon een motorway. Deze persoon zit wel (en nog niet zolang) op het forum: http://forum.openstreetmap.org/profile.php?id=9578 -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On 1-6-2011 15:20, ce-test, qualified testing bv - Gert Gremmen wrote: Martijn, je wilt niet weten hoeveel verschillen er zijn tussen de 3D gebouwen en de BING foto's. En dan heb ik het alleen maar over de toegevoegde/gewijzigde gebouwen waarvan je gevoeglijk kunt aannemen dat de BING nieuwer is. Dan is er nog de derde optie: dat de foto (of 3dShapes) verschoven is. Verder verschilt de 3dShapes data weleens per gemeente, zeker de gebouwen. Waar in de ene gemeente vooral rechthoekjes getekend zijn, zijn bij de andere gemeente dan weer overal ook schuurtjes te zien. Als je in Groningen (stad) kijkt, zie je zelfs dat rijtjeswoningen of -flats als 1 gebouw getekend zijn, maar met wel overal extra nodes, vermoedelijk dus de locatie van de perceelscheidingen/tussenmuren. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG = BAGGER ?
On 1-6-2011 15:54, Cartinus wrote: BAG = Basis Administratie Gebouwen Zoals de naam al zegt, dan zijn dus gebouwen, geen straten. Bijna goed. :) Basisregistraties Adressen en Gebouwen Dat betekent niet dat er straten instaan, maar wel dat er adresgegevens voor de gebouwen ingevoerd zijn. Dat opent de weg naar nog een andere leuke verificatietool: kijken of een in de BAG genoemde weg inderdaad binnen xxx meter van dat gebouw te vinden is in OSM. Indien niet: vlaggetje op de kaart met hey, is hier alles ok? -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On 1-6-2011 16:08, Jeroen Muris wrote: Trouwens, is die Nijmegen-import ergens gedocumenteerd? Ik kon op de wiki niks vinden. Nee, voor zover ik heb kunnen nagaan is die import nergens gedocumenteerd. De gebruiker 'nijmegen' was onbereikbaar. Ik heb daarna contact gehad met de gemeente Nijmegen. Zei zeiden: Neem voor verdere informatie eens contact op met Roeland Douma. Leest uiteraard (en hopelijk regelmatig) mee hier. Hij heeft de import uitgevoerd onder dat account. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] BAG
On 1-6-2011 16:02, dbuss...@goudappel.nl wrote: Synchronisatie hoeft volgens mij niet super-moeilijk zijn. De automaat kijkt dan naar het datum van de laatste wijziging. Als de BAG recent heeft gewijzigt wint die, anders OSM. Dit inderdaad per attribuut (en geometry als verzameling van alle nodes is voor het gemak een attribuut). Ook verwijderen is een wijziging die kan winnen. Dus een welbewust weggehaald pand in osm wordt niet indirect via de BAG weer hersteld. Daar waar afwijkingen zijn kunnen wij die als een extra tag (SYNC of zo) expliciet maken zodat plaatselijke mappers dat eventueel op kunnen pakken. Wat dat betreft met Vincent eens. Ik zie veel heil in een interim database, waar alle BAG objecten in komen. Dit maakt meerdere dingen mogelijk: 1) BAG updates zijn eenduidig te verwerken, doordat het BAG id nooit verloren kan gaan. 2) Elk object kan vlaggetjes krijgen dat de status van dat object in OSM aanduidt: geïmporteerd (+timestamp), niet geïmporteerd, gesloopt, etc. Geen dubbel werk en als er twijfel is over een gebied/pand, kan dat later nog een keer aan de orde komen. Lokale mappers kunnen benaderd worden. 3) Vanuit deze db kunnen overlays gerenderd worden alsook diagnosetools draaien. 4) Je zou er als locale mapper een plukje gebouwen uit moeten kunnen selecteren, die dan met de hand verwerkt kunnen worden in OSM. 5) Het maakt spatiële analyse andersom mogelijk: pak een OSM gebouw en kijk of dit in de BAG ook bestaat. Komen de adrestags overeen? Kan OSM aangevuld worden? Is het gebouw in OSM een eenvoudige BAG-dump of zitten er verrijkende tags (amenity, etc) op? En het voorkomt dat je iedere keer opnieuw 'het wiel moet uitvinden' of door zowel de hele OSM-db als BAG moet lopen om wijzigingen te detecteren. Zoals Frank al aangaf: BAG id's op OSM objecten hangen biedt geen enkele zekerheid. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] waterweg rond weiland taggen?
On 31-5-2011 9:10, Rick van der Zwet wrote: Al de weilanden zijn nu nog gemaakt van ``way''. Om de ``way'' te converteren naar ``multipolygon'' om zo de sloten structuur duidelijk te maken zoals bij Lexmond doe ik nu a) eerst de ``way'' te knippen in 4 stukken, b) een ``multipolygon'' maken, c) alles omtaggen. Je kunt ook een multipolygon maken met alleen die ene way als lid. Met de multipolygon plugin is dat een toetscombinatie. Als je daarna die way opknipt in stukjes, blijven de opgeknipte delen ook lid van de relatie. Het enige dat dan nog wat extra werk is, is het overbrengen van de tags van de voormalige closed way naar de multipolygon relatie. Als je dat doet, kun je dat het beste doen tussen de 2 stappen die ik hierboven zette. Met CTRL-C + CTRL-SHIFT-V zou je de tags kunnen overbrengen. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] waterweg rond weiland taggen?
On 31-5-2011 10:56, ce-test, qualified testing bv - Gert Gremmen wrote: Leg eens uit wat het voordeel is van een polygoon /multipolygoon voor slootjes ? Nee, want er is niet altijd een voordeel. Ik gaf slechts antwoord op de vraag. Is het dat de grens van weiland/sloot in een way gemaakt kan worden ? Zoiets. Een enkele way getagd als sloot, die dan ook lid is van een relatie van de weide/akker. Dan heb je veel werk, maar geen gedupliceerde ways. Hoe doe je dat dan als er niet overal een slootje ligt ? Dat wordt dan al een stuk lastiger. Ik trek dan ook vaak maar gewoon een extra way met gedeelde nodes voor een slootje. Nu heb ik hier in het uiterste zuidwesten wel een stuk minder sloten dan in sommige andere gebieden van NL, zoals daar bij Lexmond. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] waterweg rond weiland taggen?
On 31-5-2011 19:46, Rick van der Zwet wrote: Heb zoweg de 'stable' (r4064) versie als de development (r4105), krijg ik het niet voor elkaar. Het plakken CTRL-SHIFT-V gaat wel, maar de initiële kopie actie CTRL-C krijg ik niet voor elkaar als de bron ook een multipolygon is. Aha, relatie als bron! Plakken *naar* een relatie lukte tot enkele maanden geleden ook niet, hoor. Dat is toen gewijzigd. Voor 'plakken *vanaf*' zul je dan een verzoek moeten indien op de JOSM bugtracker. http://josm.openstreetmap.de/newticket -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Bridge relation on way going under?
On 28-5-2011 18:46, Tobias Knerr wrote: With a relation, these calculations would not be necessary. The people that come up with these types of relations seem to forget that spatial data is what OSM is all about. For instance, using the osm2pgsql schema: http://www.openstreetmap.org/browse/way/13884500 Which roads/railways/waterways does this bridge cross? select osm_id,highway,railway,waterway,name from ( select l1.osm_id,l1.highway,l1.railway,l1.waterway,l1.name, case when l1.layer ~ E'^-?[[:digit:]]+(\.[[:digit:]]+)?$' then cast (l1.layer as float) else 0 end as crossing_layer, case when l2.layer ~ E'^-?[[:digit:]]+(\.[[:digit:]]+)?$' then cast (l2.layer as float) else 0 end as bridge_layer from planet_osm_line l1, planet_osm_line l2 where ST_Crosses(l2.way, l1.way) and l2.osm_id = 13884500 and (l1.highway is not null or l1.waterway is not null or l1.railway is not null) ) as foo where crossing_layer bridge_layer; osm_id | highway| railway | waterway | name ---+--+-+--+-- 41050723 | | rail| | 98667698 | | rail| | 25933220 | unclassified | | | Ferdinand Perdieusstraat 71890307 | path | | | Brampad 9923332 | | rail| | Lijn 36 107068083 | residential | | | Brandweg 53085949 | cycleway | | | 25806811 | path | | | Tunnelstraat 22903417 | unclassified | | | Brandenstraat (9 rows) Time: 7.328 ms -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Importing csv, good practices and tips : Multipharma Case Study
On 19-5-2011 12:01, Julien Fastré wrote: @Lennard : i didn't know about this test API. Can we use the test api with JOSM ? Yes, change the api url in the config. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] Waterkaarten
Eerste opzet zijn de verkeersscheidingsstelsels en een aantal boeien, later zal ik alle nederlandse boeien (via een rijkswaterstaat bestand) toe gaan voegen. Iemand nog tipstrucs? Check je brondata, check je conversie naar OSM formaat/tags (conversie van RD coordinaten goed gegaan?), visualiseer dit (maak een overlay met jouw data), kondig dat hier aan, op het forum, op de wiki import catalogue, nog een keer checken, neem feedback mee. Dan pas echt importeren. Beter grondig en open. Niets zoveel werk als een foutieve of halve import weer te moeten terugdraaien. :-/ -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Building Equals Yes
By my colleague Aaron Cope: building=yes is a searchable and linkable index of every singleway tagged building=yes in OpenStreetMap (OSM). A web page for every building in OpenStreetMap! Hardly. :-) Lots of buildings are tagged building=something_descriptive_other_than_yes. Other than that: more of this! Nice to see wacky little ideas come to live and be more than a plain text listing of objects. :) -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Uiterlijk van de kaart
On 16-5-2011 19:09, Robert Elsenaar wrote: Dat is natuurlijk precies de Usability waar ik het over had. De openstreetmap.org of .nl is wat betreft jouw bewering Vlees nog Vis. De kaart biedt niet de mogelijkheid om ALLE tags te zien. En iedere Tiles@Home is = die kant op. kaartmaker die zegt dat dat niet kan . daag ik uit om samen met mij Dat kan niet. dit te realiseren. Een sobere basis kaart met een uitgebreide lijst van overlays zou een referentie moeten worden voor iedereen die wil weten wat OSM bezit. En dat is veel meer dan we nu laten zien. Met een OSM draait om data. Niets meer, niets minder. Sommigen maken daar kaarten mee. Enkele van die kaarten zijn zo bekend dat ze direct via de website zijn te zien. Andere kaarten, gemaakt met OSM data, zijn op andere plekken te aanschouwen. Er zijn zelfs sobere kaarten met overlays. Dat is natuurlijk niet hetzelfde als een mooie kaart op zich, bestaande uit 1 laag. dergelijke kaart tool kan iedere OSM’er weer trots zijn. Dit subjectieve argument laat ik even buiten beschouwing. Iedereen gebruikt OSM op zijn eigen manier, voor zijn eigen redenen. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] OSM stats
On 14-5-2011 10:20, eMerzh wrote: Hi, the lenght of osm highway are directly calculated from an osm2pgsql with data from the 12th april. I assume you took the projection into account? Plainly doing ST_Length will sum the projected length of the roads. The real length will be much lower. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-us] Do we want overlaps to be rendered? Or do we want to wait for relation support that may never come?
Or you could simply apply the shields to the geometries created by route relations, greatly simplifying the ref parsing crap. Since the tile server is running Mapnik trunk-ish now, you should be able to use the SVG symbolizers (which should allow you to specify the contents of an SVG using a DB value rather than having separate SVGs for each shield). That's also possible with non-SVG symbols, and I'm not so sure we can dynamically scale SVG symbols based on text size reported by postgresql. However, the osm.org tile server may be running a very recent trunk version of mapnik2, we're not targeting any of the features available in mapnik2 yet. The problem is two-fold: 1) One of the stylesheet developers uses Windows. There is currently no mapnik2 Windows build. I think one of the GSoC projects this summer will be about making a solid Windows build. 2) Switching over the stylesheet and using new features without announcement will mean other tile servers could be falling over left and right. We should give them some notice and time to prepare. I'd love to move to mapnik2 proper, but let's do it the right way. This is not exactly a 0.6-0.7 switch. Lots of dependencies need to be updated as well. Perhaps we need to leave osm.xml as is, and create a clone to move to mapnik2 syntax/features. -- Lennard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Do we want overlaps to be rendered? Or do we want to wait for relation support that may never come?
By the way, we'll always need rendering based on ways as a fallback, unless someone wants to make relations for every rural and suburban street in North Carolina, Virginia, and West Virginia. Another issue here is that we cannot say Hey, we've got a route relation. Let's render only shields for that relation, and not for any member ways, even if those member ways are tagged as routes as well. We either have to render only one of them (relation or ways), or both. Let's also not focus solely on the mapnik map. How's the osmarender support for route relation shields? -- Lennard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Do we want overlaps to be rendered? Or do we want to wait for relation support that may never come?
SELECT name, regexp_split_to_table(ref, '; *') FROM planet_osm_line WHERE ref LIKE '%;%' LIMIT 10; Already tried that 2 years ago. Works fine on the SQL side. You'll only get the first row rendered, though. Mapnik tries to place the 2nd shield at the exact same position, sees that there's a previous shield, and fails. -- Lennard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Skip geographical (redundant) address tags
On 6-5-2011 20:44, Pierre-Alain Dorange wrote: I could not really help you (i don't know your region, but as i can see (using JOSM) there is no admin relation in this area, so few clues to help nomatim to find location. The entire Netherlands is covered by admin relations. Of course, occasionally, these get broken. Also, not every admin_level=10 is there yet. Up to z8 is complete, barring broken data. The municipality is here: http://www.openstreetmap.org/browse/relation/188858 However, we don't have an admin_level=10 relation for the town called Helden, on account of the municipality not giving us their boundaries yet. There's another mapper tracing these from official documents (less accurate than receiving the original geo data, but alas), but he doesn't seem to have done this yet. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skip geographical (redundant) address tags
On 6-5-2011 22:46, Pierre-Alain Dorange wrote: OK, that's the admin relation Nominatim used to link the request street to Peel en Maas. Correct. It's correct, given the data. The real question is why it was also categorised as being in Belgium. I hope you could get them soon. We'd have to send another FOIA request. We used admin_level=8 for municipality and level=10 is almost not used (not in my region) and according to the wiki must be used for suburb‹ in big town. The levels vary by country. In NL level 10 is used for official subparts of municipalities. Even those subparts can consist of more than one dwelling, to make it even more confusing. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Boundary / multipolygon
On 6-5-2011 19:21, Maarten Deen wrote: Wat is het laatste woord over hoe administratieve grenzen in Nederland te taggen? Veel grenzen zijn als multipolygon opgebouwd, maar er zijn er ook als boundary. Ik meen me te herinneren dat er besloten was om multipolygons te gebruiken, maar de wiki [1] spreekt nog altijd van boundary. Ik heb alle gemeentegrenzen ooit allemaal als multipolygon geïmporteerd (indirect dus ook provincie- en rijksgrenzen), en alle resterende niet-gemeentegrenzen omgezet daarnaartoe. Er zijn echter mensen die nieuwe grenzen (voornamelijk woonplaatsen door Eugene) als boundary zijn blijven mappen. Kan niet zoveel kwaad, is wel verwarrend, zoals in jouw geval nu. Ik zet ze weleens om naar multipolygon, als ik toch in de buurt aan grenzen knutsel. Daarnaast is er soms een enkeling die ze juist weer omzet naar type=boundary en verder niets. http://wiki.openstreetmap.org/wiki/WikiProject_Nederland_AdministratieveGrenzen Waar zie jij dan type=boundary op die pagina? Het enige dat er staat* is boundary=administrative en dat is correct, ook voor relaties met type=multipolygon. * Stond. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] Logboek gebied
On 28-4-2011 0:49, filip wolters wrote: Ik heb OWL en ITO eens bekeken. Ofwel kan ik er niet mee werken ofwel vind ik het geen nuttig instrument om mijn ingevoerde data op te volgen. [...] Inderdaad, als je dat er van zou verwachten, dan is het een karige tool. Je kunt wel een RSS feed opzetten, zodat je direct een seintje krijgt als er in een gebied dat je interesse heeft, gewerkt is. Bij ITO kan je filteren op sessions, tags en users maar niet by me en by not me. Dat kan zeker wel. Nergens al je input met wijzigingen, zeker niet in een groter gebied over een langere tijd. Nochtans zou op je persoonlijke pagina bij wijzigingensets zoiets wel te maken moeten zijn door iemand met wat kennis. Ik denk dat ze een uitgewerkte patch met open armen tegemoet zien. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Logboek gebied
Ziet er op zich goed uit, maar ik krijg steeds Data not visible at this zoom level, please zoom in to see stuff. Het is me in 50 pogingen geloof ik één keer gelukt daadwerkelijk in te zoomen. Het is behoorlijk irritant als je geadviseerd/verzocht wordt iets te doen wat je niet kunt doen... Hoe probeer je dan in te zoomen? Het werkt hetzelfde als op de osm.org kaart, bijvoorbeeld. Dubbelklikken, of het de scroll/zoom-elementen linksboven gebruiken, of met shift-dragging. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cell Phones Antennas
On 21-4-2011 22:35, Pol wrote: Ok I will do it. I'll contact them tomorrow and ask them precisely. I'll do my report on that mailing as soon as I have a reply or an answer. Excellent! I hope they're more willing to cooporate than they were to you before. In general, we cannot use any government data in Belgium without explicit permission. Either to any user or to OSM specifically. Ok I wasn't aware of that. It also depends on which part of the government it is. For example: If they publish a law that documents coordinates, we can use it without questions. Any law, decree is fair game, but IANAL. But again, if I had spotted myself those antennas, the problem is still the same ? No. In that case, *you* gathered the data. You can add that to OSM without any issues. It's the same reason we cannot enter street names from other maps, but we can enter street names we mapped ourselves. Also noteworthy is that the map on ibpt.be http://ibpt.be says Door deze site te gebruiken zijn de gebruikers gebonden door de gebruiksvoorwaarden van Google. / En utilisant ce site, les utilisateurs sont tenus par les conditions d'utilisation de Google. So does it changes something ? It shows either of two things: 1) They just included that generic notice without thinking too much about it. 2) They had to include it to be able to show a Google map. Either way, the wording applies to the 'site'. So, please ask them to clarify their position with respect to their data. If they're willing to open up their data, doing it as a separate download, not on the map, is best. It avoids all traces of Google involvement. Also, if you gathered your list of antennas by going over every map popup and writing down the coordinates, you've created a derivative work from Google. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cell Phones Antennas
On 21-4-2011 23:31, Pol wrote: It's not my intention at all, by far !!! I'm a contributor and I want OSM to be the best map for everyone, everyday. We do too. That's why we're so cautious about data and licenses, and why I was so blunt to bring this import to light on this mailing list. Can't wait for tomorrow ! I'll call them and I hope that I'll have the good arguments in my mouth when I'll explain the situation and why we would like to have it on OSM (/which is the hardest part/). Let's hope so. You'll have to think about a reply to their previous argument of 'security'. What exactly is so dangerous about a list of telco towers? As you also said, anyone can create such a list. It only takes a lot of time. If someone wants to sabotage them, they certainly don't need to collect the locations for the entire country. They're also publishing their database on a Google based map. That's not exactly keeping it secret either. :) But, whatever happens, and I do understand why you wanted to import them into OSM, I hope we can talk about this before anyone does an import, next time. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] hack weekend Essen
On 21-4-2011 8:41, Martijn van Exel wrote: Ha allemaal, Van 10-12 juni is er een OSM hack weekend in Essen, net over de grens. Leuk! Dat is vlakbij mij. Ook vanuit Nederland goed te bereiken. Vanuit Roosendaal pak je de stoptrein naar Antwerpen. Na 7 minuten kun je dan uitstappen in Essen. Inderdaad nèt over de grens. :) D'oh! -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] hack weekend Essen
On 21-4-2011 21:19, Frank Steggink wrote: Ik weet niet waar jullie het over hebben. Essen ligt gewoon in Nederland. Het is nl. een gehucht bij Groningen [1]. Wat we daar moeten zoeken, veel te ver weg... Maar dat is niet net over de grens, vanuit talk-nl gezien. Of juist wel natuurlijk. Het is maar net hoe je tegen Groningen aankijkt. ;) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-GB] Things that aren't stations tagged railway=station
Any unambiguous tagging scheme you can think of would be fine. (railway=abandoned_station would also be possible) This variant has the added benefit that it would make it into most current rendering databases for free. Data users that do want to show this, don't have to do anything special to their import stages. Using a key suffix (railway:disused=*) would mean extra work. Granted, as a maintainer of a few maps, I'm biased. I just detest those negating tags. This is a $shazbaz. Oh, no, it isn't! -- Lennard ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-nl] Woonplaatsen, wijken, buurten en admin_levels
On 18-4-2011 9:47, Roeland Douma wrote: Echter als je de hiërarchie wil behouden zou ik een admin_level=12 introduceren en daarvan dan buurten maken. Het slaat natuurlijk nergens We hebben gewoon erg veel onderverdelingen in NL. Nu al een 12 nodig? Poeh he. Een gemeente met stadsdelen kan wel degelijk ook woonplaatsen hebben. De gemeente Amsterdam heeft 2 woonplaatsen (Amsterdam en Amsterdam Zuidoost) en de woonplaats Amsterdam heeft dan weer verschillende stadsdelen. Het leuke(?) aan Amsterdam is dat de woonplaats Amsterdam groter is dan de stadsdelen, maar een lagere orde admin_level heeft in OSM. Hetzelfde speelt overigens ook in Rotterdam. Wat dat betreft hadden we woonplaatsen wellicht beter op 9 moeten hebben en stadsdelen/deelgemeenten op 10. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsen, wijken, buurten en admin_levels
On 18-4-2011 13:39, rob...@elsenaar.info wrote: Roeland, Is dit ook nog een actief project of is deze reeds afgerond? Onze inmenging (het opvragen van woonplaatsbesluiten bij gemeenten en deze daarna invoeren in OSM) is op een erg laag pitje komen te staan, onder andere door het werk aan 3dShapes. Er is nog wel een andere mapper die nog steeds regelmatig woonplaatsgrenzen invoert, maar dit dan zo te zien natekent van plannetjes. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsen, wijken, buurten en admin_levels
On 18-4-2011 23:31, Oliver Heesakkers wrote: Daar ben ik het onmiddellijk mee eens. Het is al erg genoeg dat wij (samen met de Duitsers) een level meer nodig zouden hebben dan de rest van de wereld (waarvan we er dan ook nog eens twee niet gebruiken!) Niet veel landen zijn al zo ver dat ze woonplaatsen (sommigen kennen het concept wellicht niet eens) en buurten doen op dat niveau. Is het een optie om de admin_levels te herschikken? Bijvoorbeeld de gemeente in level 8 te zetten, de rest door te schuiven, zodat de buurten uiteindelijk gewoon in 11 vallen? Gemeenten staan al op 8. [1] Wat vooral belangrijk is, is dat we gelijk blijven optrekken met wat de meeste andere landen doen, zodat gebieden met gelijkwaardige status op gelijkwaardige admin_level's komen. Dit is ook erg belangrijk voor gebruikers van de data, zowel voor analyse als weergave. Zo te zien zitten gemeenten vooral op 8 en 7. Ik vraag me af of je het Duitse Amt op 7 gelijk mag zien als een NL gemeente, qua status? Wellicht zijn plusregio's juist vergelijkbaar met hun Amt? Wat dat betreft hadden we woonplaatsen wellicht beter op 9 moeten hebben en stadsdelen/deelgemeenten op 10. Op het eerste gezicht lijkt me dat een logische wisseling De huidige indeling is voornamelijk ingegeven door het Duitse voorbeeld. Zij hebben stadsdelen/gemeentedelen zonder zelfbestuur op 10. Dat concept is vergelijkbaar met onze woonplaatsen. Dezelfde overweging zorgde ervoor dat stadsdelen *met* zelfbestuur op 9 kwamen. In de praktijk blijkt het bij ons qua grootte net andersom. Als we het in OSM omdraaien, krijg je de rariteit dat een deel zonder zelfbestuur hoger uitkomt dan een deel met zelfbestuur. Moeten we admin_level dus geografisch of functioneel zien? [1] http://wiki.openstreetmap.org/wiki/Admin_level -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] POI's
On 17-4-2011 17:46, Rob wrote: poiexport draait niet op mijndev maar op productie, dat even terzijde.. ik heb helaas alleen lees rechten op die folder.. dit moet Rullzer maar even oppakken Ik heb split al vervangen door explode. Dat is echter niet genoeg. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Veerse Meer
On 15-4-2011 21:58, Robert Elsenaar wrote: Ik voel mij niet in de positie om jouw noeste arbeid in twijfel te trekken. Ik was echter niet in de positie (op het werk) om in JOSm te kijken. Wel zag ik op de map dat het verkeerd was. Bedankt voor het fiksen. Was Tavernses dankbaar voor de reverts? ;-) Geen idee. Het was laat, ik heb geen contact opgenomen. Het was echter een enorme zooi, met vlakken die opgeknipt waren, tags die verplaatst waren (water was opeens gras), het Veerse Meer zelf die geen aaneengesloten buitenste ring vormde, etc. Ook landvlakken langs het water waren op deze manier kapotgeknipt. Geknoei in Potlatch2. De edits (een dozijn changesets) waren klein, maar op deze manier wel destructief. Een quick revert was de effectiefste manier om het op te lossen. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Some tiles not rendering?
Nakor wrote: Thanks for the explanations. So that means that the particular tiles that got rejected because the queue was full could stay due to be rendered forever supposing there are no more changes made to the data they conatin? Not forever, but until such a time that somebody requests the tile again (by looking at it), thereby causing it to be added to the queue again. If the queue isn't full. A change in data they contain will not cause a tile to be added to the rendering queue. Only tiles@home proactively renders every tile that got changed. Tiles that got dropped from the queue are forgotten. They are not rendered later on, when the queue isn't full. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Veerse Meer
On 14-4-2011 22:17, Robert Elsenaar wrote: Is er iets mis gegaan met de 3dShapes import in Zeeland? Het Veerse meer is wel erg wittig. Ik denk dat deze blauw moet zijn. In ieder geval lag er laatst nog water en water is blauw toch? Waarom moet de import nu weer de (vermoedelijke) schuld krijgen? Die import is al van lang geleden, ergens vorig jaar. De huidige drooglegging zal dus niets anders zijn dan een mapper aan het werk. Droogleggingen zijn we ondertussen wel gewend. Kijk maar naar de rivieren rond Dordrecht, die maanden geleden achter elkaar leeg gingen. :) -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Veerse Meer
On 14-4-2011 22:29, Lennard wrote: Die import is al van lang geleden, ergens vorig jaar. De huidige drooglegging zal dus niets anders zijn dan een mapper aan het werk. Zo, gefixt. De enige werkbare methode was het reverten van een berg changesets van Tavernsenses. Het enige dat sneuvelde, zover ik kan zien, zijn wat pieren op de Schutteplaat. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Fietsknooppuntennetwerk Utrecht
Op 12-4-2011 9:01, Foppe Benedictus schreef: Duidelijk! Op de bordjes staat Utrecht, en zo'n netwerk mag kennelijk best groot worden, dus dan wordt/blijft het Utrecht als één netwerk. In contrast daarmee: op de bordjes in Zeeland staat overal 'Fietsroutenetwerk Zeeland'. Dit heb ik in OSM toch onderverdeeld in de 5 netwerken die je logisch ongeveer kunt vormen, maar ook met een schuin oog naar de beschikbare commerciële kaarten. Voor de zekerheid: die kaarten heb ik niet in mijn bezit en ik heb ze ook nooit in handen gehad. Ik weet alleen de titels van die kaarten. Aan de hand daarvan is de verdeling makkelijk te maken. Zo'n onderverdeling is in Zeeland, vanwege de natuurlijke grenzen, een stuk makkelijker te maken dan in Utrecht, waar streken in elkaar overlopen. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Beek
On 9-4-2011 17:35, Robert Elsenaar wrote: Dus ik kan die wateroppervlakte gewoon taggen als: - natutal=water (die weg doen) Nee. - waterway=stream - area=yes Niet nodig. - name=* Zo snappen rederers het ook? Renderers zijn in het algemeen dom en doen precies wat jij ze opdraagt. In dit geval zullen ze dus wellicht een stream langs de omtrek van het water tekenen. Nee dus. Je moet dit analoog zien aan de tagging van river en riverbank. Een lijn (waterway=stream) door een vlak (natural=water). Die lijn kun je dan door het midden trekken, of indien er duidelijk een geul of te volgen koers is (tussen eilandjes door?) verleg je die lijn daarnaartoe. In dit opzicht is waterway=riverbank eigenlijk ook overbodig. Het is toch al een combinatie die verwarrend is. Ik ben bijvoorbeeld al regelmatig waterway=river tegengekomen langs de omtrek van een rivier. Als de water=* tagging doorzet, komt er ook gelijk een einde aan deze onduidelijkheid. Dan wordt het een lijn met waterway=river (voor de stroomgeul) en een vlak met natural=water + water=river. Ik tag rivieren al een tijdje als een natural=water vlak en een waterway=river lijn. Het doel van water=* is om extra informatie toe te voegen over het soort watervlak dat dat is. Aan de rest van de tagging (met uitzondering van riverbank) hoeft niets te veranderen. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Gebruiker Emiel1 - wijzigingingen tbv fietsrouteplanner
On 8-4-2011 16:37, Colin Smale wrote: N.a.v. de suggesties van Martijn en Floris heb ik Emiel1 een PM gestuurd met een vriendelijk verzoek om dit voortaan anders te doen en een overzicht van de getroffen gebieden te geven. Ik ben benieuwd naar de reactie... Je kunt ook Goudappel-Coffeng (bv. in de vorm van Dirk) direct aanspreken. Dan kunnen ze dit meenemen in de instructie naar hun mappers, zodat ze het allemaal goed doen. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Beek
On 8-4-2011 21:54, Robert Elsenaar wrote: De beek loopt echt gewoon door en we willen natuurlijk gewoon dat de beek doorloopt. Hoe los ik dat op? Water is water. Je kunt wel een waterway=* door het natural=water laten lopen. Zie de waterway=* dan als een doorlopende, eventueel benoemde (name=*) weg, en de natural=water (zonder naam) als de omtrek van het water. Sterker nog, zo worden de imports nu gedaan, als het te vervangen water een naam heeft. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Beek
On 8-4-2011 22:58, Robert Elsenaar wrote: Jullie adviseren dan dus om over het watervlak nof een way te tekenen die gelijk getagd wordt als de beek die er ten zuiden loopt? Als die een naam heeft, zeker. Daarnaast is er net een voorstel gedaan om natural=water wat verder uit te specificeren: http://wiki.openstreetmap.org/wiki/Key:water -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
