[OSM-talk-nl] licentie op nieuwekaart.nl
Hi, Slechts ter informatie en om dubbel werk te voorkomen, ik heb op dit moment contact met nieuwekaart.nl aka Nirov voor het correct vermelden van de licentie en de attributie voor de kaart die ze op [1] tonen. Ik heb al de toezegging gehad dat ze dit corrigeren, ik wacht op dit moment nog op de feitelijke wijziging. [1] http://www.kaart.nieuwekaart.nl/?page_id=13 -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers controle
Rejo Zenger wrote: persoonlijk vind ik alleen de nummers interessant dus die voer ik ook alleen in. als een blok van 2a tot 4c loopt vul ik 2-4 in. dat is voor mij meer dan genoeg informatie. Same over here. Wat als iemand op 2b moet zijn, en dat nummer ook invoert in een routeplanner? Moet de router eerst kijken of er een 2b in de data zit, en daarna zelf maar gokken dat het in de buurt van 2 is en je daarheen routen? Dat werkt dus niet (goed) in jouw voorbeeld van 49 vs 49a aan 2 zijdes van een gracht. Andersom, als een router dit doet, is 2b opeens een geldig huisnummer in de routeplanner, hoewel dat nummer fysiek niet hoeft te bestaan. addr:interpolation=alphabetic is niet voor niets hiervoor bedacht, heren. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers controle
Rejo Zenger wrote: Mijn idee daarover was dat de router in eerste instantie kijkt of er een 2b voor de desbetreffende straat bestaat en bij het ontbreken van die definitie gaat kijken naar een 2. De routeplanner in mijn auto werkt inderdaad op nummerranges. Als ik 2b invoer, dan geeft hij bv aan 1...10. Die lijkt dus per wegsegment te werken. Iets dat ook niet onlogisch klinkt voor een unit met beperkte capaciteiten, om met een gereduceerde dataset te werken. Jawel, omdat ik in die gevallen wel degelijk een 49a definieer aan de ene kant van de gracht. Zoals ik net omschreef zou de router dan meteen matchen op de most-specific, te weten de 49a. Ook waar, slecht voorbeeld. Nee, dat klopt. Maar in de praktijk van invoeren van huisnummers kan ik je echter dan nog wel meer voorbeelden noemen. Hoeveel huizen hebben geen of geen herkenbaar huisnummer? Wat doen wij daarmee? Wat doet de router daarmee? Ik kan natuurlijk wat dogma's aandragen, zoals: - tag what's on the ground - tag what you know / can see Geen nummer zichtbaar = geen nummer in OSM kunnen zetten. Dan moeten er andere bronnen aangeboord worden, waarbij deze ook in OSM gebruikt kan worden. Ik *gok* dat er een nummer 70 bestaat, maar het is niet aan de huizen af te zien. Misschien dat dat in de informatie van het kadaster te vinden is, maar ik kan het niet met een survey bepalen. Moet de router melden dat het een ongeldig adres is, of moet hij je gewoon routeren naar het dichstbijzijnde nummer? Ik zou opteren voor het laatste. Al dan niet met een waarschuwing dat het nummer ongedefinieerd is. Als een router inderdaad meldt dat die je naar een plek in de waarschijnlijke omgeving van je gewenste nummer routeert, dan klinkt dit logisch. Dan weet je tenminste dat je ter plekke de oude Mk.1 Eyeball in moet zetten. Yeah, yeah. Je bent erg makkelijk met oplossingen aandragen, zonder de praktische problemen te kennen die ik (en naar ik aan neem ook Floris) steeds tegenkomen in Amsterdam. Je oplossing is in ieder geval niet zo Ik weet het, ik woon niet in van die 'moeilijke' steden. :) Het is zowel een odd als ook een alphabetic. Dit kun je dus alleen correct op te lossen door een 1) een way met housenumber 1-5 en interpolation odd, 2) een node of way met housenumber 7a-7c en interpolation all of alphabetic en 3) een way met housenumber 9-11 en interpolation odd. Zo doe ik het, inderdaad. Ik los dit soort dingen op met een enkele way, housenumber 1-11 en interpolation odd. Schiet gerust. Ik hecht geloof aan 'meer data, indien accuraat'. Als ik jouw probleem moet omschrijven met 3 losse ways/nodes, dan doe ik dat. Indien een routeplanner dat niet goed aankan, of niet aan wil kunnen, dan lost die dat in zijn preprocessing maar op. Voor al deze dingen geldt dat ik open sta voor alternatieve werkwijzes en ik ben bereid om mijn manier van werken aan te passen en zonodig reeds gedaan werk te herzien. Voorwaarde zijn goede argumenten en consensus onder degene die op dit moment actief huisnummers invoeren. Als je argumenten en consensus zoekt, dat moeten we niet binnen talk-nl blijven rondgaan, en ons eigen wereldbeeld creëren. Dan moeten we internationaal deze problemen op tafel gooien. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] licentie op nieuwekaart.nl
++ 26/09/09 14:48 +0200 - Stefan de Konink: Slechts ter informatie en om dubbel werk te voorkomen, ik heb op dit moment contact met nieuwekaart.nl aka Nirov voor het correct vermelden van de licentie en de attributie voor de kaart die ze op [1] tonen. Waarom denk je dat dit OpenStreetMap is? Omdat ze die kaart tonen, ze het verstopt melden en het zelf bevestigen? Voor wat betreft dat tweede, kijk in het menu kaartlagen in de linker onderhoek (je moet daarvoor eerst naar beneden scrollen) en klik bovendien op het i achter de vermelding. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers controle
++ 26/09/09 10:41 +0200 - Lennard: [voorbeeld: huisnummers 1,3,5,7a,7b,7c,9,11] Ik los dit soort dingen op met een enkele way, housenumber 1-11 en interpolation odd. Schiet gerust. Ik hecht geloof aan 'meer data, indien accuraat'. Als ik jouw probleem moet omschrijven met 3 losse ways/nodes, dan doe ik dat. Indien een routeplanner dat niet goed aankan, of niet aan wil kunnen, dan lost die dat in zijn preprocessing maar op. Het is niet alleen een probleem aan de kant van de routeplanner, het is ook een probleem aan de kant van de invoer. Dit, in combinatie met het andere dat je noemde (geen huisnummer aan de gevel zichtbaar is geen huisnummer in OSM) maakt de invoer ineens heel veel complexer. Het betekent in ieder geval dat, bijvoorbeeld op de Kinkerstraat heel veel huisnummers komen te vervallen. Veel winkels hebben domweg geen huisnummer aan de gevel. Datzelfde geldt ook voor de huizen die in vervallen staat zijn, waar bouwactiviteiten of renovaties gebeuren. Daarnaast betekent het ook dat doen van surveys vele malen lastiger worden. Ik zou dan niet alleen mijn best moeten doen om van elke hoekhuis het huisnummer te bepalen, maar van elk huis. Zonder te overdrijven, dat is een gigantische klus. [1] In de praktijk betekent dat dus dat 1) veel nummers die er nu wel in staan op basis van interpolatie komen te vervallen en 2) het een dusdanig tijdrovende klus wordt dat er beperkt vooruitgang zal zijn. Voor al deze dingen geldt dat ik open sta voor alternatieve werkwijzes en ik ben bereid om mijn manier van werken aan te passen en zonodig reeds gedaan werk te herzien. Voorwaarde zijn goede argumenten en consensus onder degene die op dit moment actief huisnummers invoeren. Als je argumenten en consensus zoekt, dat moeten we niet binnen talk-nl blijven rondgaan, en ons eigen wereldbeeld creëren. Dan moeten we internationaal deze problemen op tafel gooien. Uiteraard. Maar ik inventariseer graag eerst vooraf de situatie die wij kennen. Ik wil graag weten wat voor problemen (of juist handigheden) anderen hier tegenkomen, ik wil graag weten hoe wij hier over die problemen denken. Indien nodig leg ik het daarna wel voor aan t...@. [1] Om wat voorbeelden te noemen... er zijn niet alleen huizen waarvan de nummers domweg afwezig zijn, maar er zijn tal van huizen waarvan het bordje niet als zodanig herkenbaar zijn, het nummer is onleesbaar weggewerkt in een gedesigned naambord, het nummer met de hand op de zijkant van een deurpost is geschilderd, het nummer met een Edding op de brievenbus is geschreven, het nummerbordje is overgroeid door een klimplant, [...]. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] licentie op nieuwekaart.nl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rejo Zenger schreef: Slechts ter informatie en om dubbel werk te voorkomen, ik heb op dit moment contact met nieuwekaart.nl aka Nirov voor het correct vermelden van de licentie en de attributie voor de kaart die ze op [1] tonen. Waarom denk je dat dit OpenStreetMap is? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkq+DZgACgkQYH1+F2Rqwn13IwCfT+8rTqeYSzRm5PPMZLgIDKpv i7MAnjZ/xRp1dtH1s+zSxF2C42n+2iKv =u0+f -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] huisnummers controle
++ 24/09/09 22:13 +0200 - Sybren A. Stüvel: - Ligt het aan mij of is het vastleggen van de interpolatie op een een way met op de ene node een 2 en op de andere node een 4 als huisnummer inderdaad gewoon handig? Bovenstaande tool zegt dat interpolatie overbodig is. Lijkt me niet onredelijk. Ik vind van niet, omdat je op die manier kunt zien dat er geen 3 is. Je zou kunnen zeggen dat je dan die way niet nodig hebt, maar ook dan zou er nog in theorie een missende node met huisnummer 3 tussen kunnen zitten. Dit is alleen relevant als zowel de even als de oneven nummers aan dezelfde kant van de straat zitten. Bij addr:interpolation=even zit er dus zowiezo geen 3 tussen. Hoe gaat die tool om met addr:interpolation=all versus addr:interpolation=even? Bij elk van de ways en nodes die ik plaats ga is mijn uitgangspunt dat je aan het object zelf moet kunnen afleiden hoe je het geintepreteerd moet worden. Met andere woorden, als ik op een node een range nummers heb gezet, moet je geen andere nodes of ways in de buurt moeten hoeven te raadplegen om af te leiden hoe de nummer precies loopt. Praktisch voorbeeld: als ik een node 3-5 meegeef, dan moet je op basis van addr:interpolation key op diezelfde node kunnen afleiden dat dat alleen oneven nummers zijn. Implementaties worden denk ik onduidelijk indien voor het bepalen of 4 in die serie thuishoort, andere nodes en/of ways in de buurt geraadpleegt moeten worden. - Iemand op IRC zei me dat een huisnummer aan een building=yes hangt, niet aan een amenity=building_entrance. In de praktijk werkt dat niet voor mij. Ik vind het in principe prima als een huisnummer aan een gebouw hangt, maar ook in de werkelijkheid zit het huisnummerplaatje niet voor niets naast de voordeur op de gevel. Nee, zo eenduidig is dat niet altijd. Ik noemde denk ik in mijn vorige posting al het voorbeeld waarbij dezelfde serie huisnummers aan twee verschillende entrees van het gebouw hangen. Die nummers hangen er dan alleen om aan te geven dat je de appartementen die bij die nummers horen via die ingangen kunt bereiken. Maar goed, ik heb op dat soort punten nog geen goede oplossing kunnen bedenken. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] licentie op nieuwekaart.nl
Het lijkt er ook op dat ze highway=residential niet renderen. 2009/9/26 Stefan de Konink ste...@konink.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rejo Zenger schreef: ++ 26/09/09 14:48 +0200 - Stefan de Konink: Slechts ter informatie en om dubbel werk te voorkomen, ik heb op dit moment contact met nieuwekaart.nl aka Nirov voor het correct vermelden van de licentie en de attributie voor de kaart die ze op [1] tonen. Waarom denk je dat dit OpenStreetMap is? Omdat ze die kaart tonen, ze het verstopt melden en het zelf bevestigen? Voor wat betreft dat tweede, kijk in het menu kaartlagen in de linker onderhoek (je moet daarvoor eerst naar beneden scrollen) en klik bovendien op het i achter de vermelding. Als ze het verstopt melden dan voldoen ze toch aan de voorwaarden ;) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkq+HqAACgkQYH1+F2Rqwn1/ZQCeJsFF4886N4it2UUN3v4xAgX7 9LYAoItmv3vLg5T1koYybkRJ9G6J362m =f1QV -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] licentie op nieuwekaart.nl
++ 26/09/09 16:01 +0200 - Stefan de Konink: Omdat ze die kaart tonen, ze het verstopt melden en het zelf bevestigen? Voor wat betreft dat tweede, kijk in het menu kaartlagen in de linker onderhoek (je moet daarvoor eerst naar beneden scrollen) en klik bovendien op het i achter de vermelding. Als ze het verstopt melden dan voldoen ze toch aan de voorwaarden ;) Hooguit ten dele. Ze voldoen in ieder geval niet aan de voorwaarde met betrekking tot het gelijke delen. Er wordt in de tekst die je te zien krijgt na op het i'tje geklikt te hebben enkel en alleen vermeld dat de kaart met een open licentie beschikbaar is, maar meer niet. Daarnaast, op de kaart zelf staat nu nog maar enkel BY als licentie voorwaarde, niet langer SA (ongeacht of dat nu alleen gaat over de OSM kaart of over hun eigen layers), staat er op die kaart wel prominent Nirov als naamsvermelding en ontbreekt OSM in zijn geheel en staat erop de kaart van Geodan / TDKadaster wel expliciet de naam vermeld van de makers van de kaart. Anyway, ze hebben een en ander zelf ook al bevestigd en aangegeven het te zullen verbeteren. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
