Re: [OSM-talk-be] Uniformiteit van data (was Newbie: Huis vatten)
Zijn ook 2 dingen, gebouw, een garage met een benzinepomp voor. Ik heb dit jaren geleden zo getagt, en jij zegt vandaag nog hetzelfde (operator en brand) dus denk dat we nog goed zitten :) On 2013-10-21 13:02, Marc Gemis wrote: addr:city=Weerde addr:country=BE addr:housenumber=121 addr:postcode=1982 addr:street=Damstraat amenity=fuel brand=Octa+ fuel:1_25=yes fuel:diesel=yes fuel:octane_95=yes fuel:octane_98=yes operator=Sint-Martinus Garage phone=+32 15 611511 tel:%2B32%2015%20611511 source=survey ziet er goed uit. Sommigen zullen dan wel weer zeggen dat de operator feitelijk de name is, maar ja. Je kan toch nooit goed doen voor iedereen :-) ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Newbie : Huis vatten - adressen - UrbIS
We should stick to the current well known scheme, thinking about this renderer issue... it makes no sense to manoevre around a faulty renderer, being it nominatim or a tileserver. If a search for a street + housenumber, city returns nothing, but a search for that same street, city without the number does return fine, who's fault is that? Search engines are suppose to be 'best effort' . The correct behavior should be to drop the housenumber from the search parameters (no exact match is found), and then lower the resolution of the result set to encompass the street (visually). In nominatim that would translate to bunch of hits when searching for an address, when reverse searching for a coordinate that would just return : streetname , postalcode, city, country no housenumber. That proposal ,I mentioned that in a earlier comment already, (to be aware of it's existance) but it's flawed as you noticed. Also, there are 203 occurences in the whole database like this: http://taginfo.openstreetmap.org/keys/addr%3A1%3Ahousenumber Safe to say, it would be a lost effort following this scheme. But also, we would be the only ones using it imho We should just keep tagging the karlsruhe way. Glenn On 2013-10-21 14:40, Marc Gemis wrote: And I'm not the only one: see http://wiki.openstreetmap.org/wiki/Talk:Proposed_Features/Multiple_addresses none of the comments was in favor of this proposal. On Mon, Oct 21, 2013 at 2:38 PM, Marc Gemis marc.ge...@gmail.com mailto:marc.ge...@gmail.com wrote: 2013/10/21 Pierre Parmentier pierrecparment...@gmail.com mailto:pierrecparment...@gmail.com # Proposed Features/Multiple addresses http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses I don't like this proposal too much. This is a relation in disguise. So why not use a real relation instead ? A building relation (which already exists) with multiple address node members. -- I know it's not your proposal, so I won't shoot the messenger :-) This is a mess to maintain if you have to manually make sure that all numbers behind a addr: are there. I would vote against it. m. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] CRAB Import Tool
On 2013-10-21 20:57, Kurt Roeckx wrote: On Mon, Oct 21, 2013 at 08:05:50PM +0200, Ben Abelshausen wrote: I'm also wondering if we want to add some kind of reference to the ID from CRAB. I'm not in favour of keeping external id's in OSM, the address itself should be the id and you cannot rely on it staying on the map because anyone can remove it. I was just thinking about how to keep in sync with their database, and to try and find out which points are mapped and which are not. I'm also considering trying to do a full import and merging existing nodes / houses with their data and things like that. I would actually like to mostly automate importing updates comming from them. I think that at some point we will at least need a way to see see the difference between the 2, and having a direct relation betweem them could make things easier. Yup, you'll need a foreign key if you want to manage that automatically. I aggree. If not you could endup merging the same stuff all over again. Or worse, delete old nodes and create new ones, enlarging the changesets. But I would caution for doing an automagical full import and merge unless you're doing only for the referenced stuff, but new data and merged I would stll want to review it. I've hardly ever had this sort of database migration work at the first attempt Now lets hope someone at CRAB isn't planning on doing the same but in the other direction ;-) , I keep wondering what kind of feedback loop that would create Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Newbie : Huis vatten
On 2013-10-20 13:29, Guy Vanvuchelen wrote: Nog een probleempje. Ik veronderstel dat de hele discussie nu gaat over 'huisnummers'. Dit kan verschillen met 'brievenbus'. Hier in de buurt staan enkele appartementen met één huisnummer maar bijvoorbeeld 8 brievenbussen. Eventueel zijn de brievenbussen genummerd xx/1, xx/2, enz. Dit kan opgelost worden door 8 nodes te plaatsen op het appartement, maar echt mooi (en juist) is dit niet want de brievenbussen zijn in één groot geheel verwerkt. Is er een mogelijkheid om meerdere nummers op 1 huis (of node) te plaatsen? Guy Vanvuchelen Er is niet direct een concensus over dit maar onder de mogelijkheden behoren deze: zet een punt-komma tussen de nummers, een punt-komma is de standaard value afzonderings-teken. Dwz, in alles waar je meerdere values kunt opnemen, ook bv : traffic_sign=BE:C3;BE:TypeIV. Dus dat is steeds een veilige keuze. bv: addr:housenumber=100/1;100/2;100/3 Daarnaast kan je nog werken met een komma, al is dit minder aan te raden, ik hou zelf liever ';' als standaard. bv 11,12,13 Je kan ook een range meegeven bv: addr:housenumber=100-110 Dan kan je doen wat je zelf bijna stelt, een node zetten voor elke huisnummer op de randen van het gebouw. Dus niet in het midden ergens, en individueel taggen. Daarnaast is het best bewust te zijn van een bijkomend voorstel hier (Engels): http://wiki.openstreetmap.org/wiki/Proposed_Features/Multiple_addresses Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Newbie : Huis vatten
On 2013-10-20 20:12, Jo wrote: Mijn voorkeur zou in dat geval uitgaan naar allemaal aparte nodes met elk adres afzonderlijk. Hier heb ik iets gelijkaardigs gedaan: http://www.openstreetmap.org/#map=19/50.88332/4.71530 De bedoeling was om daar op een bepaald ogenblik ook nog bij te zetten welke dienst achter elk van die nummers schuilgaat, maar dat is bij goede intenties gebleven. Ben eigenlijk wel akkoord, ik heb het ook al gemerkt dat nominatim het niet juist indexeert. Ergens wel spijtig want het zou een simpel stukje code zijn om elke individuele nummer te behandelen. Maar zoals steeds mappen we niet voor de renderer :) Ik gebruik die data uit nominatim dagelijks duizenden keer en moet schoorvoetend toegeven dat in dit geval we mss maar voor de render(ers) moeten gaan. Anders gaat er info verloren, je vind geen enkele van die nummers terug in veel gevallen. Hoe de situatie nu is, is het gewoon wel realiteit dat je ze niet op nummer zal terugvinden, tenzij ze afzonderlijke nodes zijn. Maar kwa goeie praktijk best dat je beseft dat de punt-komma normaal die functie uitvoert bij meerdere values. Ik heb ze allemaal al geprobeerd, ranges, individuele nodes Denk dat we voorlopig het bij aparte nodes beter houden. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorstelling
On 2013-10-18 11:37, Verhoeven Fr wrote: Bedankt Glenn en Gilbert voor het snelle antwoord, In feite doe ik wat jullie beschrijven behalve dat ik in plaats van P de in de taakbalk gebruik om te splitsen, maar dat komt op hetzelfde uit, al de eigenschappen blijven voor ieder deel onaangeroerd. Ik heb nu een test gedaan met te saven na het splitten, zonder name verandering en dan heb ik al de Waarschuwing: 'Lid van relatie voor rol platform is van het verkeerde type. Probleem bij verificatie rol(12)' Dat is volgens mij niet door jou uitgevoerd. Save anders je werk en download eens opnieuw om direct te valideren Dat is latijn voor mij. Ik denk dat de buslijn aangelegd werd door PolyglotN Glenn, hoe doet men een validatie juist na het inladen in JOSM? http://josm.openstreetmap.de/wiki/Nl%3AHelp/Dialog/Validator Rechts in JOSM zie je -normaal gezien toch- als de window aanstaat een validator (waar de fouten staan). Daar kan je valideren. Let wel op dat je niets individueel aangeklikt hebt , op mijn platform valideert hij enkel mijn selectie in dat geval. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Beginnend mapper
On 2013-10-17 10:41, cloudspotter.be wrote: Glen, Ok ik zal eens een kijkje nemen naar de map ter hoogte van Groot-Zemst. P Je zal ook wel de progressie zien in het mappen van buildings :) Ik corrigeer regelmatig lelijke huizen, gezet door mezelf in het begin. Let wel op met BING als source te gebruiken, die foto's zijn vaak ouder dan je denkt. Soms verwijderen mensen huizen die niet op BING staan maar wel nieuwbouw is, ik zet regelmatig een comment bij die huizen zodat anderen ze niet wissen. Kijk vooral naar Weerde dan, daar doe ik het meest propere werk. Via Agiv kan je betere achtergrond verkrijgen. Doorzoek ook maar eens de mailing lijst hier van het laatste jaar op 'AGIV'. Voeg een custom WMS toe: http://wms.agiv.be/ogc/wms/omkl? Gewoon auto detectie nemen. Soms moet je expliciet vragen achter de layer beste kwaliteit. Zie ook http://ogc.beta.agiv.be/gdiviewer/?simple=true Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Beginnend mapper
On 2013-10-17 13:24, cloudspotter.be wrote: AGIV, WMS is terminologie die ik momenteel nog niet beheers maar ik maak er probeer er snel werk van te maken. http://nl.wikipedia.org/wiki/Web_Map_Service In principe kan het alles zijn. Agiv is agentschap. Die voorziet in luchtfoto's die het levert via een WMS Service. Grof door de bocht (er zijn ander methods, zoals TMS) gebruiken de meest kaarten het principe van tiles (tegels) te serveren als kaart. WMS en TMS zijn methodes (~ protocols) over hoe je de juiste download zodat je het effect van de kaart krijgt. Simpel gezegd: bij agiv kunt ge nen betere en andere achtergrond vinden dan wat bing geeft. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] OSM Belgium OKFN Belgium
Ben has my support. +1 On 2013-10-17 13:17, Ben Abelshausen wrote: Hello, If everybody agrees we can make this 'official'. Before we do this I would like to give everybody another chance to voice opinions/concerns again about this. Basically this is what is going to happen: - OSM Belgium is NOT going to create a seperate VZW/ASBL but will work under the Open Knowledge Foundation Belgium (OKFN Belgium) umbrella. - OSM Belgium will be represented by Ben Abelshausen. (If there are other candidates please let the list know we can organize a vote, I don't want to do this if our community does not agree) This does NOT exclude us in the future of: - Still becoming a VZW/ASBL for whatever reason. - Becoming a local chapter of OSMF. I think this is a good step forward no? Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorstelling
On 2013-10-17 19:45, Verhoeven Fr wrote: Bedankt Marc, Ik zal proberen mij morgen aan te sluiten maar Hangouts ken ik nog niet. We zien wel. Een concreet probleem waar mee ik last heb: Voor het ogenblik ben ik bezig met het mappen van gebouwen in Heppen, Leopoldsburg. Ik bekijk dan ook de namen van de straten en via de huisnummers waar ze beginnen en eindigen. Daar ontbreken nog tal van straatnamen. Op de N73 (Leopoldsburg- Beringen) loopt de Leopoldsburgsesteenweg in OSM door tot aan het rondpunt aan de kerk van Heppen. In feite is de naam van het deel aan het rondpunt 'Dorpsstraat' volgens AGIV en andere bronnen. Wanneer ik op de hoogte van de Voosstraat de N72 onderbreek en de naam van dat stuk verander krijg ik in JOSM tal van foutmeldingen want op die baan passeren een hoop buslijnen. Hoe los ik dat op en krijg ik die foutmeldingen weg ? Best niet onderbreken maar splitten , je selecteert eerst de way, en klikt dan met ctrl toets ingedrukt de node aan waar je wil splitsen, en dan druk je op 'p'. Het resultaat zijn nu 2 ways met elks dezelfde tags. Het ene stuk pas je de naam aan, het andere laat je zo. Op deze manier behoud je de relaties die die way in zich hebben intact. Het zijn die relaties die je die foutmelding geven hoogstwaarschijnlijk.Beste wat je kan doen is VOOR je aan een stuk begint, na het download van JOSM data, doe direct een validatie, en kijk hoeveel fouten er reeds stonden, want niet alles is veroorzaakt door jouw acties per se. Nadien valideer je opnieuw voor de upload zelf. Komt erop neer: Splitten als functie gebruiken, maar niet manueel opbreken, dat breekt de relaties (zoals buslijnen etc). Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Some questions from a beginner
On 2013-10-17 21:19, marc bessieres wrote: Hello, I'm a beginner mapper. I was at the meeting in Brussels a couple of weeks ago. I'm a foreigner who lives in Brussels, so I want to help mapping here. welcome! I have a couple of questions, if I may ask? No would be kind of a rude answer. 1) In the wiki, for the Project_Belgium I see several external links to tools. Is there any problem to add the ones Marc Gemis showed in his presentation? I just need an account there, or is there a bit more? Please go ahead, the wiki needs a lot of work. 2) What are the recommanded plugins for JOSM to map in Belgium? I can update the wiki with this info too. No typical Belgian plugins yet, but I would recommend : the terracer plugin, building tools. Openstreetbug (which kind of nicely shows that bug in the way you mention once I click it) , notes, mapdust, fixaddresses, turnrestrictions Also: work with mapCSS (check preferences of josm for custom style downloads). 3) I wanted to add my favorite comic books shop, I see only shop:books which would make it. As comics are famous in Belgium, is there something else? I have no idea really... now I want a special tag :) 4) In OSM inspector I see that way_id : 233946835 is reported as error because it has no tags. I see that it is the inside of a school. I thought of creating a multipolygon with the external border and this way as the internal border, is this the right way? The reason is exactly that, it's a way without a tag, e.g. you're not telling what it is. By the looks of this, it's mean as an area. So the very least it should have a area=yes tag on it to valdate.But what is it really ? What is this suppose to represent and why does it have to be a mulipolygon ? It is a big group of questions, I hope this is the right way to interact with the mailing list. Perfect place to do so ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Gebruik layer=-1 voor landuse
Als ik zijn reactie lees dan denk ik : Welk is zijn renderer ? De mijne is mss de zijne niet ... Krijg je die man niet op de lijst ? Glenn On 2013-10-16 10:57, Jan-willem De Bleser wrote: 2013/10/16 Andre Engels andreeng...@gmail.com mailto:andreeng...@gmail.com 2013/10/16 Marc Gemis marc.ge...@gmail.com mailto:marc.ge...@gmail.com Ik kan me ergens wel vinden dat een straat 2 landuses van hetzelfde type niet hoeft te scheiden. De vraag blijft natuurlijk is een straat wel landuse=residential of farmland of ... Ik dacht dat alle renderers een eigen algorithme hadden om de volgorde van landuses te bepalen, dat daarom de layer tag niet nodig is. Dus onderaan bv. residential en erboven village_green. Nooit omgekeerd. Als je natuurlijk een stad in zijn geheel als residential in kleurt en daarbovenop industrial or retail landuse legt heb je die lagen wel nodig. Maar zijn er wel renderers die daar naar kijken. Voor de standaardkaart op openstreetmap.org http://openstreetmap.org lijkt het algoritme te zijn dat het altijd het element met de kleinste oppervlakte toont. Een goede voorbeeld waarom we voor de data mappen, en niet voor de renderer. We kunnen misschien wel uit puzzelen hoe de renderer het nu doet, maar daar zijn geen normen voor en dus kan dat morgen anders zijn. Dat Maarten zegt dat hij het voor het renderen doet vind ik dus volledig fout. Er is wel te discussiëren, vind ik, over of een gebied bijvoorbeeld zowel residentieel als gras zou kunnen zijn. Dan zouden we overlappende areas zonder layer tag kunnen gebruiken, alhoewel ik niet weet hoe dat gerenderd zou moeten worden. Misschien een arcering van de twee kleuren? Cheers, Jw ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] road signs plugin customization
On 2013-10-07 13:01, André Pirard wrote: On 2013-10-06 17:48, Glenn Plas wrote : EN: Hi, I'm in the process of creating a Belgian settings file for this great plug-in. Thanks, but I think that we should first finish Road signs in Belgium http://wiki.openstreetmap.org/wiki/Road_signs_in_Belgium and other parts of the international wiki, otherwise the taggers will have to do the same job twice to revise their work and they won't. I suppose it's a JOSM plugin, but unfortunately most taggers are using Potlatch and this is otherwise a problem by itself. As I said, I'm trying to write a general document about these matters, I'd like to devote most of my time to it rather than participate to more discussions right now. You fail to see the point of the tool, which is only natural when you don't even take a look at it yet judge People spend hours in the wiki to find tags for a sign. Probably the reason why people to do to much traffic_sign entries. This plugin offers a way to intuitively tag a section with those signs in mind, in 2 clicks you can tag a way , read the wiki explainations right inside the tool when you click a familiar road sign. Also a help text, displaying the meaning of certain signs according to the law and my best effort to keep it updated an correct, and tranlated. I'm making it for myself anyway, so I keep my tagging consistent, just offering to share it. The wiki is a maze of deprecated and new pages, I'm so greatful they actually redirect you to -whatever new tagging scheme has been voted by 25 people last week- It's good it is there, but I want to spend quality time in JOSM, not in the wiki. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] your advice please about corrections to tagging instructions
C3 Only destination traffic allowed. Horses, bicycles, pedestrians are always allowed.access=destination access=destination traffic_sign=BE:C3,BE:TypeIV vehicle=no This one is wrong actually, need to drop vehicle key. It's from a failed copy/paste action access=destination traffic_sign=BE:C3,BE:TypeIV ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] OSM Belgian chapter as a Belgian asbl/vzw
On 2013-10-06 09:12, Nicolas Pettiaux wrote: 2013/10/5 Pieter Colpaert pieter.colpa...@okfn.org mailto:pieter.colpa...@okfn.org Hi OSM, With Open Knowledge Foundation Belgium vzw we are building an umbrella organisation for Open Knowledge in Belgium. Creative Commons Belgium is a working group, the iRail initiative has become a working group (Open Transport), we have people working on open source software for open data (We Open Data) and so on. It could save you a lot of time and money setting up a vzw/asbl if you could become a WG at OKFN Belgium. You can get one person of your WG in the board of the legal organisation and help making decisions from the OSM point of view. For the rest, you maintain your own budget, make your own decisions in the working group, and you can keep operating as OSM Belgium. I think the goals of our 2 initiatives are too close not to merge efforts :) Much thanks Pieter. For me, your proposal makes much sense. I am loking forward to the reactions and comments of the other people who want to move forward (Pierre P, Ben A, Julien F) I'm a fan of this evolution, I think it's a great idea. I don't think it really matters where the adress is located, most of us aren't as dumb to look at language borders.I never look at the address of a VZW/ASBL to make up my mind about it.I do think we need to make sure 'we' won't be making too much expenses until the chosen business model proves it's working. I've said it before in the past here : my company is ready to donate resources, we use OSM data every second of the day. A VZW/ASBL would make that donation a tad easier to do (and receive a decent paper trail for our friends at the tax office) So please keep the list informed, especially of the pending needs to get this to happen... if something is missing: share and thou shall receive :P Good stuff! Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] road signs plugin customization
On 2013-10-06 19:15, Ben Laenen wrote: On Sunday 06 October 2013 17:48:05 Glenn Plas wrote: I'm in the process of creating a Belgian settings file for this great plug-in. It would be a perfect tool to distil the common knowledge and tagging habits in our little country. I've done this in the past already (but half-assed ) but it's time to finish the work. See http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RoadSigns for more information Great, but we still need to actually end the discussion on how to tag everything first. Or we'll end up with competing plugins... What plugin ? I know of none that do what this does. I think the tool will help the discussion. I'm just creating our translated/modded version that applies to our road code. It's easy to begin with the basis tags , for instance: access=no , then later when adding subsigns for C3 like uitzgezonderd bus , you need to get creative and check the wiki to find out this would have to be added : key=access:bus value=yes I won't be checking in any files until they are ok. It will sure help beginners to map this, I spend hours in the wiki trying to translate that into the settings. But seriously , End the discussion on how to tag everything ? You have too much spare time :) Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] road signs plugin customization
On 2013-10-06 19:56, Ben Laenen wrote: On Sunday 06 October 2013 19:31:47 Glenn Plas wrote: What plugin ? I know of none that do what this does. I know none exists right now, but if you start making some controversial decisions other plugins can appear. I once tried making a webpage once though where you could just click the signs and it would translate them into pages. It was actually working as well, but it had to use some experimental and self- invented tags to handle the complex access restrictions (like goods vehicles above 5 tons only allowed between 7am and 12pm for loading and unloading). Was actually a tool to think about those complex restrictions rather than Belgian tags. The tagging method for complex restrictions has grown up now and since it's not the same as the one I used, the page is no longer found anywhere. I can still dig it up if someone wants to take a look, it's all javascript and svg and didn't work with Internet Explorer at all :-) Just don't look to hard at it as some things were just wrong... I'll be sticking to the current wiki information, so won't be inventing new tags to cover specials or make it too complex.I just need to stay in the loop with the current tagging habits. . But seriously , End the discussion on how to tag everything ? You have too much spare time :) I know, I've dwelt way too deep into this over the years and the things I could do if I get all those hours discussing back :-) . It's always been one of my goals in OSM to get access tags sorted out in a good and working way. I certainly could have picked an easier topic because everyone has their own ideas and they often are completely incompatible. Ranging from: tag everything explicitely, all the way to: don't tag anything with access tags, just tag what signs there are and let some tools do the translation. I've not given up yet. But even if it never leads to a result, I certainly learned a lot about our traffic code :-) Ben That last sentence sounds very familiar, it's an amazing maze ... very SM'ish of us isn't it :) I think what this tool produces in tags isn't too controversial anyway. I'm just mapping the wiki knowledge in the settings file for Belgium, it sure saves time looking up things you haven't tagged in the last 6 months. The latest discusssion was about a wrong C3 sign in combination with the road, so this plugin won't help anyway. Maybe we can finally tag this road in the Walloon region when I'm done: https://www.youtube.com/watch?v=ktkb9soWl90 don't laugh, it's our money wasted Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Verbodsbord C3
On 2013-10-01 21:06, Guy Vanvuchelen wrote: De honderden fietsers die van knooppunt tot knooppunt fietsen gaan nogal lachen met de gebruikers van Openstreetmap omdat die niet mogen doorrijden! We maken ons echt belachelijk. Misschien was het correct mappen er de oorzaak van dat ik onlangs niet van knooppunt A naar B kon maar een omweg van 16 km moest maken via 3 andere knooppunten. Guy Vanvuchelen -Oorspronkelijk bericht- Van: Ben Laenen [mailto:benlae...@gmail.com] Verzonden: dinsdag 1 oktober 2013 20:03 Aan: talk-be@openstreetmap.org Onderwerp: Re: [OSM-talk-be] Verbodsbord C3 On Tuesday 01 October 2013 10:38:41 Stijn Rombauts wrote: Goed, concrete antwoorden: Tag wat er in het echt staat, niet wat je denkt dat er in het echt zou moeten staan. Staat er een C3 zonder onderbord: vehicle=no (of iets als highway=path gebruiken) +1 Staat er een C3 met uitgezonderd plaatselijk verkeer: access=destination (en dat laat ook fietsers toe) +1 En, als je de way in kwestie wil taggen met de betekenis van dat bord, zoals ik eerder zei (maar dan versie met onderbord): access : destination en traffic_sign=BE:C3 want dat staat er in het echt. En dat laat toe dat de fietser in OSM erdoor mag. En over dat onderbord , dat ontbreekt wel in de realiteit, ik denk dat je dus tegen het verkeerde koor staat te preken, Het is wel de wegbeheerder van die gemeente waar je eigenlijk uw verhaal kwijt moet, want die kunnen de echte fout oplossen door zo'n blauw plakaat met witte randen eronder te hangen. Ik stel maar wat voor. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Verbodsbord C3
On 2013-09-30 14:36, Guy Vanvuchelen wrote: Regelmatig kom ik op wandelingen het bord C3 tegen. Een rond wit bord met rode rand. Verboden toeging in BEIDE richtingen, voor iedere bestuurder. Onderborden zijn mogelijk. Dikwijls staat er een onderbord Uitgezonderd fietsers (bromfietsen A) De laatste dagen zie ik regelmatig het bord C3, zonder onderbord, terwijl er toch een fietsroute aangeduid is. (knooppunten of toeristische route). In principe mag dus de fietser niet door want hij is een 'bestuurder' maar anderzijds loopt er wel een officiële fietsweg. Hoe moet dit gemapt worden. access: no ; eventueel 'designated' als er uitgezonderd plaatselijk verkeer onder staat. bycicle: ?? Logisch is het bycicle: yes; maar correct zou zijn bycicle: no! Je kan 2 dingen doen : het bord loggen of de restrictie op de way. Bord C3 heeft altijd een tegenhanger, wordt altijd afgesloten aan alle invalswegen(in theorie). Voor routers is de way taggen veell bruikbaarder dan de plaats van een bord. voor deze kan je(met onderbord) : de way taggen met: access : destination en traffic_sign=BE:C3,BE:Type-IV Die traffic_sign is informatie die al paar jaar meegaat. de Type-IV is : plaatselijk verkeer onderbord. Er zijn ook andere Type's, maar deze ga je het meeste vinden. Er is geen verdere onderverdeling voor dit onderbord. En zo staat het in de wegcode, bitter weinig dus. Als je het zo doet zal de way ook gearceeerd worden visueel in OSM. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Deelgemeentes en AGIV/CRAB
On 2013-09-25 19:01, Marc Gemis wrote: This is triggered by the note on OSM http://osm.org/go/0EpKQJ4xd- It requests that Muizen (part of Mechelen) is indicated. Muizen is already on the map, a few kilometers to the east. Marc, I'm from this area, I know it well. Muizen's borders aren't too far away from that location. The centre is indeed a few km off. Zoom out a little, move some to the right you'll see the Planckendael domain, which is muizen for sure. You also see the muizenstraat below (although that's right on the mechelen/hofstade border, that street is hofstade , I'm pretty sure, I surveyed that area by car long time ago to test GPS units), it might be partially Mechelen (not sure) that street (by heart). But I'm also pretty sure that everthing south of 'Leuvense vaart' is definitely not muizen. (but parts of it might be mechelen, depending on where you stand) Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
On 2013-09-19 11:37, Marc Gemis wrote: Hallo Jean=Louis, access=no means that nobody has the right to go on the path, not that it is not possible. Indeed, access=no is a different context. You might also want to check out this tag: http://wiki.openstreetmap.org/wiki/Key:smoothness Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
On 2013-09-19 12:31, Glenn Plas wrote: On 2013-09-19 11:37, Marc Gemis wrote: access=no means that nobody has the right to go on the path, not that it is not possible. Indeed, access=no is a different context. You might also want to check out this tag: http://wiki.openstreetmap.org/wiki/Key:smoothness To be more complete, this tag has been under scrutiny lately, and other proposals exist. Just follow the hotlinks. There is another proposal here: http://wiki.openstreetmap.org/wiki/Proposed_features/surface_unification#surface:condition Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] [Sentier disparu par cause de vegetation]
On 2013-09-19 14:22, Jean-Louis Stanus wrote: Ik ga akkord met je glenn dus ik gebruik dat: no highway key maar alleen deze: designation=public_footpath dank u alles Bonjour Jean-Louis, Je croix que sans 'highway key' c'est une erreur, le plus correct est de le garder et en plus, ajoute l'autre cle (alors ce n'est pas une replacement mais ajoutement). En faite, c'est encore une 'highway' , meme si il n'est pas physiquement accessible... Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Imports in the North of the province of Antwerp
On 2013-09-18 05:59, Marc Gemis wrote: In the North of the province of Antwerp (north of Hoogstraten), you'll find a lot of buildings that were imported by 3d shapes. Almost none of them seems to match with the AGIV photos. The buildings are to small, to big, rotated, have the wrong shape, there are phantom buildings as well. Pretty enoying A lot of work has to be done there. Another thing I noticed is that someone indicates each church tower as man_made=tower. An example is http://www.openstreetmap.org/browse/node/2388544510 Is this correct tagging ? What do we want ? Don't think it is wrong, looking at this building in google streetview, there is a tower that matches the wiki definition: ' A tower is a building, which is multiple times higher than its diameter. It can stand alone or as a part of a bigger building. Towers can be built from wood, steel or concrete.' But it could have been done better by adding : tower:type=bell_tower if it has bells (which by the looks of it it does). I find the placement a bit odd (a node on the corner ?). It's not common to do so however, it's not wrong. It's been done by a dutch national, so that would explain perhaps the different habit. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Imports in the North of the province of Antwerp
I must have missed the as part of a bigger building. before. I thought it was only used on stand alone constructions. I did not move the node yet. It is still at the position of the import. I'll move it and add the bell_tower tower type. I share your sentiment, when I think of man_made=tower, I think cooling towers, big antenna towers etc. It would not be something I would have done personally. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] fietsknooppunten
On 2013-09-16 09:04, Marc Gemis wrote: De Engelse tekst gaat er inderdaad over dat Navtec OSM wil gaan gebruiken voor auto navigatie. Steve Coast is daar nu gaan werken (dat is de oprichter van OSM), hij heeft Microsoft/Bing dus verlaten. Dat gaat wel een dikke boost worden om OSM in consumer devices te krijgen! Onbenoemde wegen kan je nog met een overpass query of een andere tool (Keepright e.d.) vinden. De andere ontbrekende data niet. Je kan er ook moeilijk gericht een survey voor gaan doen. Ik probeer dat zoveel mogelijk mee te nemen met de andere dingen. Ik doe het vooral via mapCSS om die wegen zonder naam te vinden: http://josm.openstreetmap.de/wiki/Styles 'Streets have no name' zoeken. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] mailing list good practice
On 2013-09-16 11:15, Pierre Parmentier wrote: Hello, I find the link to gigaom.com http://gigaom.com article very interresting. Thank you Marc. May I suggest: * to adapt the subject of our messages to the topic: fietsknooppunten is no more related to the new theme. It is quite easier to retrieve some items a few weeks later ... * to delete the sections of previous messages (history) when they are no more necessary. Best regards. EN: If you want to be serious about this then a new topic should be initiated by sending a new mail instead of a reply with a new subject. Every decent mailclient out there -usually- does not use the subject to 'thread' mails. instead it uses certain fields in the mail headers. I noticed that mail-man (the mailing list handler of THIS list) does not seem to add those headers (in fact, they seem to be removed from outgoing mails, I cannot find those fields like below). example of those are : References: 20130914070031.83C7A1561AD6@server21 CANHB50fV+JQ_DYnu91QYaURcRyAKk-pqbHGFMQmYzQZAeC=x...@mail.gmail.com 5236af60.2050...@byte-consult.be In-Reply-To: 5236af60.2050...@byte-consult.be This is what the (E)mailers usually use when exchanging mail correspondence (non mailing list) when hitting 'Reply' To be complete: top-posting (putting comments ABOVE the previous messages) is usually really a big nono in the mailing list fields. You should put follow-up comments BELOW the original mail. Personally, It doesn't bother me too much, but on plenty of mailing lists people go absolutely nuts over that fact , more true on long email exchanges, as you need to read a long reply from bottom to top in order to follow the conversation. Of course many clients let you sort using the subject field. If you make sure to bottom-post, automatically you'll be removing the non-relevant sections at the top to compact the response. I admit , when being too quick, I'm a sinner too against that rule once in a while. Some lists have their own requirements, but in general bottom-posting is considered Netiquette, top-posting isn't. It makes you scroll twice to follow a conversation. (go down to find the start, then read up). English : http://en.wikipedia.org/wiki/Posting_style NL: In usenet(nieuws)groepen wordt er altijd op gehamerd de antwoorden als bottomposting toe te voegen en daar houdt iedereen zich voor 95% aan, dus daar wordt het erg verwarrend als plotseling mensen gaan topposten want dan gaat bij antwoorden op antwoorden op antwoorden de volgorde de mist in en wordt het totaal van het bericht nauwelijks meer te lezen. Op usenet is het topposten zeer ongewenst en citeer je alleen het relevante deel voor de reactie. Op die wijze hoeft de lezer niet steeds terug te grijpen naar de vorige posts, maar blijven de posts ook kort. Normaal zouden de meeste posts binnen één scherm moeten kunnen passen. Als je de general OSM mailing list even bekijkt dan zie je dat praktisch iedereen bottom-posts doet op relevante secties. Mensen zoals ik, die vele nieuwsgroepen volgen vinden threaded views zeer onoverzichtelijk omdat je dan je steeds weer moet orienteren op de conversatie die daar voor heeft plaatsgevonden. Het is veel efficienter om alles wat nodig is te lezen in de normale leesvolgorde onder elkaar staat binnen hetzelfde bericht. Voorwaarde blijft natuurlijk altijd dat de poster uitsluitend dat quote waar hij/zij op reageert... And last but not least: Gebruikt geen HTML mail... nooit Mijn 2Eurocentjes netetiquette Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] mailing list good practice
On 2013-09-16 11:52, Glenn Plas wrote: And last but not least: Gebruikt geen HTML mail... nooit Zucht/Facepalm ... Dan krijg je dus wat er met mijn vorige boodschap is gebeurd, omdat Pierre zijn initiële boodschap in HTML heeft verstuurd neemt Thunderbird dit over in de reply (ik was zo dom zelf een reply te doen en enkel het subject aan te passen), met als gevolg dat een deel van mijn reply op zijn beurt in HTML doorkomt. Zeer lastige kettingreactie ... vanaf het minste HTML in de bron boodschap krijg je dus een resem HTML mails op de reply. waardoor ik mijn instellingen kan gaan nakijken om dit aan te passen op de verse laptop .. Het zijn simpele richtlijnen/regels maar je zondigt er echt snel tegen voor je het zelf door hebt dus. (autodetect afgezet in options-format- Plain text) Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] mailing list good practice
On 2013-09-16 13:06, Marc Gemis wrote: On Mon, Sep 16, 2013 at 11:52 AM, Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be wrote: To be complete: top-posting (putting comments ABOVE the previous messages) is usually really a big nono in the mailing list fields. You should put follow-up comments BELOW the original mail. Personally, It doesn't bother me too much, but on plenty of mailing lists people go absolutely nuts over that fact , more true on long email exchanges, as you need to read a long reply from bottom to top in order to follow the conversation. Of course many clients let you sort using the subject field. Please inform Google about this, as with Reply, it hides the original message behind 3 dots at the bottom of the mail. :-/ :-) It looks like you're doing fine on this message though :) It's probably because when replying to 'regular' emails (since a mailing list isn't USENET) the consensus is to top-post. I do this too with daily mail exchanges. But it's good that you mention this fact, so we understand better where habits like this comes from. I'm not a gmail user, although I have a gmail account, it's a spambox for me :) Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] fietsknooppunten
On 2013-09-16 13:00, Guy Vanvuchelen wrote: Spijtig dat dan ook kleine paadjes, die dikwijls geen naam hebben, weergegeven worden Guy Vanvuchelen Dat zou gemakkelijk op te lossen zijn door deze uit te sluiten voor bepaalde highway tags, persoonlijk vind ik het wel handig want vrij recentelijk hebben ze overal op de wandelwegen de officiële namen gezet van de 'kerkwegjes' in de buurt, dus is dit voor mij ook relevant om ze te zien en ze te taggen. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] mailing list good practice
Those headers are there. They're not there on mail you replied to because he actually started a new thread, and your mail client should have shown that. Yup you're right, found out later why, just didn't think it was worth spamming another one to the list and keep the focus, it was a tangent anyway. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] mailing list good practice (user's and software's)
On 2013-09-17 01:02, André Pirard wrote: On 2013-09-16 11:52, Glenn Plas wrote : If you want to be serious about this then a new topic should be initiated by sending a new mail instead of a reply with a new subject. Every decent mailclient out there -usually- does not use the subject to 'thread' mails. instead it uses certain fields in the mail headers. I noticed that mail-man (the mailing list handler of THIS list) does not seem to add those headers (in fact, they seem to be removed from outgoing mails, I cannot find those fields like below). You're right, my main gripe is against the mailing list software mailman itself because it does not allow HTML. It does archive a HTML version of the archive but when you look at it on the server you see HTML code. By allow HTML, I mean simple HTML: text style, lists, tables etc, not eccentric showy stuff. I've sent an e-mail to mailman about this and they replied * that we, technical people, do not need HTML because we don't use it much. I think you misunderstood my mail. At the very bottom of that partly quoted mail I stated : Never use HTML mail. I am very much against using html in mails. I believe HTML belongs on a website, not a mail. I prefer plain-text.. Sorry :) Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] fietsknooppunten
On 2013-09-14 13:06, Jo wrote: Het is lijkt inderdaad meer en meer op onbegonnen werk. Anderzijds zijn we vertrokken van een leeg canvas en kijk waar we nu staan. Mappers zullen er altijd te weinig zijn. Ik zie meer het heil in automatisatie om aan kwaliteitscontrole te doen, maar dan krijg je in bepaalde gevallen de DWG tegen... En het helpt dan natuurlijk enorm als je data van de bron hebt om mee te gaan vergelijken. Grappig genoeg krijg je soms het effect van: als we de toestemming hebben om het van de bron te gebruiken, waarom hoeven we het dan nog aan OSM toe te voegen? In ieder geval zou het enorm helpen als we toestemming zouden kunnen krijgen van de provinciale toeristische diensten om hun updates ook te verwerken. Maar zolang ze iets tegen de mogelijkheid om af te drukken hebben, zal dat waarschijnlijk niet gebeuren. Dus blijven we afhankelijk van mensen die anomalieën vaststellen in 'the field' en dan ofwel zelf aanpassen of melden, zodat iemand anders het kan aanpassen. En er zijn dan ook nog wel mensen zoals mezelf, die graag met Overpass API spelen en die 'en bulk' fixes aanbrengen via scripts + JOSM werk. Dat is zo'n beetje mijn dada van het laatste jaar, ik haal veel voldoening uit het feit van bv alle Dexia kantoren naar Belfius om te zetten. Dus probeer een open en brede geest hierover te houden, het werk zal nooit gedaan zijn aangezien de situatie in het veld ook van uit nature een dynamisch gegeven is . Beeld u maar eens in wat een bedrijf als Google aan resources daar moet tegengooien... Ik doe dat heel graag, mijn laatste 50 edits zijn praktisch allemaal fixes van fouten die ik via bepaalde web applicaties naar voor zie komen, die gemaakt zijn om de dingen te controleren. Alle fouten die ik kan fixen maak ik. Dus geen paniek, hoemeer fouten ik vind , des te beter ik mezelf ga voelen als ik ze rechtzet :) Je moet proberen om fouten bij de bron aan te pakken, maar openstreetmaps setup zit geweldig goed in elkaar, zeker als fouten consequent gemaakt worden is het een peulschil om dit automatisch te fixen. Misschien niet van toepassing direct op knooppunten maar er is oneindig veel verbeterwerk. En net dat vind ik gewoon leuk, beetje online sado-maso zeg maar... Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] transfer of osm.be
On 2013-09-13 10:45, Nicolas Pettiaux wrote: good news. How do we proceed now ? Check out this link: http://dns.be/nl/domeinnaam/beheer/overdragen Someone will have to 'own' and pay it of course, preferably a VZW if it exists. (that vzw will have to be sponsored of course) Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] transfer of osm.be
On 2013-09-13 12:11, Julien Fastré wrote: - earn money with banners / donate functions I think we should not place banners on such a website. I don't like banners, I don't like ads... :) But I am ready for donation. Julien Totally aggree, if the road to getting this site online has adds and banners on the way, then count me out. It goes against the very principle of being independant and non-commercial , open data . Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] transfer of osm.be
Nice start, Any chance you could make this a responsive design. I think it's rather important this opens up on all sorts of devices, I noticed that many of my friends do not own a computer anymore at home and use pads and smartphones: See the result here: http://www.responsinator.com/?url=http%3A%2F%2F14k.be%2F%3Flanguage%3Dnl It would look much better to, nomatter what the screensize is. Next, to comment on the fact, do you need a VZW, I think you do. Image the person owning the domain dies in a car accident or get eaten by zombies, then there is a big access problem in getting the control of the domain. That would be the main reason for me do put an organisation in between this.finally, there is no way you can get a VZW in place before october, so I would not wait for it. my 2eurocents. Glenn ps: check http://www.initializr.com/ for reponsive design info and reference templates. I already have basic website running: http://14k.be/?language=nl http://14k.be/?language=fr ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] transfer of osm.be
Hey Ben, I'm sorry, looks like it is pretty much responsive when I look deeper, but there are some issues primarily on the iPhone it seems, the horizontal scroll bar is not optimized. I should have taken a better look before mailing this. For a work in progress it's on the right track. Glenn On 2013-09-13 14:28, Glenn Plas wrote: Nice start, Any chance you could make this a responsive design. I think it's rather important this opens up on all sorts of devices, I noticed that many of my friends do not own a computer anymore at home and use pads and smartphones: See the result here: http://www.responsinator.com/?url=http%3A%2F%2F14k.be%2F%3Flanguage%3Dnl It would look much better to, nomatter what the screensize is. Next, to comment on the fact, do you need a VZW, I think you do. Image the person owning the domain dies in a car accident or get eaten by zombies, then there is a big access problem in getting the control of the domain. That would be the main reason for me do put an organisation in between this.finally, there is no way you can get a VZW in place before october, so I would not wait for it. my 2eurocents. Glenn ps: check http://www.initializr.com/ for reponsive design info and reference templates. I already have basic website running: http://14k.be/?language=nl http://14k.be/?language=fr ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] transfer of osm.be
On 2013-09-13 14:47, Ben Abelshausen wrote: I specifically tried to use a responsive design theme from the beginning... :-) Not sure if everything is as it should be. I tried it on android and windows phone. No iPhones here http://www.responsinator.com/?url=http%3A%2F%2F14k.be%2F%3Flanguage%3Dnl It works good, results are accurate from what I've seen in real. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Fietsknooppunt verplaatst
Overal nakijken dat je een continue rij ways in de RE hebt. Zoniet sorteren. Daar is ook een icoonknopje voor. Dat sorteren werkt wel voor routerelaties (toch als ze geen 'tentakels' hebben), maar niet voor networkrelaties. Ik heb het niet doorgestuurd naar de server. Het is een eenvoudig knooppunt, dus een goede plaats om mee te oefenen. En je hebt gelijk, het KP is wel degelijk verplaatst, zo blijkt toch uit de data van Toerisme Vlaanderen die we niet mogen gebruiken, maar die wel van pas kan komen als 'second opinion', als het daarnaast ook in the field is vastgesteld. Kleine waarschuwing, let op met het sorteren van ways. Als je een complexe relatie editeert, zoals bv : http://www.openstreetmap.org/browse/relation/20688 De 8 van zemst, dit is een fietsroute die in een 8 - vorm gaat waarvan een aantal ways 2 keer wordt gebruikt. De sorter gaat hier serieus scheef op, het heeft me al veel tijd gekost om deze te fixen manueel dan. Ik denk dat het nu wel ok is, al ziet het er niet echt ok uit, ze zijn wel degelijk verbonden in een 8-vorm. Dus altijd gezond verstand gebruiken en de resultaten van het sorteren goed nakijken. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
Comments inline: On 2013-09-11 05:44, Marc Gemis wrote: I believe that there was a blog post on Coding Error that stackoverflow got most traffic via google search. Google is the dominant search engine, whether we like it or not. Anyhow, Search Engine Optimization (SEO) is something you cannot neglect as a business. But the domain name is not that relevant imho. I'm pretty much on top of that subject professionally, try to follow me on this: when you have the same pages on different domains, your domains will compete with eachother as they are exactly the same, if you don't redirect correctly. Hence why I mention to do this the right way as I see it too many times that people buy every domain they can think of. Next to that google will crawl every domain seperately as it has no idea it's the same, so your traffic will grow exponentially. On a static site, that is usually not an issue, but once you go drupal/wordpress/joomla/etc... your server will get hits. I've had this happen to huge customers (agenda.nieuwsblad.be for example). The servers that do this where dying just because crawlers had a free pass, everyone came by, Russian, Chinese , Google , Bing, fake google bots, bots not respecting your robots.txt, etc etc ... this accounted for more than 60% of the traffic, those numbers went into the terrabytes monthly. So by just limiting and holding google's hand instead of buying new servers as the customer planned, this platform is now doing almost nothing and analytics do not suffer. Here is a site explaining this in more detail: http://www.k2seo.com/competing-with-yourself/ Search for rent a room in new york and the top hit is airbnb.com http://airbnb.com . No room, rent nor NY in the name. Content, metatag, links from other sites, url of pages etc. all play a role. Google only give hints on what their algorithm uses, all the rest are guesses. I fail to see the point of the statement in this context. My point was sending a warning to pay attention to multiple sites serving the exact same content (alias domains). I would also stick the to naming convention used in the other countries so openstreetmap.be http://openstreetmap.be (there are e.g. openstreetmap.nl http://openstreetmap.nl, openstreetmap.fr http://openstreetmap.fr, openstreetmap.de http://openstreetmap.de ) Also what technology are they using for their sites ? Their communities (especially the German one) are larger and they might develop reusable components, that can be used on other sites. And what is the main openstreetmap.org http://openstreetmap.org using (read it somewhere but forgot it) openstreetmaps.org uses Ruby on Rails, the code is available here : https://github.com/openstreetmap/openstreetmap-website Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
On 2013-09-11 11:16, Jo wrote: In Brussel zijn we dus ook alle adressen aan het toevoegen, maar wat ons betreft is die data dan nog niet compleet, ook al kunnen we er daar de gebouwcontouren aan toevoegen. Het wordt pas echt interessant als je ook weet welke POI op dat adres/die locatie aanwezig zijn en daarvoor kan je toch best ter plaatse een bezoekje brengen. Mijn manier van werken zal dus waarschijnlijk worden om die AGIV-adresdata als extra informatiebron te gaan gebruiken, naast de luchtfoto's, eigen foto's en surveyresultaten. Ik denk niet dat 'k eraan ga beginnen om ze in bulk toe te voegen, behalve als een straat nagenoeg compleet is, misschien. I have to aggree , I've pondered over automatic imports a lot by compairing OSM to AGIV and there are so many differences (buildings in particular) that I came to the conclusion that we should do this manually, by humans. In my village alone (a few 1000 houses - tops) It took me so much time compairing different datasets. I believe AGIV has more accurate buildings, but data in OSM from field work is also valuable that you just cannot destroy those by blindly importing another source. Maybe we could set up a system like the Cameroon thing, where you assign yourself a grid to work in. I cannot find the url back immediately but that system sure works and I believe the source of the webpage that manages the grids is available on github too. Ben, can you help me on this link? Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
On 2013-09-11 13:25, Ben Abelshausen wrote: Do you mean the osm tasking manager? http://tasks.hotosm.org I already helped create a small fix to allow JOSM to load extra data per square and merge it with OSM-data. Something we did for the central african republic. I was thinking of repeating this for AGIV but the french already have something like this for addresses. (at least that's what they told me at state of the map) Met vriendelijke groeten, Best regards, Ben Abelshausen Yup, that is the one... I like that approach, loosely coupled so not many constraints. It would help dividing the country (like it needs more division) and manage the spread of the work. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On 2013-09-11 17:53, Ivo De Broeck wrote: Hmm I only can say, that I have build a small website about Kinderyoga Re-born in Duffel. When I ask google Kinderyoga Duffel, this are the results: - first payed advertises (gray) then Gouden gids then the site Re-born your results don't need to match mine, and that is because you are living in a search bubble (we probably all do), unless you anonymise your browser, you WILL be a victim of this technique. That is the reason when you tell someone verbally : The 3rd result in google is the link I mean and that persons says: That's a different link here and then everyone is confused. So keep this in mind when trying to get points across, SEO is one side of the search services. The other side is user profiling, data mining and highly focused marketing. In your example the 'in' word is also ignored btw. If you want to get out of the bubble: http://dontbubble.us/ Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
2013/9/10 Jo winfi...@gmail.com mailto:winfi...@gmail.com Lodde is inderdaad bijzonder actief, maar spijtig genoeg blijkbaar eerder een Einzelgänger. Ik zou gewoon herstellen wat hij heeft aangepast in z'n ijver, met een boodschap in de history dat je zijn edits hebt moeten verbeteren. Hij heeft op mijn boodschappen ook nooit gereageerd, maar dat waren gewoonlijk open ended uitnodigingen voor mapping parties e.d. Ik denk dat je DWG pas moet inschakelen als blijkt dat er inderdaad sprake is van een 'edit war'. Anderzijds is het natuurlijk niet leuk om je tijd in bijdragen aan het project te steken, als dat door iemand anders weer ongedaan gemaakt kan worden. Spijtig genoeg is dat de aard van het beestje en het enige dat je daartegen kan doen, is het gebied waarin je werkt monitoren met tools zoals owl. Als het problemen blijft geven, kunnen we natuurlijk wel met z'n allen 's proberen om Lodde te contacteren. Het beste lijkt het mij als we hem kunnen betrekken bij een echte meer persoonlijke bijeenkomst. Het helpt enorm als iedereen zich realiseert dat we allemaal samen iets proberen op te bouwen en dat we elkaar ook 's als persoon ontmoeten, al vraagt dat wel nogal een grote inspanning. mvg, Ha de Lodde Zelfde gedachte hier: ik had direct 2 namen in men hoofd, waarvan hij eentje was, louter door de omschrijving van de situatie zegt genoeg eigenlijk. Het is idd zeer storend dat mensen op oud kaartmateriaal en beperkte kennis ter zaken gaan editen, het gebeurd in mijn streek ook regelmatig dat er een nieuw huis verdwijnt omdat iemand denkt dat Bing live beelden zijn ipv 3 jaar oud. Voor buildings en werven zet ik meestal direct de juiste 'under construction' tags zodat het opvalt. Het voordeel van deze users is dat ze overal werken, en meestal hun changes niet meer nakijken nadien (done that , got the T-shirt). Het is meestal een fervente wandelaar of fietser, maar de kans is groot dat Lodde een huismapper is die niet buitenkomt. Zijn werk stikt van de fouten, en ik ben zelf niet overtuigd dat veel werk leveren -maar slecht- met de mantel der liefde behandeld wordt. Zijn changesets die echt fout zijn zouden moeten teruggerold worden. Vergeet niet dat zo'n users (waarvan deze thread getuigt) veel energie en resources van de rest vragen, dus ik zou het niet op 'zijn vlaams' regelen. Wat betreft zijn mails is het wss iemand die via een google account inlogt (zoals ikzelf ook), waardoor de mails in een mailbox eindigen die nooit wordt gelezen. De enige manier is uw changesets taggen met doorspekte comments en proberen een reactie te provoceren , bv. : Fixing dumb mistakes made by XYZ , previous edits made by XYZ do not represent the current state of this area . Je kan er creatief mee zijn of niet. Maar op een bepaald punt moet je actie ondernemen. Zeker als hij in zijn eentje 10 andere berooft van quality time. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Project updates
We are on our way back from SOTM. We have had lots of conversations here with people and specifically with Christian Quest about his great openstreetmap.fr http://openstreetmap.fr map style. It shows a lot more data like pedestrian crossings, shops, sports-related stuff and many many more things because it has 2 extra zoom levels. There are also specific icons for each bus/train operator and things like bpost :-)! He also explained some work he did on the openstreetmap.fr http://openstreetmap.fr website and i'm thinking about duplicating this work with our own style and multilingual support but maybe somebody already started with a website? Who owns osm.be http://osm.be btw? according to DNS.be, osm.be is owned by : Dimitri Huys Siemens Square Marie Curie 30, 1070 Anderlecht +32.25368119 dimitry.h...@siemens.com Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
On 2013-09-10 12:08, Jo wrote: Volledig mee eens. Ik heb hem ook een bericht gestuurd, met de vraag om zich in te schrijven voor deze mailing list en de melding dat er een actieve discussie aan de gang is i.v.m. zijn edits. We zullen zien of dat iets oplevert. In ieder geval vind ik het idee om de situatie aan te kaarten in de edit comments ook zinnig. Maar het is inderdaad maar de vraag of hij ooit op z'n stappen terugkeert. Het grootste probleem vormt echter het feit dat je niet weet wanneer hij goedbedoeld of niet in jouw buurt voorbijkomt. We kunnen allemaal wel een stukje monitoren, maar mijn edits gaan ook over heel Vlaanderen. Het enige voordeel dat ik heb, is dat ik wat scripts kan inzetten om te zien of m'n edits wel overeind blijven, maar ook dat geeft weinig garanties, vooral als ik er niet meer aan toekom om deze scripts te laten draaien. Jo Het is vrij serieus want die raakt heel veel aan, een overpass API dump van mijn streek, data ouder dan juni dit jaar is al meer dan 30Mb groot en overpass heeft er moeite mee momenteel , die man heeft 12 000+ changesets op zijn naam. Mijn excuses aan de oudere(vul zelf in wat oud is) contributers op voorhand, en dat zijn er veel :) Ik probeer niet te veralgemenen als ik stel dat 1949 zijn geboortejaar is + het aantal changesets dan denk ik dat hij snel te profileren is als een gepensioneerde die een nieuwe passie heeft gevonden, hij is nederlandstalig (josm NL) en geeft nooit changeset comments in (word ik al gek van op zich). Aan het zwaartepunt van zijn changes te zien is Lodde van de streek van Genk, maar hij verspreid zijn legacy over het ganse land. Kanshebber is ook streek van Berlaar/Lier. Vooral toch het noorden van het land, Limburg en Antwerpen. Hij is ook deels een wandelaar, in tegenstelling tot mijn eerste vermoeden dat het een binnenhuismapper is, zijn GPX traces hebben wel commentaar, en veel ervan staat 'wandeling' bij. Hij is wel al 2 jaar gestopt met die te uploaden naar OSM. De paden die hij in mijn streek editeert (Zemst, naast Mechelen) zijn ook allen wandel/fietspaden. Zeer waarschijnlijk alleen wandelen, want mappen en langs de zenne rijden is dodelijk hier door het ontbreken van een hindernis tussen die wandelpaden en de Zenne. Ik zie die dat niet op een fiets doen. Hij is zeker ook thuismapper want landuse invullen doet niemand met de GPS (meer) data van een wandeling door de velden. Ook is hij fan van geocaching of heeft het minstens 1 keer zeker in geslaagd om iets te vinden met dezelfde username: http://www.geocaching.com/seek/log.aspx?LUID=f1226fd9-806d-4298-928f-88b01c89e4fd Misschien kunnen we eens een geocaching opdracht maken voor lodde1949 te vinden ? ;-) En speelt tussen de edits door nog wel eens een handje poker op pokerstars (mijn pokerstars account is al tijdje nie meer gebruikt, maar je zou hem dus wel kunnen zoeken met hun search systeem, dat gaat normaal. Kan je even bij aan de tafel schuiven om te praten. Kans ik ook klein daar want zijn laatste data is van 2009/2010. Dat zegt op zich niks want je kan die blocken als je wil bij alle dataminers (van pokerdata). Kan ook zijn dat dit een gans ander persoon is al zie ik een trend in het feit dat hij poker gestopt is (om OSM op te pikken eventueel?) Klachten reiken ook tot buiten Belgie: http://forum.gps.nl/viewtopic.php?f=109t=34597 maar niet noodzakelijk als oorzaak. Zijn eerste GPX track, die bij mij indertijd van voor men deur begon origineert hier: http://www.openstreetmap.org/#map=15/51.1172/4.6411 We zoeken dus misschien zelfs een Lodewijk van 1949 met zijn adres in deze BBOX. Glenn PS: Ik gebruik deze query momenteel voor OverPass: http://overpass-turbo.eu/s/10J Met zoveel changesets is zijn impact op de kwaliteit van de maps wel voelbaar, ben nog niet gaan kijken of hij juist tagt (de meeste van de changes hier zijn van 2011) naar de huidige afspraken. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On 2013-09-10 14:08, Nicolas Pettiaux wrote: Thanks. Could you contact him to ask ? I propose to start considering to setup a Belgian OSM site in Dutch, French, English and German if we have enough people to translate in German. Would Drupal be appropriate to setup such a multilingual site ? Do anyone of us know Drupal (or any other easy and well know tool that would do the job) or mediawiki ? What would be the hardware we need ? (CPUs, RAM, hard disk) It would totaly depend on what you mean by Belgian OSM site. I would personally not use drupal for such a site but use a framework (staying in the PHP realm here) like Laravel4 or Symphony2.But that also depends on what I have in mind for such a site. I do think Drupal and wordpress is overkill, I use wordpress for my personal blog just because I'm a developper , so by definition I'm lazy and don't want to spend too much time. Drupal/Wordpress and the like are pretty much OK for a blog oriented site. You could run this from a 20$ per month linode (see https://www.linode.com/ ). In fact, using nginx as a webserver, mariaDB instead of mysqlDB and spending a good chunk of time tuning it, you can run several sites easily. I have like 10 of them on it and also a piwik instance (~= opensource version of what google analytics does). So another 10 sites use it to store visitor data in in (just like analytics do it). I do have some caching going on , good practise anyway as most of the files are just staticly served but come from If your goal is to start building up database, do tileserving or create nominatim DB's, the specs go up a lot. Then you would arrive in the price for a cloud server range of a co-located server, cloud servers aren't suited either for heavy indexing, a solution for that would be to use a something like a EBS device (elastic block store - see http://aws.amazon.com/ebs ) and is expensive. On the other hand, if you want a true 'beast' of a server, I would recommend (of course) linux + the Revodrive 3 x2 (personally I would get 2 of those and stripe them over the PCI bus) see http://tweakers.net/serie/1908/revodrive-x2/ That drive has insane specs compaired to regular SATA SSD's. Check out http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks there is one that has numbers from a revodrive from the past, and you'll see why I would use that one. The performance is huge compaired to the price range. I would also not pay too much attention to CPU's. Most of them will be able to server thousands of sites in the webserver scenario. Given the huge datasets in the latter case, I would totally spend all my money on RAM, the more the better as it speeds up postgreSQL and indexing exponentially. So, question back: What are you planning to do with the site ? Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
While all the suggestions are nice, I think we're mostly looking for a company to sponsor OSM (eg. giving the hosting for free). I'm willing to do that with my company, a 'powered by' is good enough for me as this gives me exposure in something I can live with. but I would like to see more details on what is going to be served so I know what machine to throw at it so I can decide. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
On 2013-09-10 15:38, Joren wrote: Op 10-09-13 15:08, Marc Gemis schreef: zelf heb ik het nog nooit gedaan, maar er is een plugin voor JOSM die dat moet mogelijk maken. Klopt, https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter Tot mijn ervaring enkel volledige changesets terug te draaien. Even op openstreetmap.org kijken wat de nummer is van de foutieve changesets, kopieren en in het venstertje van die plugin plakken. Daarna wijzigingen doorsturen. Ok, zeer interessante plugin, kende ik niet, ik vraag me wel af of het werkt als het niet de laatste changeset is, want changesets die elementen refereren uit de 'bad' changeset , dus nieuwe nodes maw, wat gaat daarmee gebeuren als je die terugrolt. Ik zie niet direct een antwoord op dat stuk. Het zou bij definitie wel direct moeten werken op de laatste set. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Actieve gebruiker reageert niet op berichten/vragen
On 2013-09-10 21:18, wannes wrote: On Sep 10, 2013 5:54 PM, Ben Laenen benlae...@gmail.com mailto:benlae...@gmail.com wrote: Om het spreekwoordelijk te zeggen: zorg dat je het kind niet met het badwater weggooit. AAA+ ! Een gemotiveerde mapper, graag gemotiveerd houden. Tenzij hij 10 andere gemotiveerde mappers demotiveert en hun tijd verspilt. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] osm.be
On 2013-09-10 20:06, Ivo De Broeck wrote: Its important (for Google) to have a domain name like belgiumopenstreetmap.be http://belgiumopenstreetmap.be ( see http://ivoweb.be/wat-heb-je-nodig/domeinnaam-kiezen ); All other related url's can be redirected to that site (like osm.be http://osm.be and many others) Which will make you compete with yourself as the same files get indexed for every domain for all search engines if not done properly ...I'm still wondering why you claim google find that important. Sorry for being critical , but I would rather see such claims backed up by sane arguments. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Possible problem with Urbis data import in Brussels
On 2013-08-19 22:25, Jo wrote: Okay, then I looked at the wrong page, apparently. It all started as a series of 'mechanical' operations on the data, but before submitting some human intelligence still needs to be applied to make it all fit with the existing data. We can, of course, create an account like UrbisImport and then share the password of that account. On the one hand that would seem quite odd to me. On the other hand it kills the possibility to create statistics on who does what where. I guess I'm going to have to go and ask on talk-fr if they finally gave in to the pressure from above and all created separate accounts for integrating their cadastre. I don't think they actually did so and I've always been saying that it shouldn't be necessary, just like they have. Unfortunately it's hard to agree to disagree on this sort of subject. I may also take a sabbatical leave of a few years/decades from the project. Just like I did when the talk about the license change started. Unfortunately that went on for years. I hate these kind of struggles. Sharing passwords is a really bad move. First of all, there is no way in a collaborative situation to figure out which _real_ person was responsible for whatever fuckup may happen (I can assure you they _will_ happen). I think professionals should refrain from suggesting procedures that encourage this bad practise. I'm not even going to go deeper in the 'why' that -bluntly stated- is idiotic and sucks terribly. I don't even see the merit in using a seperate single account for this. Maybe it's the word 'import' that triggers this, but as far as I know the Urbis work is not fully automated at all but it is reviewed by motivated, hard working individuals to ensure quality. So it's not an import in the pure sense as this seems to be misunderstood by looking at the complaints. There is actually a solutions for both problems, whatever constraints are being forced upon those people that do the hard work. I guess they are TOO motivated, situations such as these make you loose contributers by the dozen. I for one am very concerned that Jo makes these sabatical statements as one of the key players in the .BE OSM scene. (just face it Jo, you are one of the driving forces, no denying it). The solution is as simple as it gets: Use a dedicated changeset tag, whatever account you use. being it individuals or a dedicated account, put a well chosen changeset tag(s), this can contain: - the userID that made the effort, even though it's commited through another account. - the sort of import the changeset represents. I think we already do the second one, since this is the way this got spotted in the first place afaik. The first one we just need to aggree upon as .BE OSM community. Would love to hear what benefit a seperate/dedicated yet shared account brings to the table. Take all the time you need to answer this. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Correct use of is_in tag
On 2013-07-31 15:23, Joren wrote: Hi, I was wondering what's the correct use of the 'is_in'-tag in Belgium (or Flanders in particular). When I search on openstreetmap.org for cities, I sometimes see the detail it is in 'European Union'. For example, my own city Lier has following search result: Stadsgrens Lier, Mechelen, Antwerpen, Vlaanderen, België, European Union http://www.openstreetmap.org/?minlon=4.50586080551147minlat=51.0726852416992maxlon=4.64306163787842maxlat=51.1657829284668 When I search for city Duffel: Stadsgrens Duffel, Mechelen, Antwerpen, Vlaanderen, België http://www.openstreetmap.org/?minlon=4.46484470367432minlat=51.0725708007812maxlon=4.57519102096558maxlat=51.1169281005859 As you can see, Lier is tagged correctly it is in the EU, Duffel isn't. There are multiple other examples (Oostmalle, Zandhoven, ...) When I compare the tags: For Duffel (http://www.openstreetmap.org/browse/node/85635996/history) * is_in http://wiki.openstreetmap.org/wiki/Key:is%20in?uselang=nl = Mechelen,Mechelen,Antwerpen,Antwerpen,Vlaanderen,Vlaanderen,Belgique,Belgique,Europe * is_in:continent = Europe * is_in:country = Belgium * is_in:province = Antwerp * name http://wiki.openstreetmap.org/wiki/Key:name?uselang=nl = Duffel * + some openGeoDB-tags vs for Lier (http://www.openstreetmap.org/browse/node/30997655) * is_in http://wiki.openstreetmap.org/wiki/Key:is%20in?uselang=nl = Antwerpen, Belgium, Europe * is_in:continent = Europe * is_in:country = Belgium * is_in:province = Antwerp * name http://wiki.openstreetmap.org/wiki/Key:name?uselang=nl = Lier * + some OpenGeoDB-tags (see links below) Actually, Lier is incorrect considering this relation: http://www.openstreetmap.org/browse/relation/2524403 Lier is in Arrondissement Mechelen. You have to account for the Administrative layers. Afaik, relations like this should replace the is_in tag, I never really got that tag either. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] (geen onderwerp)
Straten zonder naam lijkt mij ook wel vreemd. Zoveel kunnen dat er toch niet meer zijn? http://overpass-turbo.eu/s/GH Ik zie er wel waat waar ik ook kijk, de enige die zowat overblijven zijn de highway=unclassified , Maar als je cycleways terug aanzet, ontbreken er wel veel namen. Het hang wss af van welke hoek je het bekijkt. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] (geen onderwerp)
On 2013-07-31 16:15, Ben Abelshausen wrote:
Klopt maar niet alle service, cycleways, tracks, footway, steps hebben
effectief namen. Andere 'highways' soms ook niet, bijvoorbeeld een
rond punt moet in principe ook niet altijd een naam hebben. Die
highway=unclassified daar hebt ge wel een punt... :-)
Die waren dan ook uitgefiltered adhv de negatie (not) om die reden:
has-kv k={{key}} modv=not
regv=service|footway|track|motorway|trunk|path|steps|cycleway/
Dus de enige die nu nog bovendrijven zijn de unclassifieds. Ook alle
wegen waar wel ref voor bestaat (En geen naam) zijn eruit. De reden dat
ik dat zei over cycleways is dat die best de naam kunnen hebben van hun
'moederweg', voor routing zou dan een propere fietsnaam bovenkomen ipv
'track' of 'cycleway'
Glenn
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] (geen onderwerp)
Probeer mss eens eentje waar ik veel mee speel tegenwoordig, eigen servers: http://routing.bitless.be/www/routino/router.html Profiel van fietser lijkt aardig te werken toch, maar natuurlijk wel geen bekende fietsroutes momenteel. Enkel Benelux routing + geocoding trouwens. Glenn On 2013-07-30 21:33, Marc Gemis wrote: Voor zover ik weet zijn er geen routeplanners die gebruik maken van de routes (fiets/wandel) op basis van OSM. Ik probeer nu via de univ van Antwerpen een bachalor thesis op te zetten om dit te verhelpen. Heb je al eens naar wandelknooppunt.be http://wandelknooppunt.be gekeken ? Weet je hoeveel fouten daarin zitten ? Heb je al een naar google maps gekeken ? Ik weet tenminste 3 plaatsen waar die de mist ingaat kwa eenrichtingsstraten of straatnamen. Om nog maar niet te spreken van de ingebouwde GPS van mijn auto, weliswaar met 4 jaar oude kaarten. Dan liever OSM, kan ik tenminste zelf corrigeren/toevoegen. Ik denk dat je feitelijk alle wandelroutes ieder jaar opnieuw helemaal moet nalopen om te kijken of er geen wijzigingen zijn. Hetzelfde geldt waarschijnlijk voor de fietsroutes groeten m 2013/7/30 Guy Vanvuchelen guido.vanvuche...@pandora.be mailto:guido.vanvuche...@pandora.be Kent er iemand naast www.fietsrouteplanner-zuid.nl http://www.fietsrouteplanner-zuid.nl nog een planner waarmee je aan de hand van knooppunten een route kan samenstellen en daarna downloaden als GPX. Als ik eerlijk ben moet ik toegeven dat fietsnet.be http://fietsnet.be een betere routeplanner is maar helaas (of juist niet helaas) niet werkt op basis van OpenStreetMap. Het is namelijk mijn overtuiging dat je, ondanks alle moeilijkheden, best de gegevens van OSM zoveel mogelijk gebruikt...om er zo de fouten uit te halen. Ik ben twee dagen na mekaar verbaasd over het aantal fouten dat ik tegenkwam. Geen propaganda voor OSM hoor! Guy Vanvuchelen ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] OSM maxspeed value variaties / variations
Hallo / Hi Gezien vandaag met een pgrouting database aan te willen maken / Noticed today while trying to create a pgrouting DB (benelux) unknown maxspeed value: 50; 30; 30 unknown maxspeed value: 80; 50 unknown maxspeed value: 60; 30 unknown maxspeed value: 30; 30; 60; 30; 30; 30 unknown maxspeed value: 60km unknown maxspeed value: 60km unknown maxspeed value: 30 km/h unknown maxspeed value: 60km unknown maxspeed value: 60km unknown maxspeed value: 30km unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 30 km/h unknown maxspeed value: 60km unknown maxspeed value: 70km unknown maxspeed value: 30 km unknown maxspeed value: 50km unknown maxspeed value: 50km unknown maxspeed value: 50km unknown maxspeed value: 50km unknown maxspeed value: 70km unknown maxspeed value: 70km unknown maxspeed value: 30km unknown maxspeed value: 30km unknown maxspeed value: 60km unknown maxspeed value: 30km unknown maxspeed value: 60km unknown maxspeed value: 60km unknown maxspeed value: 30km unknown maxspeed value: 60km unknown maxspeed value: 60km unknown maxspeed value: 60km unknown maxspeed value: 30km unknown maxspeed value: 30km unknown maxspeed value: 5 mph unknown maxspeed value: 80; 50; 50; 50 unknown maxspeed value: 30; 50 unknown maxspeed value: 70 mph unknown maxspeed value: 75 mph unknown maxspeed value: 75 mph unknown maxspeed value: 15; 30 unknown maxspeed value: 50 km/h unknown maxspeed value: 50 km/h unknown maxspeed value: 50 km/h unknown maxspeed value: 50 km/h unknown maxspeed value: 50 km/h unknown maxspeed value: 50 km/h unknown maxspeed value: 50 km/h unknown maxspeed value: 50 km/h unknown maxspeed value: 60 km unknown maxspeed value: 60 km unknown maxspeed value: 60 km Werk aan de winkel dus, eens via overpass proberen te fixen. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Firefighters and OSM + fire_hydrant
On 2013-07-25 10:16, Teddy wrote: 2013/7/24 Kurt Roeckx k...@roeckx.be mailto:k...@roeckx.be fire_hydrant Hello Kurt, No, there are 3 numbers for the offset, in the tag fire_hydrant:position ** fire_hydrant:position= lane/parking_lot/sidewalk/green; left offset;front offset;right offset But in the official description (see below), there is no numbers at the end of the tag ! The type of material is in the tag fire_hydrant:type ** fire_hydrant:type=underground/pillar/wall/pond The diameter is in the tag : fire_hydrant:diameter The diameter is in the tag : fire_hydrant:standard, DIN is the standard for Europe. **fire_hydrant:standard = DIN *Be carrefull, officialy, you must also use the tag :* ***amenity=fire_hydrant* *See-**http://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant#VOTE_END_UPDATE* Rem : on fire signaling panels (Belgium, France, Deutchland) : B is for Borne - above ground H is for Hydrant - below ground Eddy, That is not correct. There is a little notice that says: The proposal moved to emergency. ? Tag:emergency=fire_hydrant Below that someone correctly states: After a long discussion about the emergency-tags we decided to let the fire hydrants in the amenity namespace (for now). This discussion was where? Please provide the link. So you should not use amenity. There is also no law that says you cannot deviate from the norm. If you check the occcurences of the way I tagged the position of hydrant you will see more of those, I also frequently see discussions on the general mailing list that state the wiki is not always correct and it is lagging behind in many cases. If you check the occurences of this tag: http://taginfo.openstreetmap.org/tags/?key=emergencyvalue=fire_hydrant vs http://taginfo.openstreetmap.org/tags/?key=amenityvalue=fire_hydrant I think it is safe to say you should keep using emergency. Eddy, That is not correct. There is a little notice that says: The proposal moved to emergency. ? Tag:emergency=fire_hydrant Below that someone correctly states: After a long discussion about the emergency-tags we decided to let the fire hydrants in the amenity namespace (for now). This discussion was where? Please provide the link. So you should not use amenity. There is also no law that says you cannot deviate from the norm. If you check the occcurences of the way I tagged the position of hydrant you will see more of those, I also frequently see discussions on the general mailing list that state the wiki is not always correct and it is lagging behind in many cases. If you check the occurences of this tag: http://taginfo.openstreetmap.org/tags/?key=emergencyvalue=fire_hydrant vs http://taginfo.openstreetmap.org/tags/?key=amenityvalue=fire_hydrant I think it is safe to say you should keep using emergency. Glenn Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Fwd: [OSM-talk] Mapping cooperation between countries in OSM
This is pretty interesting visualisation / Vrij interessante voorstelling van grensoverschrijdend mappen Original Message Subject:[OSM-talk] Mapping cooperation between countries in OSM Date: Thu, 25 Jul 2013 11:47:45 +0200 From: Frédéric Bonifas fredericboni...@gmail.com To: talk_at_openstreetmap Openstreetmap t...@openstreetmap.org Hi, For a long time I have wanted to know where people from a given country also contribute in OpenStreetMap. I have analyzed all the nodes in the OSM Planet from the 15th June 2013 and I came up with this map : http://fredericbonifas.github.io/OSM-cooperation/ One identified bias is that each contributor is assigned the country where he has contributed the most as his main country. But this may be false. Best -- Frédéric Bonifas +33672652807 skype:fredericbonifas ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Firefighters and OSM + fire_hydrant
On 2013-07-25 21:29, Kurt Roeckx wrote: On Thu, Jul 25, 2013 at 10:16:14AM +0200, Teddy wrote: 2013/7/24 Kurt Roeckx k...@roeckx.be fire_hydrant Hello Kurt, No, there are 3 numbers for the offset, in the tag fire_hydrant:position On the signs there are only ever 2 of those numbers. Either you one to the left or one to the right. Never both. Anyway, I see no point in mapping that a sign says the hydrant that much away from the sign. Those numbers are their for people who are looking for the hydrant to find by saying about where they should look. In my expieriences they're also not very accurate. It would make sense with hidden ones and a smartphone application to find them using OSM data. If you know what to look for _and_ where, you are all set. But in the end it doesn't matter, I really didn't forsee that by copying a key from the severly micromapped Rossleben a discussion of this kind would erupt. In the end, it's probably bad tagging, values like that deserve their own keys. But the same thing can be said about a tree, why would you map a tree? only reason I know is to make it a landmark. I do this sometimes as this can help recognizing distinct areas. Sometimes the application of those things is beyond our imagination. Things like this emerge nowadays : http://eprints.nuim.ie/2482/1/Ciepluch-et-al-ACM-GIS-CamerReady1.pdf Using OSM data to determine location without GPS, just by using vector data. I can imagine an application (google glasses ?) that could do wicked things using this. But in the end, it's only a sign. But it would be not against OSM spirit, e.g. To map what is there in the real world. Mapping the hydrant is much more important. Eventually the lat/lon on that, if precise enough is exactly the location, so in essence, we would be using a different positioning system in an existing one. So , eventually it's not all that important to do, and I would not have a problem to drop those from the ones I made. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Geocoding met foute postcode's
The person that made this error has made several , at random I started checking his edits, things like numbers that are in the wrong key (addr:housename=537) http://www.openstreetmap.org/browse/node/864788506 Edited twice more, but user TAA didn't seem to have fixed that mistake. I find it more and more disturbing that people are just creating more work for others by delivering low quality or careless work. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Geocoding met foute postcode's
On 2013-07-23 19:29, Kurt Roeckx wrote: So I asked on IRC in #osm-nominatim and got as answer that it should work but currently doesn't work. tx for the notice. I'm cleaning up the whole postal code information as we speak, plenty of errors: - city in addr:postcode - reversing city with postcode - postal codes prepended with B or B- or Bspace - postcode + city in addr:postcode - housenumbers in as the postcode I'm looking straight into the placex table from nominatim to see what crap is in there, and then use Overpass to extract the data into JOSM so I can edit and fix. Almost done with the current mess. My edit history reflects this mess. I think half of it is due to not paying enough attention to what josm autocompletes while entering a new key. I hope this will sort out the Belgium quality of postal codes as it stands now. Whatever the future will bring us, atleast the present is correct. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Geocoding met foute postcode's
Dat is niet de OSM id die in de result set staat, maar het zal idd van
die bank komen.Die OSM id is van een bushalte blijkbaar, was me niet
direct opgevallen.
Nu heb ik nominatim benelux lokaal staan dus kan wat in de DB gaan
neuzen wanneer de temperatuur onder de 25 graden valt vanavond (hopelijk).
tx voor het voor de hand liggende te laten weten ;-)
Glenn
On 2013-07-22 17:25, Georges De Gruyter wrote:
Postcode staat op die node van de bank :
http://www.openstreetmap.org/browse/node/283131658
Mvg,
Georges
Op 22 juli 2013 17:20 schreef Glenn Plas gl...@byte-consult.be
mailto:gl...@byte-consult.be het volgende:
Vandaag volgende tegengekomen:
http://nominatim.openstreetmaps.org/reverse.php?format=jsonlat=50.9420900lon=4.7305583zoom=18addressdetails=1email=gl...@byte-consult.beaccept-language=nl,en;q=0.8,fr;q=0.5
resultaat:
{place_id:12246533,licence:Data \u00a9 OpenStreetMap
contributors, ODbL 1.0. http:\/\/www.openstreetmap.org
http://www.openstreetmap.org\/copyright,osm_type:node,osm_id:1156867059,lat:50.9424155,lon:4.7310233,display_name:Station,
Stationsstraat, Rotselaar, Leuven, Vlaams-Brabant, Vlaanderen,
3012KA, Belgi\u00eb, European
Union,address:{bus_stop:Station,road:Stationsstraat,city:Rotselaar,county:Leuven,state:Vlaanderen,postcode:3012KA,country:Belgi\u00eb,country_code:be,continent:European
Union}}
Daar komt als postcode uit: 3012KA
Nu sinds wanneer hebben wij dit soort postcodes in Belgie ?
als je de google ding doet met die postcode kom je op dit uit:
http://www.straat1.be/belgie_a_34/wilsele_m_19319/3012ka_k/bank_a
Maar als ik ga kijken, staat er geen postcode op die node, dwz dat
er dus bovenliggen een probleem is.
Heeft iemand een idee van waar dit komt ? Voorlopig vind ik niet
vanwaar die code komt.
Mvg,
Glenn
___
Talk-be mailing list
Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Geocoding met foute postcode's
On 2013-07-22 23:13, Kurt Roeckx wrote: On Mon, Jul 22, 2013 at 10:44:51PM +0200, Ben Laenen wrote: On Monday 22 July 2013 22:24:09 Kurt Roeckx wrote: On Mon, Jul 22, 2013 at 09:22:47PM +0200, Marc Gemis wrote: The only good solution is to create post code polygons. This is stated e.g. on the nominatim FAQ page: http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#postal_codes I don't know hpw we can do this. So basicly most administrative boundaries (relations) should also be turned into a polygon? Boundary relations are polygons, the same kind as a multipolygon relations. So no need to change anything I tried adding it to the boundary relation 1 hour ago, but it's still showing a wrong result here. My expierence is that nominatim updates after like a few minutes already. It takes about an hour to 2 hours to index the minute diffs/updates, I've setup a few nominatim instances this weekend and I came across that in de documentation I absorbed. The extracts are loaded pretty fast but it's the reindexing part itself that takes a while to run. They also aggregate as you cant index 2 hours for each minute diff, so there is some aggregation. As always, the wiki can be outdated, biggest problem with wiki's in fast moving scenes. It can be faster however, it just depends on the data size. GLenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Firefighters and OSM + fire_hydrant
@Glenn: What does this mean : * fire_hydrant:position = sidewalk;0.0;1.2;0.0 * fire_hydrant:standard = DIN I understand fire_hydrant:position:sidewalk, but not the numbers after. Are they the position from the sidewalk's edge ? Do you have a list of fire_hydrant:standard ? I copied most keys from RossLeben area, anyone who was there in Lier should remember that micromap. Check out node http://www.openstreetmap.org/browse/node/1841448214 there. The person ( manu1400 ) that did the last edit on that node, also corrected the one I mentioned earlier in Mechelen : http://www.openstreetmap.org/browse/node/2155389836 So that corrected the same key on both, I'm sure I copied that over. I believed at the time it's a description of the location/distance from the first part: in this case the sidewalk. I noticed that potlatch marks that key as problematic but It seems to be the consensus for the location of the hydrant. manu1400 hasn't corrected it (yet) ;-) I'm sure it's described somewhere but I'm running circles too on the wiki on that. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] jaagpad / chemin de halage
On 07/15/2013 09:07 PM, Stijn Rombauts wrote: Hi, How should tow paths (jaagpaden / chemins de halage) along canals be mapped, either paved or unpaved? I see many different things: service road, cycle path, general path, track, ... StijnRR Hi Stijn, Take a look at de jaagpaden in my area, for example http://www.openstreetmap.org/browse/way/24798953 or http://www.openstreetmap.org/browse/way/25352830 Lots of key/value inspiration. They are accurate afaik. The road is an unpaved 'gravel-like' road, but hardened by usage. a tad dangerous as there is no security between the path and the Zenne. hope this helps you choose, check out the tracktype key in the wiki, lot's of examples. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Power generation - tag update
On 07/02/2013 09:31 PM, Glenn Plas wrote:
http://overpass-turbo.eu/s/rA
Er is iets mis met de bovenstaande Overpass query, heb een iets simpele
versie nu, en die brengt toch wel veel meer werk naar boven nu.
union
query type=way into=waypower
has-kv k=power regv=power|station|generator/
bbox-query {{bbox}}/
/query
query type=area into=areapower
has-kv k=power regv=power|station|generator/
bbox-query {{bbox}}/
/query
query type=node into=nodepower
has-kv k=power regv=power|station|generator/
bbox-query {{bbox}}/
/query
/union
union
item/
recurse type=down/
/union
print mode=meta/
Best niet uitvoeren over meer dan 1 grote stad.
Mvg,
Glenn
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Power generation - tag update
Hi, On 07/03/2013 05:28 AM, Marc Gemis wrote: I wonder whether they will run a bot to change them globally. I have asked this question on the talk maling list. I don't think this is a good idea, I actually closed the overpass export in JOSM without saving, since by the looks of it, most of these nodes aren't even power stations to begin with, so re-tagging them as a 'plant' is not correct. The use of 'generator' for a transformator device isn't intuitive to me, but I guess that's a cultural thing. I think most of us have a different mental picture when I say 'generator' vs. 'transfo'. We'll have to look at each individual node/way to determe what to do with it, luckily there aren't much of them, fixing 'designation' key was a lot more work. Ik vraag me af of ze een programma gaan laten lopen om dit globaal aan te passen. Ik heb de vraag gesteld op de talk mailing list Denk niet dat dit een goed idee is, heb de overpass export dichtgegooid omdat op het eerste zicht de huidige tags al niet eenduidig zijn gebruikt. Zomaar retaggen naar 'plant' is niet juist, als ik de nodes en de locatie in detail bekijk gaat het zeker niet over een powerplant in veel gevallen maar een transfo. Voor mij is het gebruiken van 'generator' voor een transformator niet echt voor de hand liggend, ik heb een heel ander mentaal beeld als iemand 'generator' zegt vs 'transformator' Het zal per node/way moeten worden bekeken hier in Belgie, maar gelukkig zijn er echt maar weinig. Het fixen van 'designation' key was een pak meer werk. Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Power generation - tag update
We could use OverPass export to fix this at once for Belgium if applicable. Except for what the 3 remaining proposals cover. Can take a stab at this. Via OverPass export kunnen we dit gemakkelijk aanpassen, afhankelijk of het toepasselijk is of niet. Wil die poging wel wagen, maar dan uitgezonderd voor wat de 3 hangende voorstellen betreft. Mvg, Glenn On 07/02/2013 09:20 PM, Marc Gemis wrote: This is a cross post from the tagging-mailing list: There are some major changes to the tagging of power generating installations: Recentelijk zijn er een aantal tag i.v.m. met het opwekken van energie gewijzigd. In de nabije toekomst gaan er nog enkele wijzigingen. Dit is waarschijnlijk ook van belang voor Hoe map ik een groeten m François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu wrote: Last June 11, the power generation refinement proposal was approved by 30 wiki users. http://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement It aims to provide a strong and consistent tagging model to map power plants and power generators too. http://wiki.openstreetmap.org/wiki/Tag:power%3Dplant http://wiki.openstreetmap.org/wiki/Tag:power%3Dgenerator Thus, power=plant replace the deprecated power=station (for places where power is generated only, seehttp://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement for other OSM use cases). power=generator is reserved for devices which convert power from one kind to another kind. Wiki update is still in progress but rendering models and editors presets should be upgraded with that new stuff. If there's anything you need to bring this up to date, please ask here and I would be pleased to precise any unclear point. Please note that 3 other proposals are still draft or RFC and should be voted in next monts. http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Power generation - tag update
http://overpass-turbo.eu/s/rA it's a small result set Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] OSM Activities during the summer
On 07/01/2013 09:42 PM, Ivo De Broeck wrote: Hm Korbeek-lo is minder ver van Leuven dan Afrika ;-). Er klopt toch iets niet, mensen veel verder verwijderd van Leuven zijn wel vermeld. Ivo, Klik even 'activity center' af in het menu rechts, en watch the magic ! Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] OSM Activities during the summer
On 07/01/2013 10:32 PM, Ivo De Broeck wrote: Magic ja, maar op een totaal verkeerd adres op ongeveer 2 km van mijn woning (Valleilaan 13 Korbeek-lo) Aan de opties te zien denk ik niet dat het de bedoeling is om te tonen waar de mapper woont maar waar het zwaartepunt van zijn werk ligt. Mijn 2 locaties staan ook niet bovenop mijn woning. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorsorteerstoken
Je kan gebruik maken van de puntkomma voor een lane met meerdere functies : bv: turn:lanes = left|through|through;right Dit stelt dan 1 links, 1 rechtdoor en 1tje rechtdoor+rechts. Er is wel een verschil tussen destination:lanes key en de turn key, probleem is dat ik de R16 niet goed ken en kan niet helemaal volgen in de uitleg. Zijn de bing achtergronden courant ? Anders kijk ik het op basis daarvan even na. Ik denk dat je hier de destination:lanes key verkeerd gebruikt voor het doel dat je voor ogen houd, zie http://wiki.openstreetmap.org/wiki/Key:destination Mvg, Glenn On 07/01/2013 11:11 PM, Joren wrote: Beste, (For rough English translation, please see bottom) Zonet heb ik er even de wiki bijgehaald in verband met voorsorteerstroken (http://wiki.openstreetmap.org/wiki/Key:turn en http://wiki.openstreetmap.org/wiki/Lanes). Voornamelijk het uitgewerkt voorbeeld is interessant http://wiki.openstreetmap.org/wiki/Key:turn#Motorway_with_links_and_destinations Enkel begrijp ik volgens mij de 'destination:lanes' tag niet zo goed. Ik heb even wat uitgewerkt op 2 kruispunten in Lier, waarvan hier een voorbeeld van: http://www.openstreetmap.org/browse/changeset/16783476 (zie R16 (=ring van Lier) van zuid naar noord). Hierbij ga je uiteindelijk over van 2 baanvakken naar in totaal 5 (2 links, 2 rechtdoor, 1 rechts). Hoe moet ik dit bijvoorbeeld aanduiden op het stukje voor de voorsorteerstroken, wanneer er nog 2 banen zijn. Met destination:lanes=A|B kom ik voor deze 3 richtingen (links, rechtdoor, rechts) er niet denk ik. Of wel :)? Bedankt voor jullie hulp. Joren ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorsorteerstoken
On 07/01/2013 11:30 PM, Joren wrote: Op 1/07/13 23:22, Glenn Plas schreef: Je kan gebruik maken van de puntkomma voor een lane met meerdere functies : bv: turn:lanes = left|through|through;right Dit stelt dan 1 links, 1 rechtdoor en 1tje rechtdoor+rechts. Er is wel een verschil tussen destination:lanes key en de turn key, probleem is dat ik de R16 niet goed ken en kan niet helemaal volgen in de uitleg. Zijn de bing achtergronden courant ? Anders kijk ik het op basis daarvan even na. Ja, deze kloppen en de pijlen zijn vrij goed zichtbaar. Zie http://binged.it/1cJonWi Zoals je (hopelijk) kan zien gaat het van 2 rijbanen naar 4 over (left, left, through, through), en uiteindelijk komt er nog een 5de bij (left, left, through, through, right). Bing doet wel raar, als ik de link open zoom hij in op de locatie om direct uit te zoomen op lier. Ik kijk het even na in JOSM. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorsorteerstoken
On 07/01/2013 11:30 PM, Joren wrote: Op 1/07/13 23:22, Glenn Plas schreef: Je kan gebruik maken van de puntkomma voor een lane met meerdere functies : bv: turn:lanes = left|through|through;right Dit stelt dan 1 links, 1 rechtdoor en 1tje rechtdoor+rechts. Er is wel een verschil tussen destination:lanes key en de turn key, probleem is dat ik de R16 niet goed ken en kan niet helemaal volgen in de uitleg. Zijn de bing achtergronden courant ? Anders kijk ik het op basis daarvan even na. Ja, deze kloppen en de pijlen zijn vrij goed zichtbaar. Zie http://binged.it/1cJonWi Zoals je (hopelijk) kan zien gaat het van 2 rijbanen naar 4 over (left, left, through, through), en uiteindelijk komt er nog een 5de bij (left, left, through, through, right). Die van zuid naar noord ziet er volgens mij ok uit, aantal lanes klopt, en de turn:lanes zitten ook goed. Ik denk niet dat je destination:lanes daar nodig hebt. Ik zie ook geen pijlen op het stuk voor hij overgaat naar 4. Tenzij iemand anders mij tegenspreekt voor een reden die ik niet zie, zit je goed! Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorsorteerstoken
On 07/01/2013 11:48 PM, Joren wrote: Op 1/07/13 23:46, Glenn Plas schreef: Die van zuid naar noord ziet er volgens mij ok uit, aantal lanes klopt, en de turn:lanes zitten ook goed. Ik denk niet dat je destination:lanes daar nodig hebt. Ik zie ook geen pijlen op het stuk voor hij overgaat naar 4. Tenzij iemand anders mij tegenspreekt voor een reden die ik niet zie, zit je goed! Super :-). Bedankt voor je tijd en de hulp! Zeer geapprecieerd :)! Geen probleem, mss nog even iets, volgens mij zit de cycleway=lane niet correct. Ik denk dat het cycleway=track moet zijn Heb de description nog eens herlezen en eens met streetview gaan spieken, er is een scheiding tussen de baan voor de wagens en het fietspad. Ik vind het soms wel moeilijk om te kiezen tss die 2. Als er parkeerplaats tss de baan en het fietspad ligt ben ik geneigd 'track' te gebruiken. http://wiki.openstreetmap.org/wiki/Key:cycleway Mss wel even een 2de mening vragen hier van de 'bike-mappers' onder ons. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorsorteerstoken
On 07/01/2013 11:48 PM, Joren wrote: Op 1/07/13 23:46, Glenn Plas schreef: Die van zuid naar noord ziet er volgens mij ok uit, aantal lanes klopt, en de turn:lanes zitten ook goed. Ik denk niet dat je destination:lanes daar nodig hebt. Ik zie ook geen pijlen op het stuk voor hij overgaat naar 4. Tenzij iemand anders mij tegenspreekt voor een reden die ik niet zie, zit je goed! Super :-). Bedankt voor je tijd en de hulp! Zeer geapprecieerd :)! Een vergelijkbare situatie (turnlanes + cycleway) is het kruispunt te Hofstade aan het Bloso Domein: Neem even way 24764202 , te downloaden als object in JOSM (dan centreert josm zich op kruispunt), om dan nog eens een download te doen van een bounding box. Dat kruispunt heeft ook turn:lanes gedefinieerd. Het fietspad heb ik daar uiteindelijk uit de keys gehaald en apart als highway=cycleway gemapt. Daar staat ook een parkeerstrook tussen de baan en het fietspad. Meestal denk ik zo: als ik het fietspad appart kan mappen zonder te overlappen, is de kans groot dat het een cycleway=track betreft. Een cycleway=lane zou in principe overlappen met de baan waartoe het behoort. Op dat kruispunt dat ik vermeld staat ook turn lanes van dit soort: (noordelijk stuk) turn:lanes:backward / turn:lanes:forward Ik zie net dat onze mails kruisen maar blijkbaar denken we hetzelfde over die cycleway, dus goe bezig zou ik stellen. Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Voorsorteerstoken
On 07/02/2013 12:03 AM, Jo wrote: Ik ben ook geneigd om voor een gescheiden fietspad een eigen way in te tekenen. Zo kan je alle nuances meenemen en ze mooi rond de bushalte bays leiden. Wie had er ooit gedacht dat ik het over bushaltes zou gaan hebben :-) Jo Ik ga ooit nog een wagen voor je kopen Jo, dan gaan de wegen even goed gemapt worden als de busroutes, volgens mij ben jij wel voor een electrisch model te vinden :) tx om mijn idee erover te bevestigen, denk dat we allemaal op 1 lijn staan op dit onderwerp. Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
On 06/30/2013 01:27 PM, Guy Vanvuchelen wrote: Bedankt Jo, ik zal echter moeten wachten tot we eens samenkomen want skype heb ik niet meer en een Google hangout is voor mij een nobele onbekende. Wat een MAPCSS-stijl betreft ook dat zal je me eens moeten uitleggen. Je merkt, dat zo'n bijeenkomsten nuttig zullen zijn, en waarschijnlijk niet voor mij alleen.. Guy, Je gaat ze nooit meer willen afzetten die mapCSS, toen Jo me daarop attent maakte heb ik mijn verzameling mapCSS sheets gevonden, die zijn echt enorm handig. Als ik nu ergens een streek opendoe zie ik onmiddelijk waar er straatnamen ontbreken, en huisnummers bv. Naast Overpass API is mapCSS van de meest effectieve dingen. Het is eigenlijk gewoon een soort eigen stijl dat je erover plakt om ervoor te zorgen dat iets in het oog springt, dus je kan bv alle highway=trunks in het roos weergeven, of dikte maal 5. Hier is een ... ahum ... nederlandstalige (bedoelde) link over mapcss met veel engels op (kon niets anders vinden) http://josm.openstreetmap.de/wiki/Nl%3AStyles Ik heb een extra stijl of 5 steeds aanstaan. Het verdubbeld je productiviteit in JOSM. Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
On 06/30/2013 04:41 PM, Guy Vanvuchelen wrote: Glenn, Bedankt voor de info. Helemaal versta ik het (nog) niet. Ik heb wel de 'kaarttekenstijlen' gevonden. MapCSS vond ik niet. Wel railway.mapcss. Ook Wandelknooppuntennetwerken vond ik. Of is MapCSS de verzamelnaam van al die 'kaarttekenstijlen'? In elk geval ga ik hier ook gebruik van maken Hallo Guy, Het is eerder een verzamelnaam, het is wat weggestopt in JOSM, gemakkelijkste dat je het kan vinden is F12 - Map Settings - Map Paint Styles (ik heb JOSM in Engels staan, dus probeer even equivalent van die te vinden). Bij mij onder de linux versie is het de derde menu optie van boven geteld (lijkt op een raster over een wereldbol). Je kan via de OSM wiki custom stijlen vinden, ik heb aanstaan (is niet standaard de meeste): - JOSM interne stijl - Streets Have No Name - New Parking CSS stijl (Mijn eigen custom versie van 'new parking features') - Address Tag Validator - Coloured Addresses - Lit - Lit Objects Ik weet alleen niet meer of er al standaard een aantal staan, maar het komt erop neer dat je heel gemakkelijk stijlen kan toevoegen. Hopelijk vind je ze zelf. Nog interessant zijn bv: - Maxspeed CSS (toont direct welke straten geen maxspeed settings hebben. - Cycleways Jo heeft ook een goeie gemaakt(of bestaande aangepast) dacht ik, public transport natuurlijk :) Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
On 06/27/2013 06:54 PM, Marc Gemis wrote: Ivo, wanneer is iets volledige in jouw optiek? buiten de dingen die je hebt opgesomd, probeer ik ook nog de voetpaden (sidewalk tag = yes/no/left/right/both) verlicht yes/no (vooral van belang voor fietspaden die niet naast de weg lopen) parking lanes (voor het al/dan niet evenwijdig parkeren) het aantal rijstroken (lanes) maximum snelheid afdraaibeperkingen (turn restriction) te mappen. Dan pas kom je een beetje in de buurt van volledig volgens mij. Want je hebt natuurlijk ook nog de voorsorteervakken en de wegwijzers, de toeristische bezienswaardigheden, enz. Met die dingen ben ook ik bezig, vooral op hoofdwegen, turn restrictions en lanes , voor het 1ste is er een goede plugin om dit visueel te doen in JOSM. Voorsorteervakken vind ik ook vrij plezant om te doen, die key/tags hierover zijn goed opgezet en eenduidig. Probleem met 'lit' is momenteel dat JOSM het veel naar boven brengt bij validation, zet het maar eens op een overdekte 'bicycle parking' of op een amenity=parking (+parking_space). Maar uw lijst zijn idd de dingen waar je moet op overgaan als de kaart al redelijk compleet is. Mvg, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
maar dit gezegd zijnde: hoe geraken we aan de volledige lijst van straatnamen ? Voor het Brussels gewest en de Stad Gent hebben we die al ter beschikking. Agiv ! Daar staan alle officiele straten in. Ik vergelijk ook steeds met AGIV bij twijfel, en wat betreft straatnamen is de data compleet mijns inziens. Ik ben trouwens niet akkoord dat google veel beter is, als ik 'vogelzang 5, weerde' opzoek, dan doet Google maar een gokje waar die nummer is (ergens in het begin). In OSM is dit aanwezig en erop zoeken toont duidelijk dat hij de nummer vindt. Daarnaast heb je nog de google Easter Eggs, straten die niet bestaan, namen die opzettelijk verkeerd worden geschreven, gebouwen die er niet zijn, dit alles om mensen die de kaart los overkopieren te betrappen. Daar kan je dus niet echt op vertrouwen, het percentage is klein maar ze zijn er en ik heb er al persoonlijk ontdekt. Ik kan ook alvast zeggen dat 90% straatnamen in orde al heel veel is, als je de data gebruikt bv in nominatim. Ik heb nog een database van een dump uit 2007 staan. Naast het feit dat de postcode's er toen niet uitkwamen (en ik zelf een bijkomende modificatie heb gedaan met mijn eigen database van postcodes) was dit al vrij bruikbaar voor productiedoeleinden. Als ik vandaag een nominatim server zou opzetten komen daar ook huisnummers uit, en huisnummers die kloppen met de realiteit. Ik zou anders wel eens locaties willen weten waar er echt straatnamen ontbreken (en mss zelfs de straten). met OverPass API is het gemakkelijk om straatnamen te dumpen uit OSM per gemeente, op de nominatim mailing lijst passeerde er een tijd geleden ook een script om dit recht uit de postgresql databases te trekken. Ik persoonlijk vind toch dat we meer moeten overgaan naar AssociatedStreet relations ipv individuele tagging, ik heb ooit anders geadviseerd ivm geocoding (alweer nominatim dus) en resultaten maar na redelijk wat research in de nominatim code ben ik van mening dat we die richting beter uitgaan met nieuwe data (ik zou de oude niet aanpassen) want het lijkt mij dat dit toch meer word gebruikt omwille van performance word er niet achter een gebouw gezocht bij dit proces. Google hun map is verre van beter, en wat nog erger is, vreselijk vertraagd op vele vlakken, het nieuwe klaverblad constructie bv op R6 (Mechelen) heb ik bijna 2 jaar in OSM gestoken voor het tevoorschijn kwam in Google (de satelliet foto's waren wel recenter aangezien de aanbouw erop stond). Sinds kort is het gemakkelijker om fixes op Google Maps te doen, maar dit is jaren een pijnlijk en traag proces geweest om fouten te laten fixen, pas toen streetview erbij kwam hebben ze wat van die schade ingehaald. 'Beter dan ' is ook vrij relatief denk ik, er zit veel meer in OSM dan er op de kaart uitkomt, dankzij taggers die de extra mile doen. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
Ik ben het zelf ook eens met de associatedstreet-relatie-manier. Het zou beter zijn dat dit op deze manier kan gebeuren maar is het niet beter om eerste prioriteit te geven om de adressen effectief gemapt te krijgen? Ja idd, zoals ik zei: laat wat er staat vooral staan, geen prioriteit. Gewoon gezond verstand gebruiken, voor die ene extra huisnummer gaan we niet alles in de straat in relatie steken. Gewoon addr:* taggen die node/building en vooruitgaan. Het probleem is dat ik moeilijk aan een nieuwe mapper kan uitleggen waarom je een relatie moet gebruiken. Een huisnummer/adres toevoegen zou eenvoudig en snel moeten kunnen. Ben ik mee akkoord, ik zou voorstellen: doe wat je kan, het is altijd beter dan niets in te geven, en we mogen nooit vergeten dat we niet mappen voor een tool, er zijn meerdere toepassing waar AssociatedStreet wordt gebruikt dan geocoding alleen dus de preferentie is niet alleen uit oogpunt van nominatim te verklaren. Ik heb al android tools gezien die ervan gebruik maken. Naar mijn mening moet een nominatim ook maar omkunnen met deze data. OSM zal altijd een beetje anarchie zijn op dit vlak maar zolang hier geen tegenstrijdigheden in zitten zodat tools de data duidelijk kunnen interpreteren heb ik daar weinig problemen mee. Nominatim gebruikt die data wel hoor, maar pas als het niets anders vind ivm relaties/ways etc. Wat nominatim niet doet is node's zoeken met addr:* keys op. Dus maw, alle nodes doorzoeken op hun addr:streetname , nominatim haalt de straatnaam van de way zelf en niet de buildings in de buurt. Maar de huisnummer komt natuurlijk wel vandaar. Het is vrij cpu-I/O expensive om op die manier diep te gaan in de data. Zonder die anarchie had OSM nooit geweest wat het is vandaag hee. Zonder zoveel data in OSM had dit nooit een probleem geweest, maar nu er zoveel inzit is dit een ander verhaal. Gewoon doen wat je kan, bij twijfel is deze mailing lijst er nog voor hulp. De wiki is zeker niet zaligmakend, op de general OSM talk lijst is er deze week nog zo'n stelling gemaakt dat de wiki soms ook achter staat en dan is het gevaarlijk die als bijbel te gaan gebruiken. Wat we nu al vrij goed doen zijn die 'peer-reviews' en 'zone-watchdogs' , zo heeft Marc het probleem uit de subject naar boven kunnen brengen en is er gereageerd geweest, ik vind dat dit goed werkt dat bepaalde zones worden in het oog gehouden door individu's. We zouden het iets meer moeten coordineren zodat er geen blackspots ontstaan, mss zelfs automatiseren, er zijn al veel online sites/tools die ons kunnen helpen hiermee. Ik wil best een site hosten waar we hiervan een overzicht kunnen geven in 1 oogopslag zou je moeten zien waar er is gewerkt. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Openbaar vervoer in Vlaanderen
On 06/28/2013 02:02 PM, Jo wrote: Idem probleem met openbaar vervoer. Probeer eerst alle bushaltes te mappen en ga niet verder in detail. Google deed dat wel (zie de mooie site van de Lijn). Het schandalige hier is dat google die data soms op een zilveren plateau krijgt van bepaalde instanties, terwijl OSM moet ploeteren en smeken. Google lacht zich daar een breuk mee want die data brengt wel degelijk centjes op. Geef me nog een paar maanden en alle haltes van De Lijn zitten in Openstreetmap. Wat niet onbelangrijk is, is dat er ook een systeem op poten zal staan waarmee we deze data up to date kunnen houden. Ik wil ze er echter niet zonder meer ingooien. Voor elke halte die ik toevoeg kijk ik de positie na op de luchtfoto's. Dat is niet altijd mogelijk, maar waar er een B U S-markering of een bushokje aanwezig is, kan het wel. Als ik op de luchtfoto duidelijk kan zien dat er een platform is, dan zet ik dat er ook bij. Het blijft echter belangrijk om de bushaltes te blijven surveyen. Staan ze op de correcte plaats? ref, name en route_ref zijn waarschijnlijk wel correct. Maar bank, vuilbak, noppentegels en verhoogd platform voor rolstoelen, dat zit niet in data en het is ook niet te zien op de luchtfoto's. 2 weken geleden was hier niets te zien, wat openbaar vervoer betreft: http://www.openstreetmap.org/?lat=50.7955lon=3.7819zoom=12layers=T Nu is het volledig, belbussen en al. Vreemd genoeg heb ik daar geen schoolbussen gevonden en slechts 1 marktbus. Oost-Vlaanderen heb ik eerst gedaan, omdat het eenvoudig was om de zones te destilleren uit de PDF-bestanden van de belbussen. Nu werk ik me doorheen de provincie van Zuid naar Noord. Mooi werk van jou Jo, ben danig onder de indruk van het resultaat van uw gedrevenheid. Mij krijg je nog niet op een bus :) Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
On 06/26/2013 10:37 PM, Ivo De Broeck wrote: Ik vindt het goed dat deze discussie ven in talk-be ff komt. imho schrikt deze talk-be heel wat nieuwe vrijwilligers af. We hebben in Lier bv wel iets bereikt door how-to-map-a in het Nederlands te vertalen. En nogmaals, dit is geen kritiek op de kleine groep super gemotiveerde mensen die hier tientallen (lange) posts plaatsen in het engels. Maar misschien moet ook eens gedacht worden aan het rekruteren en begeleiden van nieuwe (niet IT) mensen. Volgens mij werkt de persoonlijke aanpak het beste, ik heb bv 'fransvm' aangesproken op de problemen en een prima reactie van hem gekregen, de boodschap die Ben stuurt ga ik ook gebruiken in de toekomst. Die persoon is van goede wil, en ik denk dat de meeste contributers dat wel zijn. Wat ik heel veel hoor is dat bv Jo zijn persoonlijke sessies heel wat resultaat leveren. Misschien is een soort peter/meterschap wel een idee, mensen die bereid zijn om wat tijd te investeren in anderen zouden zich kandidaat kunnen stellen. Zoals steeds is bij de meeste mensen steeds een probleem van 'tijd hebben'. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Interessant OSM artikel over HOT (Haiti)
Dit geeft mss wat ideeen over hoe ze leden werven in gebieden waar ze geen tijd hebben om over voertalen te discussieren: https://medium.com/medium-for-haiti/f4582ed41656 Weliswaar in het engels. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
On 06/25/2013 06:07 AM, Georges De Gruyter wrote: ... They should forbid people to edit with potlatch... They = the openstreetmap police ? ;-) Vrees dat het niet enkel van Potlatch afhangt of mappers al dan niet fouten maken It's called humor, never forget to laugh! But on a more serious note, everyone can dive in without even knowing the correct tags, potlatch makes that possible, for JOSM, one needs to get to know it first. Big difference I think between the 2. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
On 06/25/2013 05:31 AM, Marc Gemis wrote: For bomputten one could use historic=bomb_crater, but only when it has some historic value (e.g. when it's marked with an information board). I'm still under the impression that historic=battlefield is not meant for each individual bunker or bomb. The typical example in Belgium would be Waterloo. The trenches in the Westhoek would also fall in this category. They are definitely not historic, in fact, they are a nature reserve and are protected now, so it would not be appropriate since there is no real historic value, the story about those craters is explained at the entrance of the reserve I think to remember. But that's all there is to it. I did seem to think I saw most bunkers being marked correctly, so without battlefield tag. But I didn't check with JOSM directly. Just marking it as a bunker is fine but the battlefield tag is most probably overkill. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] amenity on relation of widespread nodes
Hi everyone, Been looking at this relation today : 271476 ( see http://www.openstreetmap.org/browse/relation/271476 ) It has an amenity set, but these points are widely spread out, I think this goes against the intended idea behind amenity's. Any comments ? Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
The Eppegem cemetary is like 1200 meters from my doorstep, I never saw a battlefield reference on the cemetary. Whats worse is , in his other edits he's adding parking space where I've already done all the parking space around. user has 5 edits on his name: http://www.openstreetmap.org/user/fransvm I'm originally from Bonheiden, so I'll take a look there too after I see what has been done here. Glenn On 06/24/2013 09:37 PM, Marc Gemis wrote: I'm interested in the usage of historic=battlefield. I saw that someone added this to e.g. to a cemetery in Eppegem (Zemst) http://www.openstreetmap.org/browse/node/2308368137 There are also a lot of those tags around Bonheiden - Rijmenam - Keerbergen: http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=13lat=51.00577lon=4.56379layers=BFT Are these really battlefields or are they bunkers, cemeteries (something else) ? Can the tag (http://wiki.openstreetmap.org/wiki/Tag:historic%3Dbattlefield ) also be used for those purposes ? regards m ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
I really tried but he sure pissed me off. I fixed everything he did wrong, he's thinking: Hey, it's a military cemetary (it is ...) so lets add a node smack in the middle and call it: historic=battlefield. He uses amenity=kindergarten to mark leisure=playground. He also deleted information on a building ( amenity=doctor ) I personally added. He also managed to disconnect ways in order to add 1 footway. Also parking nodes, placed over parking ways (which I put there ages ago). So he's not even looking at what is there. Luckily he only did 5 changesets. So clearly a beginner. They should forbid people to edit with potlatch. I actually already fixed 2 of his mistakes few days ago in my .be overhaul on the designation key, which is totally cleaned up now. Glenn On 06/24/2013 10:00 PM, Jo wrote: Please be gentle when explaining him where he goes wrong :-) We need all the fresh blood, I mean mappers we can get... Jo 2013/6/24 Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be The Eppegem cemetary is like 1200 meters from my doorstep, I never saw a battlefield reference on the cemetary. Whats worse is , in his other edits he's adding parking space where I've already done all the parking space around. user has 5 edits on his name: http://www.openstreetmap.org/user/fransvm I'm originally from Bonheiden, so I'll take a look there too after I see what has been done here. Glenn On 06/24/2013 09:37 PM, Marc Gemis wrote: I'm interested in the usage of historic=battlefield. I saw that someone added this to e.g. to a cemetery in Eppegem (Zemst) http://www.openstreetmap.org/browse/node/2308368137 There are also a lot of those tags around Bonheiden - Rijmenam - Keerbergen: http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=13lat=51.00577lon=4.56379layers=BFT Are these really battlefields or are they bunkers, cemeteries (something else) ? Can the tag (http://wiki.openstreetmap.org/wiki/Tag:historic%3Dbattlefield ) also be used for those purposes ? regards m ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] amenity on relation of widespread nodes
Indeed, I aggree. Dropping the amenity would probably be enough I think. If you take it a step further, I don't even see where amenity is allowed on a relation checking the wiki (bear in mind I made 2 of those myself which I'm reconsidering right now) So stricto senso, it's not allowed, furthermore an amenity is a interesting place I would want to go to, so it needs to stay concentrated to a local area. You're right about the network relation too Marc, That's probably what they need. Glenn On 06/24/2013 09:16 PM, Marc Gemis wrote: The wiki clearly describes that the relation=network should be used to combine routes (walking, bus, ...) together. see http://wiki.openstreetmap.org/wiki/Relations/Proposed/Network This network groups together single nodes. That's outside the scope. From a database design viewpoint, I understand that one wants to normalize common attributes in a separate table. However, this is not the way most things are done in OSM. We do not create a network of Shell-tankstations, McDonalds restaurants or BMW-dealers. I would contact the mapper and ask him on which basis he thinks that we should create relations like this. regards m On Mon, Jun 24, 2013 at 2:21 PM, Glenn Plas gl...@byte-consult.be mailto:gl...@byte-consult.be wrote: Hi everyone, Been looking at this relation today : 271476 ( see http://www.openstreetmap.org/browse/relation/271476 ) It has an amenity set, but these points are widely spread out, I think this goes against the intended idea behind amenity's. Any comments ? Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] historic=battlefield
There are also a lot of those tags around Bonheiden - Rijmenam - Keerbergen: http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=13lat=51.00577lon=4.56379layers=BFT concerning these, I think this user is correct, that's the area I grew up in and it's packed with bunkers, the locations seem ok tool I'm pretty sure some of these where battlefields. There are places we called 'bomputten' , they have water in it now and are a primary place for aquatic life, so I would say battlefield , most of those places definitely are, but as for the fact if they are historic, I'm not too sure. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] designation key
On 06/20/2013 03:35 PM, Marc Gemis wrote: I am under the impression that the designation key is misused a lot in Belgium. It's used for descriptions, notes, names, etc. (see http://overpass-turbo.eu/s/nW ) It's hardly used for its intended purpose: The tag designation=* is used to record the legal classification of a way. (see http://wiki.openstreetmap.org/wiki/Key:designation UK-only ?.) Or is there another definition/use of designation that I'm not aware of ? You're right about the use, I even see I misused it myself in my first edits even thought I understand the use as described now. So, I'm correcting now. tx for the overpass query, makes it easy to fix this. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] designation key
On 06/21/2013 09:12 AM, Glenn Plas wrote: On 06/20/2013 03:35 PM, Marc Gemis wrote: I am under the impression that the designation key is misused a lot in Belgium. It's used for descriptions, notes, names, etc. (see http://overpass-turbo.eu/s/nW ) It's hardly used for its intended purpose: The tag designation=* is used to record the legal classification of a way. (see http://wiki.openstreetmap.org/wiki/Key:designation UK-only ?.) Or is there another definition/use of designation that I'm not aware of ? You're right about the use, I even see I misused it myself in my first edits even thought I understand the use as described now. So, I'm correcting now. tx for the overpass query, makes it easy to fix this. I fixed some (see changeset http://www.openstreetmap.org/browse/changeset/16639881 ). There is some info that you just can't throw away to fix the tag use, I tried selecting appropriate keys(most work was re-keying the info) to keys like operator, name, note or ref. For example : the airport buildings used designation to put some interesting information on the buildings and it differs from the already chosen name , see http://www.openstreetmap.org/browse/way/136459078 . I parked that info in 'ref' keys. Some information you just need to get rid of as it duplicates other keys. There are a few in that bbox that I left alone, there is node 1858449632. Someone with more experience on 'archeological' tagging than me should do this. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] designation key
Did some more fixes, I've adapted your Overpass query to limit the result set to belgium: http://overpass-turbo.eu/s/ow It's too big to export belgium but it displays fine. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Inventarisatie Trage Wegen
Hi everyone, It's seems that our municipality is asking for some public mapping aid of some sort. Please check this page, I would love to bring OpenStreetMaps to their attention, I have a feeling that they aren't even aware of it's existence looking at the sort of help they ask for. http://zemst.be/nl/press/319/inventarisatie-trage-wegen.html references are made to check this site although no hyperlinks in the statement, here it is : http://www.tragewegen.be/ The latter site is extremely slow at the moment. I've noticed some screenshots of OSM maps are being used there. Do you think we can/should/want to be a part of this as a community? If so, I believe we should join efforts then and send some well written inviting mail to bring OSM to their attention?It would probably save a lot of work for lots of people involved. Does anyone have some 'canned' response to these types of initiatives? What always bothers me about most of these initiatives is that they usually 'give up' the data to Google for free so they in turn can start charging for it (commercially). All the while OSM would be such a perfect fit as a tool by itself. Please share your ideas, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Nominatim administrative boundaries
Kurt (a.o), I checked the Rotselaar/Werchter setup and I made a single change to the Rotselaar relation: http://www.openstreetmap.org/browse/relation/214462 The only thing I think was missing is adding the Werchter boundary relation as a 'subarea' to the Rotselaar one. Did the same setup for Rijmenam/Bonheiden. There aren't many 'fusiegemeentes' being mapped -unfortunately- although it would be highly interesting to have them, not only from a nominatim (search) point of view, but also for addressing in general. The change I made will probably trigger some changes in the nominatim search result in a few days , I now expect that Leuven will be replaced by Rotselaar in the search result set when looking up Werchter in a few days. regards, Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Nominatim administrative boundaries
Don't think it'll make nominatim process it differently; it gets it input from the admin_level and adds each different admin_level to the list it shows (9 = Werchter, 8 = Rotselaar, 7 = Leuven, 6 = Vlaams Brabant, 4 = Flanders, 2 = Belgium. Btw, you don't have to wait a few days for it to update, it updates a few minutes after uploading your edits. That's the theory indeed minute diffs, I know all about them... but there is serious lag sometimes for nominatim, they have a nice lag graph somewhere. I love to be on the safe side when making claims I have no influence over :) The difference now is that Werchter is not 'standalone' anymore, being made part of something. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Nominatim administrative boundaries
On 06/16/2013 07:14 PM, Daan Bellefroid wrote: Oops sorry was looking at Rotselaar Everything OK ;- No problem, made me double-double the check, it's always possible I made a mistake clicking back and forth and using copy/paste ninja techniques ;-) I feel like we should add all of them 'Fusiegemeentes' , they is almost no other source of information that gathers them all, noone really knows, Google maps is as clueless as it gets too, some borders are very strange (Werchter for example at google looks like they only took the 'bebouwde kom'). ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
