Re: [OSM-talk] OsmAnd audio files and JOSM
Photos taken on the same track have correct date/time and display correctly in JOSM. Really? I couldn't get this to work reliably and posted a question about this November last year: https://lists.openstreetmap.org/pipermail/talk/2013-November/068446.html In my case it didn't work because the photo's themselves did not always get geotagged. The correct location however is recorded in the track as a waypoint as you stated earlier. My camera settings are set to geotag pictures but I suspect this doesn't always work when I flip out my phone without already having a gps fix. My guess is that OsmAnd won't record the waypoint until the fix is there, whilst the picture might have already been taken before the fix. So the fact that your pictures show up correctly in JOSM is maybe just because your pictures ARE all correctly geotagged by your camera and has nothing to do with OsmAnds waypoints. The waypoints in OsmAnds track refer to the picture, audio or video by (file)name. And my understanding is (was?, I haven't checked recently) that JOSM will not use that info to place OsmAnds notes in the correct location. Of course things change and could be different for the different kind of notes. Is it possible to geotag audio files? Kind regards, Lambert Carsten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geotag OsmAnd picture notes
Thanks Rob. Viking is a really great, I use it regularly. My current Linux systems are too old to install version 1.5 right now without pulling in a lot of dependencies that might break things. I tried the Windows version as a workaround (wine and Win8) but it refuses to 'open/import' the jpg files. I will look at it again when I have updated to a more current Linux system so thanks for the tip. Lambert On Sat, 2 Nov 2013 00:48:04 + Robert Norris rw_nor...@hotmail.com wrote: The thing is I need a way to use the geolocation that OsmAnd has recorded in the gpx file (in the waypoints corresponding to the pictures). I wasn't doing any tracking when I noticed that things had changed quite a lot at a certain location. Normally I would have my gps logger and a camera and use the process you describe. It turns out the pictures ARE geotagged. Some are fine but some are way off. The info recorded in the OsmAnd gpx file is correct and is what I want to use. Maybe I need to strip the existing geotags before Josm or some other program will look into OsmAnd's file and use it's data. But GPS-correlate that I would use for this, has disappeared so I first need to find a replacement for that. I would the use the program Viking: http://sourceforge.net/projects/viking Mind you I would say that, since I'm now the lead writer / maintainer of it. I used to use gps-correlate but then I wrote the geotagging support in Viking. It has the ability to overwrite existing Geotag data in the file (you will have to turn on this option in the geotagging process). The latest Viking version 1.5 also has the ability to Geotag images to a Waypoint's position. HTH. Be Seeing You - Rob. If at first you don't succeed, then skydiving isn't for you. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geotag OsmAnd picture notes
On Sun, 3 Nov 2013 18:44:10 +0900 Andrew Errington erringt...@gmail.com wrote: So, if you have a GPX file, and a bunch of correctly timestamped photos, won't this do what you want? Normally yes but here the lat/lon belonging to a picture is recorded as a waypoint in the gpx file by OsmAnd. The waypoint records the lat/lon, the picture name and an inaccurate time. Josm seems to only be able to use timestamps to do the correlation, not the filenames (recorded in the waypoint). Lambert ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Geotag OsmAnd picture notes
Hi, OsmAnd has become increasingly useful to me whilst mapping so I am using it more and more. Recently I came across an area that needs to be fixed because it has changed considerably. I used a feature in OsmAnd I hadn't tried yet and took several 'picture notes' which are all nicely pinpointed at the right location within OsmAnd. The pictures themselves however are not geotagged, so I cannot use them directly in JOSM. The geolocation info is stored in the XML file (*.gpx) using waypoints. Does anyone know of a simple script to write the geolocation info to the pictures themselves using OsmAnd's gpx file? I did Google around a bit but found nothing including OsmAnd project site. Just to avoid confusion, the geolocation information for the 'notes' (pictures, audio, video) in OsmAnd's gpx file is NOT done using the time stamp. Therefor those utilities to geotag pictures using a track and the time stamps don't work here. Here is an excerpt of how the info is recorded in the gpx file: wpt lat=52.3621917 lon=4.838233 name0...@qlv8---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.3621917 lon=4.8383188 name0...@qlxc---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.3622561 lon=4.8381257 name0...@qoas---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.362653 lon=4.8381257 name0...@qord---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.362653 lon=4.8381257 name0...@qord---2.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.3628783 lon=4.837954 name0E4@q...@w---1.jpg/name time2013-10-31T08:44:22Z/time /wpt (As you can see the time info is the same for several pictures at different locations.) Sadly I am not a programmer other than some very simple bash scripts. But this does not seem to need extensive programming skills. Anyone already solved this and care to share their script? Thanks, Lambert Carsten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geotag OsmAnd picture notes
Thanks Peter. The thing is I need a way to use the geolocation that OsmAnd has recorded in the gpx file (in the waypoints corresponding to the pictures). I wasn't doing any tracking when I noticed that things had changed quite a lot at a certain location. Normally I would have my gps logger and a camera and use the process you describe. It turns out the pictures ARE geotagged. Some are fine but some are way off. The info recorded in the OsmAnd gpx file is correct and is what I want to use. Maybe I need to strip the existing geotags before Josm or some other program will look into OsmAnd's file and use it's data. But GPS-correlate that I would use for this, has disappeared so I first need to find a replacement for that. Basically I need a simple script that will go through the pictures (for i in *.jpg do ...), parse the given OsmAnd gpx file for the geolocation, and then write that info to the picture using exiftool. I don't have the expertise nor time to figure out how to extract the info from the gpx file correctly so it can be passed on to exiftool. Kind regards, Lambert On Fri, 01 Nov 2013 11:24:47 +0100 Peter Wendorff wendo...@uni-paderborn.de wrote: Hi Lambert, If I remember right JOSM is very nice in this area: If you open a gpx file with timecodes at the points and images that are time-coded (file-creation time), JOSM matches them together and shows the image at the coordinate along the gpx at the corresponding time. Of course for that to work properly the times have to be in sync, but if you use osmand to do both - log the GPX and take the picture - this should be the case automatically (be careful when combining a camera with a smartphone) regards Peter Am 01.11.2013 10:52, schrieb Lambert Carsten: Hi, OsmAnd has become increasingly useful to me whilst mapping so I am using it more and more. Recently I came across an area that needs to be fixed because it has changed considerably. I used a feature in OsmAnd I hadn't tried yet and took several 'picture notes' which are all nicely pinpointed at the right location within OsmAnd. The pictures themselves however are not geotagged, so I cannot use them directly in JOSM. The geolocation info is stored in the XML file (*.gpx) using waypoints. Does anyone know of a simple script to write the geolocation info to the pictures themselves using OsmAnd's gpx file? I did Google around a bit but found nothing including OsmAnd project site. Just to avoid confusion, the geolocation information for the 'notes' (pictures, audio, video) in OsmAnd's gpx file is NOT done using the time stamp. Therefor those utilities to geotag pictures using a track and the time stamps don't work here. Here is an excerpt of how the info is recorded in the gpx file: wpt lat=52.3621917 lon=4.838233 name0...@qlv8---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.3621917 lon=4.8383188 name0...@qlxc---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.3622561 lon=4.8381257 name0...@qoas---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.362653 lon=4.8381257 name0...@qord---1.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.362653 lon=4.8381257 name0...@qord---2.jpg/name time2013-10-31T08:44:22Z/time /wpt wpt lat=52.3628783 lon=4.837954 name0E4@q...@w---1.jpg/name time2013-10-31T08:44:22Z/time /wpt (As you can see the time info is the same for several pictures at different locations.) Sadly I am not a programmer other than some very simple bash scripts. But this does not seem to need extensive programming skills. Anyone already solved this and care to share their script? Thanks, Lambert Carsten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geotag OsmAnd picture notes
Maybe I need to strip the existing geotags before Josm or some other program will look into OsmAnd's file and use it's data. But GPS-correlate that I would use for this, has disappeared so I first need to find a replacement for that. Well that was easy: for i in *.jpg;do exiftool -gps:all= $i;done Sadly Josm cannot handle OsmAnd's waypoint coördinates and doesn't geolocate the pictures. Lambert ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] adres nummers, BAG straatnaam
Hoi, Gisteren kwam ik op een plek(1) waar opslag garages worden gebouwd. Het zit daar naar ik begrijp ingewikkeld in elkaar wat betreft de adressering dus wilde ik dat correct invoeren in openstreetmap. Ik ben begonnen wat adres gegevens per gebouw in te voeren met behulp van de BAG gegevens zodat de gebouwen zelf tenminste een correct adres krijgen. Naar aanleiding hiervan heb ik een aantal vragen waar ik zelf niet uitkom: -Straatnaam- Volgens de BAG gegevens heet de straat 1e Tochtweg (en dus niet Eerste Tochtweg). De afkortingen lijst(2) bevat geen afkortingen hiervoor en overal staat bij implemented: not yet. De wiki(3) geeft aan dat de straatnaam borden (afgezien van fouten) beslissend is. Tegelijkertijd moet de tag addr:street een naam bevatten die ergens in de buurt gevonden wordt. Als ik wat zoek opdrachten doe bij Openstreetmap, Project-OSRM en in JOSM wordt het mij niet duidelijk in hoeverre'1e'='Eerste'='eerste' en of de inhoud van de keys hierop invloed heeft. Moet de registratie in de BAG niet beslissend zijn/worden(4)? In dit geval dus de straat hernoemen naar 1e Tochtweg? Is het beter of aan te raden alt_name te gebruiken? En is het NWB bestand eenvoudig op dit soort vragen te raadplegen? Ik kom er niet achter m.b.v. Google. Doet die afkortingen lijst(2) iets? Zo ja, hoe waar dan? In de database, in de api, of alleen de wiki. Anders gezegd: hoe moet ik als mapper hiermee rekening houden? -Nummering- Het is mij niet duidelijk of het '13a-d' moet zijn of '13a-13d' (met toevoeging van 'addr:interpolation=alphabetic'). Het gebouw 'de Zuidplas' heeft drie letters (e, f en g) en een stuk of 30 nummers. Wordt het dan '13e1-30;13f1-30;13g1-30' (of '13e1-13e30;g1-13f30;13g1-13f30') met de toevoeging 'addr:interpolation=all' ? Met vriendelijke groeten, Lambert Carsten 1-http://www.openstreetmap.org/?lat=51.982036lon=4.613469zoom=18layers=M 2-http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Nederlands_-_Dutch 3-http://wiki.openstreetmap.org/wiki/NL:Key:name#Afkorting_.28doe_het_niet.29 4-http://lists.openstreetmap.org/pipermail/talk-nl/2012-January/013723.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Jerusalem name tag - Mediation
Hi, This proposal is well considered and it could work in my view. Even though it's a compromise (vs. solution) in the sense that it solves a rendering 'problem', it doesn't compromise the tagging rules/principles to that end. Of course it's the local mapping community that will have to make the decision to agree to this or not. I only entered the discussion when I thought I could help move the discussion forward. By the way I don't believe the DWG acted irrationally. However their decision wasn't the best and my goal wasn't to point a finger at them but to point out a mistake so it could be corrected. On a personal level I have huge appreciation for them. And I also like the 7 day time limit. Lambert Carsten On Fri, 7 Oct 2011 16:40:18 +0100 Andy Robinson ajrli...@gmail.com wrote: In addition to the talk list and the DWG this email is being sent to those who have edited the name tag on node 29090735. Those reading the mailing list and forum will know that there is an on-going dispute between Israeli and Palestinian folks as well as unhappiness with the OSMF DWG. All relates to the name=tag for Jerusalem, the default name tag shown by the project mapnik rendering. The facts are clear that a tit for tat dispute of the name tag went on during 2009 and 2010. Also fact is that some discussions were held between mappers in the region to try and reach an agreed position. It was unfortunate that the DWG removed the name tag from the node around the same time, before the views of those discussing the point could communicate back. Regardless of this it is clear that there is no full 100% agreement between the local groups or even within each side. There have been discussions about two nodes, each holding information separately in Hebrew and Arabic, and there have also been suggestions of returning to a single node with Arabic, Hebrew (and English) names on it considering the international interest in the city. Both might work but nether offers a sustainable solution long term, mainly because as new mappers come and go the view of different individuals will change, and so it will be also for those viewing the map. I was asked to help mediate in the dispute. Something that I have found almost impossible as there is no basis on which to force mediation in the first place. I have however looked at the matter and offer the following for consideration and I would hope implementation. It must be recognised that no solution will be perfect. 1. All cities of the world have a varying demographic. Few have only one language or faith. Jerusalem has a population of over 700,000 and by all accounts the religious split of its people (ignoring minority groups) is in the order of 2/3 Jewish, 1/3 Arabic. Therefore a significant number of people will be served by having the name of Jerusalem visible in Hebrew and also in Arabic. English might be useful addition for the international interest in the city but that can be argued for all major cities around the world and therefore I don't see reason to include it in this solution. As with all other languages the language specific name tags are always available anyway. 2. There appear to be three choices for the number of nodes. One node to reflect the whole of the city, two nodes to reflect east and west, or three nodes to reflect both of the above. I'm going to suggest the latter, three nodes as follows: Node 1: With the name in Hebrew and Arabic (in that order to reflect the demographic). Since I believe all of Jerusalem considers it to be the capital, it can have the capital tag as well as the place=city tag. This is what most viewing a zoomed out view would see on the default mapnik rendered tiles. No is_in tag would be added to avoid the political connotations, though a note (in English) would be added to reflect why this tag is missing. This node would carry all the international language specific name tags for Jerusalem as well as any other data that is factually correct and applicable for the city as a whole. Nodes 2 and 3: These would be created and maintained by each respective group. They would be placed to the east and west of Node 1. These nodes would not use either the capital nor the city tag but would instead reflect the east and west sector (suburb). The is_in tag would be controlled and decided upon by the respective group. Other tags would be as decided upon by the relevant group but must maintain the on-the-ground approach of factual data. DWG will continue to monitor but only to support the process of maintaining the agreed solution. Finally, I was encouraged that at the start of the discussion process the local mappers met and debated the issues. I would wish and strongly urge this to continue. It will only be through further communication and dialogue that differences will be understood. This needs to keep to one side the politics and beliefs and focus on what the wider
Re: [OSM-talk] Naming dispute over Jerusalem - OSM failure
On Wed, 5 Oct 2011 23:04:02 +0100 Andy Robinson ajrli...@gmail.com wrote: Mediation currently appears problematic because only one side of the discussion is present. Ideally I'd like to see a joint statement from the two sides (the local mappers) that states what the difference(s) of position are. If it can't be joint then at least two separate statements. At the moment we have one side making a lot of noise only which means there is no practical route to mediation presently. Is it correct that this all started with the now silent 'other side' asking the DWG to step in? In that case maybe the DWG should revert their 'name removal decision' and let the local mappers continue the way things were before. The silent side can always decide to speak up in which case you will have something to mediate. Can we even speak of a dispute if one party is absent? I still think the real dispute is about the name tag and they just want it back, as do I. Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming dispute over Jerusalem - OSM failure
On Wed, 05 Oct 2011 08:42:13 +0200 Frederik Ramm frede...@remote.org wrote: , the node will either remain nameless, or it will have both a Hebrew and Arab name combined in the name tag. This suggestion was met with either silence or attempts to drag us into a political disussion, which we refused. As an outsider I really don't understand this. Is there a dispute on what can be considered the local language in Jerusalem? http://wiki.openstreetmap.org/wiki/Key:name : The default name (occupying the 'name' tag without suffix) should be the name in whatever language is used locally. Personally I would say: '.. OFFICIALLY used locally.' See for example Brussels where the name tags have both Dutch and French names and as suggested here by the DWG. If Hebrew is the (official) local language this is not a tagging issue but a rendering one as others have noted and in that case the combined name tag would be 'wrong' (IMHO). Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming dispute over Jerusalem - OSM failure
On Wed, 5 Oct 2011 12:47:52 +0200 Pieren pier...@gmail.com wrote: On Wed, Oct 5, 2011 at 11:14 AM, Lambert Carsten lhc@solcon.nl wrote: As an outsider I really don't understand this. Is there a dispute on what can be considered the local language in Jerusalem? Yes, it is. And this happens on some other areas in the world. The answer just saying set up your own tile server is not working because the main Mapnik rendering is used as am international reference, whatever we like it or not. Understood, but the route taken now by the DWG is to convert a rendering dispute to a tagging dispute effectively changing the parties to the dispute from a local community to a dispute between the DWG and one local community. Obviously in the main Mapnik rendering we need to be able to switch languages. I wish it were so but I can't do it so I will just have to wait until someone who can gets around to implementing that option. We are all volunteers after all. The other answer saying please find an agreement locally or keep the name empty is also not acceptable impov. This type of answer will not satisfy the two local communities, neither the rest of the world. Perhaps the solution adopted by the belgians for their disputed areas could be used as a model: put both versions in the tag 'name' (as Frederik already suggested). Another way would be to check how the UN is handling this on their own maps... To my knowledge both Dutch and French are official languages in Brussels. So if the local community there cannot agree on one or the other OSM needs to accept both versions in one name tag. As I understand it Jerusalem as the capital of Israel is not accepted by everybody in the international community. However Israel has effective control over the city in the sense that there is no other authority that can claim international acceptance for that position. And I am trying to stick to facts here, which is what OSM is all about. So please point out any mistaken facts on my part. On Wed, 5 Oct 2011 10:27:32 +0100 Ed Loach e...@loach.me.uk wrote: Personally I would say: '.. OFFICIALLY used locally.' Which is where it becomes political... Do you mean officially according to Israel? Or official according to international resolutions such as http://en.wikipedia.org/wiki/United_Nations_General_Assembly_Resolution_194 (see also http://en.wikipedia.org/wiki/Jerusalem#Political_status ) (Note: I'm not taking sides in all this, but didn't realise there was such a political aspect to Jerusalem until doing a bit of research and thought the above made interesting reading for those not aware of the history involved. Disclaimer: I'm not saying Wikipedia is a reliable source). Agreed, that's political and therefore would need to be resolved outside OSM. In this case that would mean a dispute about the capital=yes tag though. However the dispute Dmitry brought to our attention is about a decision made by the DWG. Their position seems to be to agree with anything the local mappers agree to. Few seem to regard that as viable but more importantly it is not the whole story. The rest of the community has a say too! In my opinion we have at least two relevant osm rules here: -we don't tag for the renderer; -the name tag holds the (IMHO: 'official') local name. The statement by Frederik seems to contradict both these 'rules'. I think we could help resolve this issue if we can determine if these rules hold true or not. Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming dispute over Jerusalem - OSM failure
On Wed, 5 Oct 2011 09:52:06 -0400 Serge Wroclawski emac...@gmail.com wrote: On Wed, Oct 5, 2011 at 9:25 AM, Lambert Carsten lhc@solcon.nl wrote: On Wed, 5 Oct 2011 12:47:52 +0200 However the dispute Dmitry brought to our attention is about a decision made by the DWG. Their position seems to be to agree with anything the local mappers agree to. Few seem to regard that as viable but more importantly it is not the whole story. The rest of the community has a say too! In my opinion we have at least two relevant osm rules here: -we don't tag for the renderer; -the name tag holds the (IMHO: 'official') local name. The statement by Frederik seems to contradict both these 'rules'. I think we could help resolve this issue if we can determine if these rules hold true or not. I've largely stayed out of taking sides but I think one thing that's missing here which Dmitry tried to express is that the issue of local community in this case. ... Back to the point, I think the technical issues are too far away to solve. I think the political issues are too complex to address. In this case, I'd say that the DWG should be looking for consensus amongst active contributors, rather than the two parties, and all parties involved need to realize that this is just going to happen here, as it sometimes happens in other areas. - Serge Looking into the facts they seem to paint a different picture so here is what I have found: 1. According to Dmitry it was the East Jerusalem mappers (that) complained to OSM about the name tag on the Jerusalem node (not the Israeli mappers as Serge claims). Only the DWG can enlighten us on this. 2. There is relative little back and forth regarding the name tag of the Jerusalem node when I look through the history. Most of the time the name tag holds Jerusalem in Hebrew (there were more edits but these are the ones possibly relevant to this issue): -27 jul 2011 OSMF removed the name tag and added warning note -30 dec 2010 talkat reverted to Hebrew alone -29 dec 2010 beweta added 'Jerusalem' in front of the Hebrew version -23 june 2010 talkat put the name tag back -23 june 2010 abuammar48 removed the name tag -22 june 2010 talkat reverted to Hebrew alone -20 june 2010 Esperanza36 added the Arabic name in front of the Hebrew version -11 may 2009 talkat reverted to Hebrew alone -9 may 2009 Esperanza36 added English and Arabic after Hebrew -22 jan 2009 talkat reverted to Hebrew alone -19 jan 2009 Esperanza36 added the Arabic name in front of the Hebrew version. -Before that some 'normal' corrections/editing. None of these editors are 'newbies' with just one edit as Dmitry claims so it's unclear to me where that comes from. After the name tag removal bij OSMF user wikipod temporarily added the name tag with Arabic and Hebrew, probably later realising the 'issue' and removing it again. 3-The East Jerusalem node originally created in 2008, has had no back and forth on the name tag until OSMF removed it tag on 30 jul 2011. (Please add, correct or point to any relevant facts missing here.) To me it looks like the DWG has acted to fast in removing the node and by doing that made it look politically motivated: Their goal was to stay out of a perceived political feud, but by trying to stay out of a political feud that wasn't really there (in this case!), they actually made the decision politically motivated! Life ain't easy :) The facts in combination with OSM 'rules' (IMHO) points to a solution being the way it was before this became an issue. Looking for a solution through an agreement between the mappers is one of the last options we should look at, not one of the first (as seems to have happened here). Only if we cannot come to a conclusion using our rules and conventions should we look to resolve a conflict through a compromise. But keep in mind the real issue here (again IMHO) is the decision by the DWG to remove the name tag and forbid anyone adding it until the (other!) issue (between not clearly defined group of mappers) is resolved by them. Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming dispute over Jerusalem - OSM failure
On Wed, 5 Oct 2011 11:39:16 -0400 Serge Wroclawski emac...@gmail.com wrote: On Wed, Oct 5, 2011 at 11:30 AM, Pieren pier...@gmail.com wrote: On Wed, Oct 5, 2011 at 3:52 PM, Serge Wroclawski emac...@gmail.com wrote: I said that you can't get consensus from idle accounts. I like David's idea with the specific tag name:disputed. The status of Jerusalem as part of Israel is not disputed except by the same sort of people who might say that London is not the capital of the UK. The fact that some people don't like the situation doesn't change that. A disputed tag will result in many things being marked disputed. I can think of a bunch even in the US. I have to agree here. It also doesn't solve disputes about what is disputed. In other words it doesn't force parties to agree to disagree. And rightly so, sometimes (rarely I'll admit) people can be mistaken. :) Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Nieuwe website
Ook van mij heel veel complimenten. Fantastisch werk, overzichtelijk en begrijpelijk. Echt een site om iedereen met een gerust hart naar te verwijzen. Een technisch probleem dat mij opviel bij openstreetmap.nl die niet speelt bij openstreetmaps.nl is dat bij het inzoomen (Ctrl+wiel) van de pagina (dus niet op de kaart zélf in map mode) het venster gedeeltelijk buiten beeld valt onderaan. De scroll balk rechts komt wel tevoorschijn maar laat mij niet voldoende naar beneden scrollen. Probleem doet zich voor in Firefox en Opera op een Linux systeem. Dit bericht heb ik ook met screenshots verstuurd maar de 'moderator' moet die goedkeuren vanwege de grootte. Als die wordt geweigerd en er is toch behoefte aan ter verduidelijking dan stuur ik ze wel verschaald. m.vr.gr. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] webpagina
On Monday 17 August 2009 11:21:37 Lambertus wrote: Lambert Carsten wrote: On Monday 17 August 2009 10:05:17 Lambertus wrote: Hey wat is er mis met de enige opensource online routeplanner van OpenStreetMap die toevallig ook nog eens wereldwijde dekking heeft? Niets natuurlijk. Hoewel... gpx download voor langere routes gaat nog steeds niet, en via-points kan ook soms nuttig zijn. Ja, je vraagt er zelf om.. :) GPX download moet nog omgebouwd worden van HTTP GET naar POST zodat ook IE alle coordinaten kan opsturen naar de server. Iemand had aangeboden dit te doen maar heb er al lang niks van gehoord. Ja, wist ik, had je al gezegd. Maar die andere sites kunnen dat dus wel. ;) (IE ?? ik gebruik Firefox op Linux) Aan via's wordt gewerkt, ik heb al een werkend voorbeeld gezien. Het is nu nog vooral de UI die bijgewerkt moet worden. Ik kijk er naar uit. Bovendien dat is precies wat wij volgens mij willen, kunnen kiezen. Dat kan natuurlijk nu ook al maar de 'niet nerd' komt volgens mij veel te snel tot de conclusie dat openstreetmap.nl niet voor hen is. Volgens mij moeten wij dat niet willen, maar misschien is de overheersende opvatting dat wij nog rijp zijn voor jan en alleman. Moeten we naast CM en ORS ook een link naar maps.google en maps.live erbij gaan zetten? Nou nee, maar Garmin staat erbij en dat moet beslist zo blijven. Niet iedereen heeft een Garmin, ik in elk geval niet en die willen misschien toch online een route kunnen plannen. Cloudemade en Openrouteservice gebruiken net zoals jouw Garmin site en Yournavigation OSM materiaal en horen er daarom bij. En als Google maps OSM data zou gebruiken dan zouden we maar al te graag daarmee te koop lopen denk ik (en terecht). Ja wellicht is ORS en CM ook wel interessant om te linken, het was ook een beetje een plagerijtje van mij, vandaar de ;-) Tuurlijk, begreep ik heel goed. Maar het is ook zo dat we niet linken naar alle websites die kaartjes van OSM maken en mochten er 20 routeplanners zijn voor OSM dan hoeven we die ook niet allemaal te linken. Een keus voor een redelijk werkende, opensource én die dan ook nog eens van Nederlandse bodem komt, is dan niet raar voor een NL OSM portal. Als het er 20 waren dan zou ik klagen dat niemand meer door de bomen het bos ziet. En dat van iemand die zelf als klacht altijd krijgt dat ik teveel details geef. :) Als iemand jouw zou vragen of je met Openstreetmap kunt routen, zou jij je dan beperken tot je eigen Yournavigation? Ik denk van niet. Het feit dat op de vraag 'Kan ik een route plannen?' maar een antwoord komt suggereert dat dat het beste is en misschien wel het enige. Hoe fantastisch ik jouw site ook vindt, ik denk niet dat iemand die google maps als referentie heeft daar erg onder de indruk van zal zijn. Yournavigation moet er beslist bij want het gaat hier niet alleen om Openstreetmap maar ook om nl en dus mogen en moeten Nederlandse projecten daar vrij prominent getoond worden. Daar bovenop komt dat Yournavigation een ander aanpak heeft en veel sneller is. Zodra ik een route kan 'corrigeren' met behulp van via-points en vervolgens een gpx track kan downloaden dan zal ik die vrijwel exclusief gebruiken. Al die lange lijsten met 'na 10km rechtsafslaan de huppeldepup weg in', zouden er mensen zijn die daar gebruik van maken? Onlangs nog was er een vraag op de algemene talk list van iemand die vroeg of hij OSM data kon gebruiken op een Garmin die hij wilde kopen. Ik vind dat raar. Hij vindt openstreetmap, de mailing list (moet zich aanmelden om te posten) en neemt de 'moeite' die vraag te stellen. Ongetwijfeld zullen mensen denken dat hij wat meer zelf had moeten onderzoeken maar ik vind dat een gewone argeloze gebruiker die niet van plan is bij te dragen dit al meteen had moeten vinden. Overigens is net dit geval niet een voorbeeld van een probleem van openstreetmap.nl maar een omissie van openstreetmap.org. Nu weet ik dat niet iedere computer gebruiker een gevorderde gebruiker is, maar 1 Google search met daarin twee woorden 'Garmin OpenStreetMap' leid jou naar zat sites die verklaren dat OSM Garmin kaarten heeft en als je een paar extra woorden invoert kom je rechtstreeks bij mijn Garmin site uit. Dus moeilijk vindbaar is het écht niet, zelfs zonder duidelijke vermelding op de NL portal. Ben ik geheel met je eens. Toch denk ik dat het geen uitzondering is en dat het eerder uitzonderlijk ik dat hij nog die omweg nam. Die vraag op de ML mailinglist is overigens netjes beantwoord maar daar doel je niet op natuurlijk. Inderdaad een prima antwoord zonder ondertoon zoals het wat mij betreft hoort. Intussen is er niet alleen een tool tip bij de OSM logo gekomen maar ook een link Bekijk de kaart op de site. Heel erg bedankt! mvg Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] webpagina
On Monday 17 August 2009 15:34:36 Lambertus wrote: Het zijn er op dit moment 4 en ik verdenk de Traveling Salesman auteur ervan dat hij ook nog eens met een webversie aan komt zetten. Dan ga je de passant van onze portal overspoelen met keuzemogelijkheden... Komt er imo op neer dat we een keus moeten gaan maken en doe dan bijvoorbeeld YOURS en CM. Dan zie je als gebruiker ook het verschil tussen rauwe techno functionaliteit van YOURS Made in Holland en de Google achtige 'ooowww aaah' UI van CM :-) Eens, maar Openrouteservice heeft die mooie Cyclemap achtergronden al die overlays, dat heeft Google zelfs niet. Al die 'styles' bij Cloudmade zie ik nu pas , inderdaad woooaaauw! Ik heb mij niet voldoende verdiept in de materie om op niveau mee te praten over de design. Ik wilde alleen mijn ervaring/inzicht melden zodat het eventueel meegenomen kan worden. Ondanks dat zou ik denken dat op die vraag Kan ik een route plannen? een pagina komt met een aantal keuzes zeer prominent. Ergens (ik weet niet meer waar) was er sprake van een voorpagina en was er een drie kolommen optie. Als je weet wat ik bedoel dan zou daar mooi de drie routerings opties kunnen komen. En dan boven of onder wat verdere doorlinkmogelijkheden. Het is juist die rijkdom aan mogelijkheden waar op zijn minst een hint van moet blijken. En als het voorportaal van openstreetmap.org wat beter wordt (vroeg of laat moet het er toch van komen lijkt mij) is een link daar naar toe voldoende. 'Dit is wat wij in Nederland doen, kijk hier voor de rest van de wereld.' Yournavigation moet er beslist bij want het gaat hier niet alleen om Openstreetmap maar ook om nl en dus mogen en moeten Nederlandse projecten daar vrij prominent getoond worden. Daar bovenop komt dat Yournavigation een ander aanpak heeft en veel sneller is. Zodra ik een route kan 'corrigeren' met behulp van via-points en vervolgens een gpx track kan downloaden dan zal ik die vrijwel exclusief gebruiken. Akkoord, ik ga mijn GF vanavond lief aankijken in een poging tijd te maken om het om te bouwen. Nu voel ik mij schuldig. :( Al die lange lijsten met 'na 10km rechtsafslaan de huppeldepup weg in', zouden er mensen zijn die daar gebruik van maken? Ik zou het niet weten. Er is trouwens een google summer of code project waarbij een text-only uitbreiding voor YOURS is gemaakt speciaal voor blinden en slechtzienden. Die laat ook de straatnamen zien. Text only voor blinden en slechtzienden? En dan met braille of voorlezen (audio)? Toch denk ik dat ik je begrijp, want een lijntje op een kaart is niet echt nuttig voor blinden en slechtzienden. Maar die uitbreiding is 1 grote hack omdat YOURS nog niet de straatnamen terug geeft + de segment lengtes. Zodra de API voor versie 2 af is dan wordt die informatie ook meegegeven en is het maken van een text-only interface een stuk makkelijker. Ik heb dus niets met die lijsten. In een routeplanner op het juiste moment weergeven en voorlezen, prima natuurlijk. Nog beter is dat ik niet meer hoef te sturen en de krant,, eehh web kan lezen. :) Enkele afdrukken van de kaart met route is volgens mij wat mensen gebruiken. En gesproken teksten zoals nu standaard is wat denk ik ook prima is voor blinden en slechtzienden. Trouwens er wordt ergens op een universiteit in Nederland een blindegeleide stok ontwikkeld met ingebouwde gps en diverse sensors. Maar of dat opensource en vrij komt/is weet ik niet. mvg Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] [english 95%] A process for rethinking map features
Hi, Implementing the outcome of what the working group comes up with is not an issue IMO. We have the presets in the editors and the errors in keepright. Together those are way more powerful than any discussion here or even the mapfeatures page.. My guess is that the developers those projects will be very happy with clear guidance on the 'rules'. The main task of the working group would be to search through mailing list(s), discussion pages etc. and decide what the outcome is. The way I see it all the pieces are there it is just unclear as to what the outcome/conclusion is. So the goal would be to collect all the points of view, weigh them and present their conclusion. The wiki page could have an extra tab where the outcome of the working group presents their result. If unhappy comments turn up on the mailing list they could decide to go a second round. When they have finished a subject the mapfeature would be updated. Also they would inform the various developers groups (editors, keepright, stylesheets) of the status quo, and hopefully there is a contact for the translated mapfeatures pages. The working group would decide which feature to tackle, but there could also be a 'wishlist' where requests could be put up and be voted on to get an order of priority helping them which feature to tackle next. I am not a big fan of voting. Sometimes it is necessary to cut a long discussion short where one needs to 'force' an agreement. So voting the way it is now where those involved in the discussion do the voting IMO doesn't need to change. The hard part as I see it is who gets to decide who is in the working group. Is it a fixed group where we vote who gets in? Maybe ad hoc groups where someone announces on this mailing list they want to tackle a feature and invites others to join? When is a group a group? The working group will need some kind of authority to work, otherwise they will just be ignored and ineffective. Lambert Carsten On Sunday 16 August 2009 01:51:43 James Livingston wrote: On 16/08/2009, at 2:20 AM, Tom Chance wrote: Probably sensible to start with something more manageable than path/ highway. Maybe the forest/wood debate. Sounds good to me. The important thing is that the group has their goals set out explicitly, so they know exactly what they should be doing, and they know when they're finished. To me, this means that we need to collect a complete list of all the tree/wood/forest-related things that people may want to add to OSM (even if they already have tagging solutions), with good descriptions, if possible photos and what implications people think they have. The WG could then sit down and figure out which of them are actually the same, and then find a good tagging scheme. I think the complete list of what we want to tag is something we're missing in the current arguments. How are we supposed to know if what people are talking about are actually the same thing? Especially since language is an issue, either not having English as a first language, or not having the same English (e.g. British vs Australia vs American). The one missing part to work out is how we respond to the proposal. The best thing I can imagine is if we could set-up a poll that uses our OSM.org logins and we notify as many users as possible through every channel available. We could set the bar at something like 1000 votes and a 66% majority needed. I think that if the WG comes up with a solution after taking into account, then it would likely be acceptable to most people. If not, then it probably didn't represent a crosssection of the community, or people didn't add their items to the list of things to tag. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Josm API error
Hi, Does anyone know what this means and what to do about it? Upload to OSM API failed Uploading failed. NameError: uninitialized constant Changeset::SCALE(Code=500) except that the upload failed :) Josm version 1979 Java version 1.6.9-15 Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Josm API error
On Sunday 16 August 2009 12:26:55 SLXViper wrote: Lambert Carsten schrieb: Hi, Does anyone know what this means and what to do about it? Upload to OSM API failed Uploading failed. NameError: uninitialized constant Changeset::SCALE(Code=500) except that the upload failed :) Try again ;) firefishy reverted some changes causing these problems. Tried several times already but this time it worked :) Thanks! Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Hoe duikers mappen
Een beetje dubbel intussen want anderen waren mij voor :) maar toch: On Sunday 16 August 2009 16:08:05 Frank Fesevur wrote: Op 16 augustus 2009 15:13 schreef Milo van der Linden het volgende: Ik zou adviseren, zoals ook al eerder in deze thread, om de volgende vuistregels te nemen: - taggen wat er is, geen gekunstelde alternatieven taggen omdat het er dan mooier uitziet. Maar kom ik weer terug bij mijn eerste vraag: Hoe moet ik het dan taggen. Zoals het nu is, is het in ieder geval niet goed. Het zijn geen bruggen, maar duikers. Dan het water maar opsplitsen? Als je er niet onderdoor kunt varen zou ik het daar niet als brug taggen. Voorzover ik op Google Earth kan zien zitten er tussen de kruispunten stukjes water waar je verder alleen in kan vallen. Dat zou ik met een way tekenen en taggen met waterway=stream of waterway=drain. Die stukjes kunnen dan verbonden worden met die waterway=culvert en layer=-1 voor onder het kruispunt. Een alternatief voor stream of drain zou canal kunnen zijn maar dan moet je wel boat=no toevoegen. Als je er onderdoor kan varen zie hieronder. In Amsterdam worden de grachten enz. getagged met natural=water (wat toch een beetje 'tekenen' is voor de renderaar n.m.m.) maar ook met een waterway=canal in het midden van de gracht zodat ook een vaarkaart mogelijk is. Een heleboel van die natural=water stamt nog uit het AND bestand. - een onjuiste rendering op de wiki of hier op de nl lijst posten, het liefst met een screenshotje zodat onze stylesheet experts er naar kunnen kijken. Zie het voorbeeld van het Muntplein van Lambert. Of bijvoorbeeld deze kruisingen hier in Den Haag. http://www.openstreetmap.org/?lat=52.06198lon=4.27402zoom=17 Eenzelfde situatie. Vanaf de straatkant gezien bijna niet meer als brug herkenbaar, maar het water loopt er echt goed onderdoor. Zeker niet 4 aparte bruggen voor de rijbanen en fietspaden. Zo zijn er in Den Haag wel tientallen voorbeelden te vinden. Bruggen over water waar er meer ways over gaan (gescheiden banen, trams, fietspaden) worden momenteel niet goed gerenderd. Dat moeten de renderaars oplossen. Inderdaad zoals Milo aangaf niet met gekunstelde oplossingen aankomen . Er is een voorstel om dergelijke bruggen in een relatie op te nemen om daarmee duidelijk te maken dat het gaat om een brug met meerdere 'ways'. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Bridges_and_Tunnels#Tags Maar daar zit op dit moment weinig schot in en de ontwikkelaars van de render regels houden waarschijnlijk alleen rekening met geaccepteerde voorstellen (niet onbegrijpelijk). Zolang dat voorstel niet is aangenomen (of een ander voor in de plaats) moeten wij ons behelpen met meerder bruggen naast elkaar. In elk geval is daarmee de functionaliteit in de database opgenomen. Een renderaar zou lijkt mij nu al die bruggen kunnen samenvoegen en als een tekenen, maar ik heb makkelijk praten. :) - Indien je info hebt waar momenteel geen, of enkel een tagging voorstel bestaat, toch taggen, volg je gevoel. Dit kan altijd later worden verbeterd en als je het niet tagged is het risico dat jou bevinding verloren gaat veel groter. Mijn gevoel is als beginner nog te klein om dat te durven volgen. Komt wel. mvg Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Layer transitions
On Thursday 13 August 2009 00:31:23 Lauri Kytömaa wrote: Lambert Carsten wrote: sense. Even though the smaller road ends at the edge of the larger road not the middle of the road. Inside the crossing area the roads overlap, neither ends there - you're on both roads. But you're not on the bridge that starts only several meters away - or inches away if you're already moving towards the bridge. Taking the canal bridges mentioned previously: if you draw the riverbanks/canal edges, it has been the recommendation (I'd have to dig the talk list archives for that) also that the bridge=yes starts and ends at the points where one can get under the bridge - at the water's edge, meters away from the ways marking the roads running parallel to the canal. It isn't about inches or even meters. It is about representing reality in such a way that renderers, routeplanners whatever can do interesting things with the data. Starting the bridge at the edge of the water is not a good recommendation because it has to be made clear to whatever program parsing the data that it is ok to have a road going 'through' water because we have a bridge. Just for practical editing reasons the bridge node should not be too close to the water edge. One thing about the same layer check occurs sometimes: a motorway link road joins the motorway right at the point where the bridge starts: most notably the case where the road markings indicate three lanes on the bridge and only two (+1 approaching but still separate) up to the exact point where the bridge starts. We can make the connected node something other than the point where the lanes come into contact (the acceleration lane's hundreds of meters long anyway, but that would need some kind of a note to be consistent - at least once more people start to get to that level of detail. If I understand this example correctly it is another example that the 'rule' as rule is wrong. On Thursday 13 August 2009 11:51:36 Jochen Topf wrote: On Wed, Aug 12, 2009 at 10:58:36PM +0200, Lambert Carsten wrote: That often leads to inconsistencies, but inconsistent is not necessarily bad. Exactly, no need to 'force' junctions to have connecting roads on the same layer. If you really believe in the 'middle of the junction theory' let us be inconsistent with that one and help mappers clean up real issues rather than adding titsy bits of road between junctions and bridges. I didn't say anything about titsy bits. If you only add this to work around the Keepright message, that doesn't make any sense. It only makes sense to add a non-bridge part of the way, if it actually is large enough to make a difference when rendering. Well sadly while I have been discussing this here that is exactly what has been done. (No one's fault, it's the way things go.) Most of the bridges in Amsterdam now have 2-3m connection bits (less than half the width of most roads) between the bridge way(s) and the junction (example: http://www.openstreetmap.org/?lat=52.36607lon=4.88279zoom=17). Hopefully this will not cause (too many) other issues in the future. Often the renderers try to insert the name of those bits separately. I dread that next people will start 'cleaning up' that by removing the name there after which Keepright will (correctly) mark it as a street with no name :( I hope I am wrong, I really do. And if we get better software or more detailed data or want to support new uses, we'll change things around. Can we agree on getting rid of the Right and especially Wrong texts that deal with this issue in the Map Features and give some advice like: Often bridges/tunnels will not connect directly to a junction in which case you should/can (?) add a piece of road connecting the two. ? The page could definitely have a more thorough description of the problems with either way of mapping and give some advice, when each makes sense. Feel free to add this. Your sentence above sounds like a good start to me. Well thanks for that! Consider it done. btw I noticed there are some translations regarding this issue. Is there a way to inform them or is it their job to keep an eye on the English version? Jochen Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
Hi Jochen, Could you please comment on this thread: http://lists.openstreetmap.org/pipermail/talk/2009-July/039217.html http://lists.openstreetmap.org/pipermail/talk/2009-July/039259.html http://lists.openstreetmap.org/pipermail/talk/2009-August/039847.html since you created the 'T-junction' rule in the first place back in feb 2007: http://wiki.openstreetmap.org/index.php?title=Key:tunneldiff=nextoldid=23441 As you are the co-author on a book on tagging I feel I should ask your input on this :). On Tuesday 11 August 2009 15:31:24 Lambert Carsten wrote: On Saturday 08 August 2009 14:11:21 Marc Schütz wrote: no, it's not, it's about relative order in the db. Fair enough. In other words, at any node which is a junction of way segments with different layers (whether the segments are part of the same way or different ways), the physical implication is that the slope of the way changes in the close vicinity of that node. Not even that: it only says something about the relative ordering, not about slope. Regards, Marc Here is just one of the many examples in Amsterdam concerning bridges: http://maps.google.com/maps?f=qsource=s_qhl=degeocode=q=bayreuthsll=37 .0625,-95.677068sspn=59.467068,107.138672ie=UTF8t=kll=52.371356,4.897274 spn=0.001132,0.003447z=19 All the connecting roads are more or less on the same physical 'layer'. The roads that do not intersect with anything on another level don't have a layer tag and are assumed layer=0. (A layer tag only has meaning relative to something that is intersected). Clearly the bridge starts at the (in this case 'X') junction. All the connecting roads are (implied) layer=0. The T-junction rule makes it necessary to add a non existing 'segment' OR add three (for this bridge actually 6) layer=1 tags. Of course the other end of those ways will connect to other roads. So the T-junction eastwards will also need layer=1 tags which in turn will force the X intersection northwards to have layer=1 tags. The result is of course that most or all of the roads will need a layer tag. And where we finally connect Amsterdam to the rest of Holland we have to hope that there are enough I connections so we don't endup forcing the whole world to sit on layer=1. The 'segment adding solution' does not only not represent the reality. Those extra bits have hardly any room because it has to fit between the junction and the 'natural=water' to work. All the layer tag does is make it clear that a crossing of ways do NOT connect/intersect and the numbering helps the renderer to make a decent representation on a 2D drawing. It is not about slope or height and shouldn't be. I think we should insert a in most cases into this rule. What is the point of this? O.K. if I delete the 'offending' :) bits in the wiki? http://wiki.openstreetmap.org/wiki/Key:tunnel#How_to_Map http://wiki.openstreetmap.org/wiki/Key:bridge#How_to_Map Also here (since july 2009): http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Bridges Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
On Wednesday 12 August 2009 11:59:36 Jochen Topf wrote: Hi! Thanks for your quick input. I have amended the bridge and tunnel pages with the reason for those rules: Rendering breaks if you have different layers on junction nodes. This is tagging for the renderer which I thought was generally considered a big nono. But whats more important, in real life bridges don't start in the *middle* of junctions so there *is* a little bit of non-bridge roads between the junction and the bridge. This argument has been made previously and doesn't really hold up. An X-junction between a large primary road and a connecting cycleway (for example) does not either get a small bit of primary inserted in the cycleway to cover the width of the larger primary road. For very tight features this is a problem, I agree. But I haven't seen a good solution for this yet. The rules on the wiki work in most cases and give good guidance to newbies. But they should never be read as gospel, so if you have a solution that works better for your case, just use it. Of course, personally I let a bridge connect to a junction without changing the layer tag of the connecting roads. The 'problem' has shown up because keepright is now showing these intersections as possibly incorrectly tagged and people wanting to 'clean up' their area. For canals in Dutch cities, I'd consider not tagging the roads special but giving the canals a layer=-1 and maybe use tunnels where they cross under the roads. That might be a bit of a hack, but sometimes its easier to tag something as a tunnel even if it might technically not be one. Changing the layer of the water to -1 will still generate an 'error' from keepright at the bridge junction because the bridge is layer=1. So in those cases the bridges would need to be tagged layer=0 as well (virtually all the bridges in Amsterdam and similarly built cities). That would work to 'get around the T-junction rule', but then the question arises: What did we achieve with all this? The renderer still needs to figure out to draw the bridge correctly when connecting to a junction. Newbies now not only need to 'understand' the rule but also how and when to get around it. Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
On Wednesday 12 August 2009 20:36:54 Jochen Topf wrote: On Wed, Aug 12, 2009 at 07:18:03PM +0200, Pieren wrote: On Wed, Aug 12, 2009 at 7:04 PM, Martin Koppenhoeferdieterdre...@gmail.com wrote: 2009/8/12 Jochen Topf joc...@remote.org: in real life bridges don't start in the *middle* of junctions so there *is* a little bit of non-bridge roads between the junction and the bridge. +1 There *is* nothing. It is all an abstraction and *this* abstraction is not helpfull or get us anywhere. As I stated before a crossing between a big road and a (much) smaller road does not either get little bits of road inserted in the smaller road to cover the width of the larger road because it makes no sense. Even though the smaller road ends at the edge of the larger road not the middle of the road. That's a stange argument. In real life, traffic signals are also not in the middle of junctions. So you add nodes per traffic signal on each way arriving at intersection ? In real life, oneway streets do not have oneway road sign on the middle of junctions, so you split your way to be sure that oneway is really starting at the right centimeter in the street ? Modelling the real world is always a compromise. When mapping a oneway road we do it from the junction, because it doesn't really matter where the sign is exactly for the road to be oneway, also routers would get very confused otherwise. But if the oneway sign is a few meters into the road, say after an entrance to a parking lot that should be reachable, I'd split the road there. So would I. A traffic signal is something that probably belongs more to the junction than the road, so it sort of makes sense there. But of course I can also move the traffic signals somewhat down the road, if I want to have all the details, say if there is a fan-out and only one branch has the traffic signal. I have never tagged traffic signals myself, so I am not the expert on that. But a bridge often needs a ramp, even if its a small one, so there is some space there where the road is not a bridge yet. So I do think there is a difference to the examples you mentioned. often here just means that you 'often' have to add an extra piece, not always and no rule. But, again, the real world is always more complex than any rule people come up with. I'll mostly go with the most practical compromise: Easy to map and easy to use in current software. But my point is that this 'rule' is causing the opposite of what you want. Is adding a segment between a bridge and a junction where in reality there is none 'practical' and 'easy to map'. The rule maybe simple the consequences are not. That often leads to inconsistencies, but inconsistent is not necessarily bad. Exactly, no need to 'force' junctions to have connecting roads on the same layer. If you really believe in the 'middle of the junction theory' let us be inconsistent with that one and help mappers clean up real issues rather than adding titsy bits of road between junctions and bridges. And if we get better software or more detailed data or want to support new uses, we'll change things around. Can we agree on getting rid of the Right and especially Wrong texts that deal with this issue in the Map Features and give some advice like: Often bridges/tunnels will not connect directly to a junction in which case you should/can (?) add a piece of road connecting the two. ? Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Openstreetmap on FLOSS weekly
Hi, Strangely no mention of this that I have seen on OSM so for those interested Openstreetmap (Steve Coast) was on the FLOSS weekly podcast recently: http://www.podtrac.com/pts/redirect.mp3/twit.cachefly.net/FLOSS-081.mp3 Webpage: http://www.twit.tv/FLOSS Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
On Saturday 08 August 2009 14:11:21 Marc Schütz wrote: no, it's not, it's about relative order in the db. Fair enough. In other words, at any node which is a junction of way segments with different layers (whether the segments are part of the same way or different ways), the physical implication is that the slope of the way changes in the close vicinity of that node. Not even that: it only says something about the relative ordering, not about slope. Regards, Marc Here is just one of the many examples in Amsterdam concerning bridges: http://maps.google.com/maps?f=qsource=s_qhl=degeocode=q=bayreuthsll=37.0625,-95.677068sspn=59.467068,107.138672ie=UTF8t=kll=52.371356,4.897274spn=0.001132,0.003447z=19 All the connecting roads are more or less on the same physical 'layer'. The roads that do not intersect with anything on another level don't have a layer tag and are assumed layer=0. (A layer tag only has meaning relative to something that is intersected). Clearly the bridge starts at the (in this case 'X') junction. All the connecting roads are (implied) layer=0. The T-junction rule makes it necessary to add a non existing 'segment' OR add three (for this bridge actually 6) layer=1 tags. Of course the other end of those ways will connect to other roads. So the T-junction eastwards will also need layer=1 tags which in turn will force the X intersection northwards to have layer=1 tags. The result is of course that most or all of the roads will need a layer tag. And where we finally connect Amsterdam to the rest of Holland we have to hope that there are enough I connections so we don't endup forcing the whole world to sit on layer=1. The 'segment adding solution' does not only not represent the reality. Those extra bits have hardly any room because it has to fit between the junction and the 'natural=water' to work. All the layer tag does is make it clear that a crossing of ways do NOT connect/intersect and the numbering helps the renderer to make a decent representation on a 2D drawing. It is not about slope or height and shouldn't be. I think we should insert a in most cases into this rule. What is the point of this? O.K. if I delete the 'offending' :) bits in the wiki? http://wiki.openstreetmap.org/wiki/Key:tunnel#How_to_Map http://wiki.openstreetmap.org/wiki/Key:bridge#How_to_Map Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Amsterdamers (en anderen) wij hebben u nodig; Haltes
On Friday 07 August 2009 20:36:12 Stefan de Konink wrote: On Fri, 7 Aug 2009, Lambert Carsten wrote: Ja maar, hoe, waar? Op openstreetphoto.org zie ik niets over uploaden. De wiki :) Stefan kun je een fatsoenlijke link geven want ik zie nergens* een mogelijkheid om foto's voor openstreetphoto te uploaden. Is het handig om bijvoorbeeld 'haltes' in de naam op te nemen? Lambert *) m.u.v. de plaatjes voor op de wiki zelf: http://wiki.openstreetmap.org/wiki/Special:Upload maar die accepteert maximaal 2Mb. Ik doe natuurlijk zowiezo alles op hoogste resolute (7megapixel momenteel) en dat lijkt mij vooral voor de tabellen wel nodig ervanuitgaande dat je een ocr programma erop los wil laten. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Amsterdamers (en anderen) wij hebben u nodig; Haltes
On Tuesday 11 August 2009 19:08:12 Stefan de Konink wrote: On Tue, 11 Aug 2009, Lambert Carsten wrote: De wiki pagina heb ik aangepast en 'ftp:// projectname .org /' vervangen door 'ftp://openstreetphoto.org/' Je bent een beetje te naief. Terugveranderd en voortaan eerst vragen voordat je iets verandert wat met een reden obfuscated is neergezet. Ik vind het prima dat je het hebt terug verandert. Realiseer je alleen dat het weinig had gescheeld of ik had het opgegeven. De wiki is overigens niet een plek om informatie aan bieden als je niet wilt dat anderen dat veranderen. Ik hoef jouw toch niet het principe van de wiki uit te leggen. Bovendien heb ik het juist gemeld omdat er wellicht een reden was om het te doen zoals jij het (blijkbaar) had gedaan, eerst vragen is hier dus niet aan de orde. Als het een omissie was geweest van jouw kant had je waarschijnlijk gereageerd in de trant van: 'het is een wiki, verander het toch lekker zelf'. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Layer transitions
On Friday 31 July 2009 17:25:19 Richard Mann wrote: I saw some strange rendering effects when a side road was straight onto a bridge. The bridge was layer=1, so the side road was rendered on top of the main road. That's why all the ways approaching a junction should be on the same layer. You can either achieve this by inserting a short way between the bridge and the junction, or by altering the layer of the thing that is bridged (ie making the stream layer=-1) Recently we have been discussing this problem on the Dutch talk list regarding bridges. Keepright doesn't like T-juntions with different layers and tags these as 'not so obvious' errors. The reasoning that we map the centre of the road is faulty. That reasoning implies that we need to split up the road because the sidewalk does not either continue to the centre of the crossing road. Adding a little piece of road so the junction can be on one layer just does not make sense. In Amsterdam there are lots of bridges and canals. The canals there are physically not on the same layer as the road and bridges. But for practical reasons we only add layer tags where ways cross without connecting (bridge over water). This 'T-junction rule' is causing just about every bridge to have small extra bits added. Or have roads that do not cross anything tagged as layer=1. On the discussion list the argument is made that we don't need a layer tag for bridges and tunnel (except of course when there are more than two ways above/under each other) and I agree with that. So simply removing the layer tag on most tunnels and bridges would resolve the layer issue. However I am not sure if it is generally accepted that it is wrong to tag a bridge or tunnel with a layer attribute. The renderers already seem to have a problem with the names of roads when they are split up into bits. Adding these extra little bits will just make things worse. It seems to me that those rendering problems (at least with bridges) would be much better solved by looking at whatever the bridge is crossing and use that to decide how to render a bridge that creates a T-connection with a way. And if Keepright can see that a bridge or tunnel is connected to a T-junction why can't a renderer come to the same conclusion and render differently? Richard On Fri, Jul 31, 2009 at 11:01 AM, Marc Schütz schue...@gmx.net wrote: to make my question more precise, please have a look at this tunnel that crosses a railway track (the railway is a subway that runs at ground level): http://www.openstreetmap.org/edit?lat=48.1325961lon=16.3109488zoom=19w ay=29205957 The tunnel tag implies layer=-1 No, it doesn't. and that leads to a junction of ways on different layers on both ends of the tunnel. Which wouldn't be a problem either. Layer is only relevant for defining the relative order of intersecting (crossing) objects. If the objects don't intersect, or have a common node, their layers don't imply anything about their relative or absolute height. Absolutely! In any case, PLEASE let us get rid of this 'rule' that a T-junction has to be on the same layer. On the western end of the tunnel the adjacent way ends, this should be no problem with the layers; on the eastern end there is a T junction. Do you think, this tunnel is OK the way it is or should someone add a small piece of way on layer 0 at the eastern end next to the T-junction to avoid a T-junction of different layers? It is ok as it is. Regards, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
On Friday 07 August 2009 12:29:09 Marc Schütz wrote: On Friday 31 July 2009 17:25:19 Richard Mann wrote: I saw some strange rendering effects when a side road was straight onto a bridge. The bridge was layer=1, so the side road was rendered on top of the main road. That's why all the ways approaching a junction should be on the same layer. You can either achieve this by inserting a short way between the bridge and the junction, or by altering the layer of the thing that is bridged (ie making the stream layer=-1) Recently we have been discussing this problem on the Dutch talk list regarding bridges. Keepright doesn't like T-juntions with different layers and tags these as 'not so obvious' errors. The reasoning that we map the centre of the road is faulty. That reasoning implies that we need to split up the road because the sidewalk does not either continue to the centre of the crossing road. +1 It was always my view that the way is simply an abstraction of the entire road, not only its centre. Adding a little piece of road so the junction can be on one layer just does not make sense. In Amsterdam there are lots of bridges and canals. The canals there are physically not on the same layer as the road and bridges. But for practical reasons we only add layer tags where ways cross without connecting (bridge over water). This 'T-junction rule' is causing just about every bridge to have small extra bits added. Or have roads that do not cross anything tagged as layer=1. On the discussion list the argument is made that we don't need a layer I meant discussion page by the way: http://wiki.openstreetmap.org/wiki/Talk:Key:tunnel#Layer tag for bridges and tunnel (except of course when there are more than two ways above/under each other) and I agree with that. So simply removing the layer tag on most tunnels and bridges would resolve the layer issue. However I am not sure if it is generally accepted that it is wrong to tag a bridge or tunnel with a layer attribute. Please don't do that. O.k. I won't. I have no problem with explicitly tagging the layer and have always done so by the way. On the wiki (and the mailing lists) there are also strong arguments against implied layer. Layer should be kept as simple as it can be, and this also means keeping it as an independent feature that doesn't change its default value depending on other tags. Also I am also not sure that removing the layer tags would actually 'resolve' the 'T-junction layer issue' since Keepright or whatever system will probably regard the implied layer no differently from a separate layer tag. Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] een amsterdam zonder keep right issues - bijna?dan
On Friday 07 August 2009 11:32:07 Rejo Zenger wrote: ++ 06/08/09 13:07 +0200 - Lambert Carsten: Mijn voorstel zou zijn om het perron niet als area maar als way te tekenen. Waarom is dat? Ik zie de toegevoegde waarde van een perron als area niet. Integendeel het maakt al die 'ways' die erop aansluiten nodeloos ingewikkeld. De mapfeatures geeft aan dat het kan (als area aanmerken:especially wider ones) maar ik zie daar nauwelijks een discussie over dus het lijkt niet erg doordacht. http://wiki.openstreetmap.org/wiki/Tag:railway=platform Ok. Als je er alleen een way van zou maken, zou je dan voor perrons aan beide kanten een way maken, dus voor beide sporen? In het onderhavige geval komt namelijk de trap in het midden van het perron omhoog. Aan het eind van de roltrap kun je naar links voor het ene perron, rechts naar het andere. Of maak je een enkele way (met ref's naar beide sporen)? If so, hoe komt de trap daar dan aan? Met dat soort details hou ik mij niet bezig. Als fietser erger ik mij aan al die mini vluchtheuvels en wat niet al. Die teken ik ook allemaal niet. Dat de trap midden in het perron omhoog komt is niet wezenlijk. Wel dat er daar ergens een mogelijkheid is om op het perron te komen. Op een perron kun je over de hele lengte van de ene kant naar de andere kant 'oversteken'. Een 'way' is dus voldoende. Twee 'ways' klopt niet want dan moet je bij wijze van spreken een liggende ladder tekenen, onzin natuurlijk. Trouwens over die T kruisingen met verschillende layers is er ook een 'thread' op de algemene talk list (subject: Layer transitions): http://lists.openstreetmap.org/pipermail/talk/2009-July/039217.html Nog niemand heeft zich gemeld als voorstander van die regel! Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Amsterdamers (en anderen) wij hebben u nodig; Haltes
On Friday 07 August 2009 14:50:47 Stefan de Konink wrote: Hoi allen, Voor een nog ubergeheim project dat niet zo geheim meer is als ik het op talk-nl post heb ik exacte halte coordinaten nodig. Ik heb al eerder gemeld dat ik een 'lijstje' heb gekregen. Maar ik heb daarvan al emperisch bewezen dat deze lijst slechts op 50m naukeurig is. Ik zou je daarom willen vragen als je zin hebt, of langs een halte komt even een PoI aan te maken, en de halte naam over te nemen. Wat is een Pol? Als je er toch bent kun je ook even een fotootje nemen van de haltetijden tabellen ;) Kom ik net terug van een rondje om Schiphol en onderweg steeds bij de bushaltes dacht ik, die sla ik over want ik begrijp nog steeds niet hoe ik die moet mappen (node in de weg, links/rechts, relation?!?). :( Begrijp ik het goed dat je genoeg hebt aan foto's met geolocatie van de haltes? En is dat serieus dat je iets met een foto van de haltetijden kunt (ook met geolocatie natuurlijk)? Is het geen probleem dat je niet kunt zien wat de orientatie is van de camera en dus niet weet aan welke kant van de weg de halte zit? Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Amsterdamers (en anderen) wij hebben u nodig; Haltes
On Friday 07 August 2009 17:28:37 Stefan de Konink wrote: On Fri, 7 Aug 2009, Lambert Carsten wrote: On Friday 07 August 2009 14:50:47 Stefan de Konink wrote: Hoi allen, Voor een nog ubergeheim project dat niet zo geheim meer is als ik het op talk-nl post heb ik exacte halte coordinaten nodig. Ik heb al eerder gemeld dat ik een 'lijstje' heb gekregen. Maar ik heb daarvan al emperisch bewezen dat deze lijst slechts op 50m naukeurig is. Ik zou je daarom willen vragen als je zin hebt, of langs een halte komt even een PoI aan te maken, en de halte naam over te nemen. Wat is een Pol? Een Pol is een vraag die aan het publiek wordt gesteld en statistiek met wordt bedreven om een algemene opinie uit op te maken. Een PoI is een Point of Interest. Ik begrijp het, even vernemen wat het standpunt is van de halte. :) Als je er toch bent kun je ook even een fotootje nemen van de haltetijden tabellen ;) Kom ik net terug van een rondje om Schiphol en onderweg steeds bij de bushaltes dacht ik, die sla ik over want ik begrijp nog steeds niet hoe ik die moet mappen (node in de weg, links/rechts, relation?!?). :( Gewoon neerkwakken aan de kant van de weg waar je ze ziet. Maar die moeten toch geïntegreerd worden in een route relation o.i.d.? (ik hoop dat ik geen spijt krijg van die vraag) Begrijp ik het goed dat je genoeg hebt aan foto's met geolocatie van de haltes? Jup. En is dat serieus dat je iets met een foto van de haltetijden kunt (ook met geolocatie natuurlijk)? Ja. Is het geen probleem dat je niet kunt zien wat de orientatie is van de camera en dus niet weet aan welke kant van de weg de halte zit? Ik hoop dat je GPS zo goed is dat hij mij dat verteld ;) Nou nee. De foto' s worden achteraf 'gegeolocated' (!?). Welke richting de camera op kijkt zit daar niet in. Uit een track is natuurlijk de beweegrichting bekend wat soms helpt. Vaak is duidelijk te zien aan welke kant van de weg de track ligt en dus ook hoe nauwkeurig de track is, maar zonder track en dus alleen de foto's met geolocatie lijkt het mij wat lastiger. Is er een truckje die ik niet ken. Overigens zou ik graag betaalbare camera's met ingebouwde gps en kompasrichting komen, maar ik geloof dat we daar nog enkele jaren op moeten wachten. Is dit een tijdelijke project en waar moeten die foto's heen dan hou ik er voortaan rekening mee? Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Amsterdamers (en anderen) wij hebben u nodig; Haltes
On Friday 07 August 2009 19:43:05 Stefan de Konink wrote: On Fri, 7 Aug 2009, Lambert Carsten wrote: Maar die moeten toch geïntegreerd worden in een route relation o.i.d.? (ik hoop dat ik geen spijt krijg van die vraag) Niets moet :) Gezien relaties momenteel zo 'dom' in elkaar zitten. Gaan we dat eerst eens goed fixen voordat ik iemand vraag routes toe te gaan voegen. Begrijp ik. 'Moet' voor mij betekent 'wil het enige zin hebben'. Is het geen probleem dat je niet kunt zien wat de orientatie is van de camera en dus niet weet aan welke kant van de weg de halte zit? Ik hoop dat je GPS zo goed is dat hij mij dat verteld ;) Nou nee. De foto' s worden achteraf 'gegeolocated' (!?). Welke richting de camera op kijkt zit daar niet in. Uit een track is natuurlijk de beweegrichting bekend wat soms helpt. Vaak is duidelijk te zien aan welke kant van de weg de track ligt en dus ook hoe nauwkeurig de track is, maar zonder track en dus alleen de foto's met geolocatie lijkt het mij wat lastiger. Is er een truckje die ik niet ken. Overigens zou ik graag betaalbare camera's met ingebouwde gps en kompasrichting komen, maar ik geloof dat we daar nog enkele jaren op moeten wachten. Ah :) ik begrijp je, je staat niet naast/bij de halte. Als je dat wel doet zie gewoon aan welke kant van de weg je loopt. En nu begrijp ik jouw pas. Als ik de haltetijden fotografeer dan is het daarmee opgelost. Sirf III is meestal nauwkeuring genoeg, maar in de gebouwde omgeving kan ook die soms er behoorlijk naast zitten. En juist bij stilstand (tijdstip van de foto) gaat de track wat rond dansen. Aan de track is dat wel te zien maar een enkele geolocatie niet. Maar goed, we zien wel. Is dit een tijdelijke project en waar moeten die foto's heen dan hou ik er voortaan rekening mee? Foto's mogen altijd naar openstreetphoto.org; dit project is waarschijnlijk niet tijdelijk. Maar beleeft we een mediamomentje. Ja maar, hoe, waar? Op openstreetphoto.org zie ik niets over uploaden. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] een amsterdam zonder keep right issues - bijna dan
On Wednesday 05 August 2009 21:43:57 Rejo Zenger wrote: ++ 05/08/09 20:21 +0200 - Rejo Zenger: Die 25 issues wil ik ook wegwerken, door het op te lossen of als false positive te markeren. Voor een deel wacht dat op onsite survey, andere dingen weet ik niet hoe ik het moet oplossen. [...] Andere dingen waarvan ik niet zeker weet hoe we het willen hebben: http://keepright.ipax.at/report_map.php?error=4671602 http://keepright.ipax.at/report_map.php?error=4671603 http://keepright.ipax.at/report_map.php?error=4671604 http://keepright.ipax.at/report_map.php?error=4671605 Dit zijn een tweetal trappen (rij treden) in het Max Euweplein. Die zullen er in het echt ook wel zijn, maar omdat ze midden in het plein zitten zit er geen pad aan vast. Dat levert toevallig een error op Keep Right als almost-junction. De vraag is niet zozeer of Keep Right het hier goed doet, maar de vraag is vooral, willen we dat inderdaad zo in OSM, die trappen in het niets? Ik woon er vlakbij en die trappen zijn er. Persoonlijk vind ik het niet erg zinvol om trappen zo in het 'niets' te tekenen. Voor wandelroutes moeten die natuurlijk worden aangesloten op de rest. Overigens vind ik dat wel zinvol. Vroeg of laat zullen ook blinden/slechtzienden hiervan gebruik kunnen maken. Vooralsnog zou ik zeggen link die trappen met de weg en tag dat stukje weg die tussen de trappen loopt met foot=no. Overigens voeg ik zelf alleen trappen toe daar waar die echt een nieuwe verbinding vormen, bijvoorbeeld een trap die een brug/viaduct die de weg eronder direct bereikbaar maakt voor voetgangers. In bovenstaande geval was er al een verbinding. http://keepright.ipax.at/report_map.php?error=4715381 http://keepright.ipax.at/report_map.php?error=4832345 http://keepright.ipax.at/report_map.php?error=4755669 http://keepright.ipax.at/report_map.php?error=4786346 http://keepright.ipax.at/report_map.php?error=4475639 http://keepright.ipax.at/report_map.php?error=4475638 Dit zijn onder andere een viertal layer issues. D'r is een perron getekend als area en tagged met layer 1, daarin een trap die uit een onderliggende layer omhoog komt en dwars op trap en area een kleine way zonder layer aanduiding. Die 'junction of ways on different layers' is gewoon een onzin fout. Layers hebben geen functie op nodes. Een stukje way heeft een layer tag om aan te geven dat die boven of onder een ander kruisende way ligt. Dat is de enige functie van de layer tag. Keepright geeft zelf aan dat het een twijfelgeval is en moet simpelweg opgelost worden door die 'regel' eruit te gooien. Er is principieel geen verschil tussen een 'juntion' van twee 'ways' en meer dan twee. Hier een onderscheid maken doet mij denken aan de tijd waarin men de nul onzin vond want niets van iets zou niet zinvol zijn. Oftewel er zou een wezenlijk verschil zijn tussen 0 en alle ander getallen. Die is er niet en de zaak wordt alleen ingewikkelder als je dat onderscheid toch maakt. Als niemand mij voor is zal ik binnenkort een verzoek naar de General Talk list sturen om die 'regel' eruit te gooien. Ik snap waarom Keep Right hier een melding van maakt. Mijn vraag heeft wederom niet zoveel met dat issue te maken: hoe hoor dat perron getekend te zijn? En die trap omhoog. Mij lijkt het dat die trap er wel hoort, maar die way daar dwars op niet (want geen toegevoegde informatie en niet waarheidsgetrouw). Mijn voorstel zou zijn om het perron niet als area maar als way te tekenen. Als ik de way daar dwars op goed begrijp is dat gedaan om de trap aan te sluiten op het wegennetwerk en dat is goed. De fietspad daar impliceert ook voetgangers. Je kunt je afvragen of het het nodig is een stukje voetpad daar te tekenen maar helemaal verkeerd vind ik het niet. Tenslotte, de volgende issues denk ik alleen op te kunnen lossen met een onsite survey. Ik zou het niet erg vinden als iemand die eerder in de buurt is dat wil doen. Hehe. Het gaat om: http://keepright.ipax.at/report_map.php?error=3122296 http://keepright.ipax.at/report_map.php?error=3102983 (nabij NS Station Amsterdam Zuid/WTC) http://keepright.ipax.at/report_map.php?error=4832776 (nabij Muziekgebouw, iets oostelijk van Centraal Station) http://keepright.ipax.at/report_map.php?error=4561246 http://keepright.ipax.at/report_map.php?error=4561245 (nabij kruising A10 en S104) Als ook deze issues als resolved of false positive gemarkeerd zijn, is Amsterdam binnen de ring A10 geheel vrij van Keep Right issues - voor het moment [1]. Ik vind het echt fantastisch wat je hebt gedaan, petje af. Toch moet keepright niet heilig worden verklaard. Er is al genoeg ellende in de wereld met al die 'heiligen' :) Wie kan me helpen met bovenstaande? [1] Maar ik heb geen jaarwisseling nodig voor goede voornemens. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] een amsterdam zonder keep right issues - bijna dan
On Thursday 06 August 2009 10:36:34 Lambert Carsten wrote: Ik snap waarom Keep Right hier een melding van maakt. Mijn vraag heeft wederom niet zoveel met dat issue te maken: hoe hoor dat perron getekend te zijn? En die trap omhoog. Mij lijkt het dat die trap er wel hoort, maar die way daar dwars op niet (want geen toegevoegde informatie en niet waarheidsgetrouw). Mijn voorstel zou zijn om het perron niet als area maar als way te tekenen. Als ik de way daar dwars op goed begrijp is dat gedaan om de trap aan te sluiten op het wegennetwerk en dat is goed. De fietspad daar impliceert ook voetgangers. Je kunt je afvragen of het het nodig is een stukje voetpad daar te tekenen maar helemaal verkeerd vind ik het niet. Ik had een verkeerd station in gedachte ! Bestaat die verbinding daar (Zuid-WTC) wel? Vandaag of morgen ga ik wel kijken of die trappen er zijn. Het is voor mij nieuw dat daar ook een ingang is naar de perrons. Zo leer je nog eens wat. Die fietspad parallel en ten zuiden van het station richting west loopt volgens mij daar niet dood, dus dat neem ik dan ook mee. Overigens als die trappen er wel zijn kun je het natuurlijk ook oplossen zoals Skywave dat voor de trappen aan de andere kant heeft gedaan door het aan te sluiten op de 'area'. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] een amsterdam zonder keep right issu es - bijna dan
On Thursday 06 August 2009 11:18:00 Rejo Zenger wrote: ++ 06/08/09 10:36 +0200 - Lambert Carsten: Overigens voeg ik zelf alleen trappen toe daar waar die echt een nieuwe verbinding vormen, bijvoorbeeld een trap die een brug/viaduct die de weg eronder direct bereikbaar maakt voor voetgangers. In bovenstaande geval was er al een verbinding. Ook zonder zulke overduidelijke niveau overbrugging lijken trappen mij erg zinvol. Kleine, smalle trappen in een groot plein niet. Trappen in een pad of trappen over de gehele breedte van een plein lijken me zeer zinvol. Ik denk dan bijvoorbeeld aan een routeplanner voor rolstoelers. Ik had ook al aangegeven dat ik het op-zichzelf wel zinvol vind. Mijn voorstel zou zijn om het perron niet als area maar als way te tekenen. Waarom is dat? Ik zie de toegevoegde waarde van een perron als area niet. Integendeel het maakt al die 'ways' die erop aansluiten nodeloos ingewikkeld. De mapfeatures geeft aan dat het kan (als area aanmerken:especially wider ones) maar ik zie daar nauwelijks een discussie over dus het lijkt niet erg doordacht. http://wiki.openstreetmap.org/wiki/Tag:railway=platform Als ik de way daar dwars op goed begrijp is dat gedaan om de trap aan te sluiten op het wegennetwerk en dat is goed. De fietspad daar impliceert ook voetgangers. Je kunt je afvragen of het het nodig is een stukje voetpad daar te tekenen maar helemaal verkeerd vind ik het niet. Je hebt het over iets anders. Zie mijn andere e-mail, met directe link naar de way die ik bedoelde. Ja ik begrijp het nu. Die oplossing aan de andere kant vind je juist niet mooi. Ik kan mij daar iets bij voorstellen. Ik wil ID's. :) Die afkortingen weer.. !? :) Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Undo request button for changesets
On Wednesday 15 July 2009 16:36:36 Russ Nelson wrote: On Jul 15, 2009, at 7:10 AM, Frederik Ramm wrote: Hi, Yann Coupin wrote: I completely agree with Pieren here. Unless you're part of the happy fews, if case of vandalism/error, you're forced to painstakingly repair by hand the problems That is true, but we also have to look at the potential for problems. (If everyone had a gun, it would be much easier for everyone to defend themselves, and the streets would thus become much safer for everyone. - Can you spot the problem?) No, in fact, I can't, because you're using the wrong analogy. Try this one: If only police and criminals have guns, it is much easier for everyone to defend themselves, because when a criminal is threatening you with his gun, you just call a policeman, wait for him to arrive, and he uses his gun. The gun analogy is a very bad one whichever way you use it. In the real world there is no undo/revert. Philosophical nitpicking aside we can undo/revert things in the data so there is no real risk involved unlike the physical world. Having very powerful tools on either side will do more good than bad. If we make these things too easy, then they will get abused. Do you realize that you're also making this argument: If we make map editing too easy, then abusers will edit the map, thus we must put horrible user interfaces in place to make it harder to edit. One might argue that this has already happened. :) (just teasing!) Also, it is quite a challenge technically as well. A good revert system would have to visualise what it is about to revert, Fair enough! Perhaps a revert should be couched in terms of a .OSM file which you load into JOSM, and then preview? If you like what you see fixed, then you hit the upload button. If there are conflicts, well, then there are conflicts and you deal with them as any other edit conflict. Agreed. Ordinary mappers like me need an easy way to download the deleted objects so they show up in Josm (or other). Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] sotm 2009 video
Hoi, 'Anday Allan' heet volgens mij Andy Allan: http://www.vimeo.com/5609679 Ik weet niet wie voor die text verantwoordelijk is dus meld ik het maar hier. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk] undelete
Hi, By coincidence I discovered a recently and unjustly deleted node: http://www.openstreetmap.org/browse/node/242086945 Part of the changeset concerning the node: delete node id=242086945 lat=52.360876 lon=4.9064347 changeset=1720154 user=mvexel uid=8909 visible=false timestamp=2009-07-03T12:58:47Z version=7 tag k=name v=ABN AMRO/ tag k=addr:housenumber v=47-55/ tag k=addr:street v=Sarphatistraat/ tag k=addr:city v=Amsterdam/ tag k=created_by v=Potlatch 0.10f/ tag k=atm v=yes/ tag k=addr:postcode v=1018 EW/ tag k=addr:country v=NL/ tag k=note v=streetname corrected from Sarphatiastraat to Sarphatistraat/ tag k=amenity v=bank/ /node /delete The bank and the atm is still there so the delete is an error. I cannot seem to figure out how to undelete it. It doesn't show up after clicking on the edit button (on the aforementioned link). 'U' in Potlach only seems to show deleted ways not nodes. If I try a wget for the node I get a 410: GONE error. I was hoping to wget the node so I could open it in Josm and then upload it again. I am not a programmer but it seems all that is needed is to change the visible=false bit to visible=true. How does a mere mortal (mapper not developer) handle this without resorting to recreating a new node? Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] undelete
On Thursday 09 July 2009 18:46:03 Lambert Carsten wrote: Hi, By coincidence I discovered a recently and unjustly deleted node: http://www.openstreetmap.org/browse/node/242086945 Part of the changeset concerning the node: delete node id=242086945 lat=52.360876 lon=4.9064347 changeset=1720154 user=mvexel uid=8909 visible=false timestamp=2009-07-03T12:58:47Z version=7 tag k=name v=ABN AMRO/ tag k=addr:housenumber v=47-55/ tag k=addr:street v=Sarphatistraat/ tag k=addr:city v=Amsterdam/ tag k=created_by v=Potlatch 0.10f/ tag k=atm v=yes/ tag k=addr:postcode v=1018 EW/ tag k=addr:country v=NL/ tag k=note v=streetname corrected from Sarphatiastraat to Sarphatistraat/ tag k=amenity v=bank/ /node /delete The bank and the atm is still there so the delete is an error. I cannot seem to figure out how to undelete it. It doesn't show up after clicking on the edit button (on the aforementioned link). 'U' in Potlach only seems to show deleted ways not nodes. If I try a wget for the node I get a 410: GONE error. I was hoping to wget the node so I could open it in Josm and then upload it again. I am not a programmer but it seems all that is needed is to change the visible=false bit to visible=true. ok so I modified the above to: ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id=242086945 lat=52.360876 lon=4.9064347 changeset=1720154 user=mvexel uid=8909 visible=false timestamp=2009-07-03T12:58:47Z version=7 tag k=name v=ABN AMRO/ tag k=addr:housenumber v=47-55/ tag k=addr:street v=Sarphatistraat/ tag k=addr:city v=Amsterdam/ tag k=created_by v=Potlatch 0.10f/ tag k=atm v=yes/ tag k=addr:postcode v=1018 EW/ tag k=addr:country v=NL/ tag k=note v=streetname corrected from Sarphatiastraat to Sarphatistraat/ tag k=amenity v=bank/ /node /osm after which it would show up in Josm and could be uploaded (I did add a tag though). How does a mere mortal (mapper not developer) handle this without resorting to recreating a new node? Until someone shows 'us' an easier way :) Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] IJtunnel
Hoi, De IJtunnel is momenteel dicht. Omdat het toch een zeer belangrijke verbindings ader is en er inmiddels al diverse routeplanners zijn die gebruik maken van OSM heb ik er een tijdelijke access=no aan toegevoegd. Misschien heb ik het (grotendeels) goed gedaan, maar het is erg ingewikkeld. Ik heb naast de access=no een date_on, date_off en hour_off toegevoegd. Toch moet er zoals het nu is handwerk worden verricht op 24 augustus want er zaten al foot=no en bicycle=no access restricties op en die blijven natuurlijk, ook na 24 augustus. Verder is de tunnel nu niet dicht voor openbaar vervoer, taxi's en noodhulpdiensten: http://bereikbaar.amsterdam.nl/live/main.asp?action=display_dataname=paginaitem_id=1695 Om dit allemaal goed aan te geven is zover ik heb kunnen vinden niet of nauwelijks te doen, maar ik hoop dat ik ongelijk heb. Als iemand weet hoe dit beter kan dan hoor ik dat graag? IJtunnel link: http://www.openstreetmap.org/?lat=52.38lon=4.9113zoom=14 Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] IJtunnel
On Thursday 09 July 2009 11:55:07 Lambert Carsten wrote: Hoi, De IJtunnel is momenteel dicht. Omdat het toch een zeer belangrijke verbindings ader is en er inmiddels al diverse routeplanners zijn die gebruik maken van OSM heb ik er een tijdelijke access=no aan toegevoegd. Misschien heb ik het (grotendeels) goed gedaan, maar het is erg ingewikkeld. Ik heb naast de access=no een date_on, date_off en hour_off toegevoegd. 'hour_on' was al een gepasseerd station dus die heb ik weggelaten. Ik vraag mij nu ineens af hoe de 'hour_off' wordt geïnterpreteerd na 24 augustus als verder niemand de tags weghaalt. Beter in dit geval zou natuurlijk zijn: date_off=2009-08-24:06:00:00 (-mm-dd:HH:MM:SS) maar ik kom die optie niet tegen in de mapfeatures. Toch moet er zoals het nu is handwerk worden verricht op 24 augustus want er zaten al foot=no en bicycle=no access restricties op en die blijven natuurlijk, ook na 24 augustus. Verder is de tunnel nu niet dicht voor openbaar vervoer, taxi's en noodhulpdiensten: http://bereikbaar.amsterdam.nl/live/main.asp?action=display_dataname=pagin aitem_id=1695 Om dit allemaal goed aan te geven is zover ik heb kunnen vinden niet of nauwelijks te doen, maar ik hoop dat ik ongelijk heb. Als iemand weet hoe dit beter kan dan hoor ik dat graag? IJtunnel link: http://www.openstreetmap.org/?lat=52.38lon=4.9113zoom=14 Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] talk-ams Re: Herinnering: vanavond eerste Amsterdamse MappersBabbel
On Thursday 25 June 2009 14:55:25 Paul Berendsen wrote: Wat mij betreft is er juist veel te veel verkeer op [OSM-talk-nl], ik zou liever hebben dat er meer gespecialiseerde lijsten zouden zijn. Maar het duidelijk voorop zetten van plaats/regio en/of thema lost al veel op. (en natuurlijk zorgen dat de onderwerp-regel nog klopt als je een bericht beantwoordt) Paul Be. Volgens mij is 'reply' en dan het onderwerp wijzigen niet voldoende. Dergelijke mails komen bij mij (kmail) in threaded view gewoon bij de vorige 'gereplyde' thread terecht. Heeft dacht ik met de Message ID te maken die onveranderd blijft. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] weesperstraat/sarphatistraat-mauritskade
On Sunday 14 June 2009 23:55:15 Christiaan Welvaart wrote: On Sun, 14 Jun 2009, Lambert Carsten wrote: http://www.yournavigation.org/?flat=52.361942flon=4.917075tlat=52.359638tlon=4.906853v=bicyclefast=0layer=mapnik Helaas doet yournavigation het op dit moment het niet goed. Ik had beter een screenshot kunnen bijvoegen. (De tunnel en bijbehorend stuk weg heb ik inmiddels met bicycle=no en foot=no getagged, dus het komt wel goed met die 'shortest' route in die laatste link). Wat voor borden staan erbij? Zie voor tagging voorbeelden: http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging Waar doel je op? Dat je niet door die tunnel mag fietsen of lopen weet ik zo wel. Of een brommer er ook niet door mag zal ik volgende keer dat ik er langs kom nagaan. Yournavigation gaf een route voor de fiets die door die tunnel ging en ik wilde slechts aangeven dat het mij daar niet om ging. De 'snelle' route ging over de Singelgracht, langs de Spinozastraat, stukje Sarphatistraat om weer over de Singelgracht te gaan in plaats van gewoon de Mauritskade te volgen zoals de kortste route. Wat ik raar vind zijn die motorway tags op een weg midden in de stad. Volgens mij zijn die motorway_junction tags alleen bedoeld voor snelwegen. Heeft iemand bezwaar als ik ze verwijder? Of misschien een andere 'key name'? Hier nogmaals de link met osmarender (mapnik toont deze tags niet): http://www.openstreetmap.org/?lat=52.36028lon=4.909zoom=16layers=0B00FTF Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] weesperstraat/sarphatistraat-mauritskade
On Monday 15 June 2009 11:59:08 Christiaan Welvaart wrote: De 'snelle' route ging over de Singelgracht, langs de Spinozastraat, stukje Sarphatistraat om weer over de Singelgracht te gaan in plaats van gewoon de Mauritskade te volgen zoals de kortste route. Ik snap (ook) niet wat die 'snelle' optie doet, ik gebruik altijd 'korste' route. openrouteservice.org heeft die optie niet eens voor fietsers en voetgangers. Een groot voordeel van die routeplanners is dat je fouten vindt die je anders niet of nauwelijks ziet. En al die verschillende opties brengen weer ander fouten aan het licht. Zoals bijvoorbeeld een ontbrekende cycleway=opposite_lane op de Sarphatistraat met gevolg dat een route daar een hele rare 'omleiding' maakte. Natuurlijk zijn de routeplanners zelf in ontwikkeling en dan is het wel prettig om de beperkingen (vooralsnog) te kennen om eindeloos zoeken naar fouten die er niet zijn achterwege te kunnen laten. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenKVK
On Monday 15 June 2009 12:12:36 Stefan de Konink wrote: On Mon, 15 Jun 2009, Richard Korthuis wrote: 2009/6/15 Stefan de Konink ste...@konink.de Dit resulteerde in het project OpenKVK. We zijn op IRC alvast begonnen met het zogenaamde scrapen van de KVK website, zodat deze ook beschikbaar is na twaalf uur 's avonds. Wat is precies het doel van OpenKVK? Wat moet ik me er bij voorstellen? De KVK site 24x7 beschikbaar maken en een API er voor zetten. Spannende dingen als 'laat alle bedrijven van NL op de OSM kaart zien' zou eventueel ook kunnen in de nabije toekomst. Was er niet onlangs een probleem met het herpubliceren van kvk gegevens (of het publiceren door kvk zélf) in die zin dat bekende Nederlanders die een eigen bedrijf hebben (artiesten bijvoorbeeld) zo al te gemakkelijk met hun privé gegevens ge-googled kunnen worden? Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] weesperstraat/sarphatistraat-mauritskade
On Monday 15 June 2009 20:06:45 Martijn van Exel wrote: 2009/6/15 Lambert Carsten lhc@solcon.nl: On Sunday 14 June 2009 23:55:15 Christiaan Welvaart wrote: On Sun, 14 Jun 2009, Lambert Carsten wrote: http://www.yournavigation.org/?flat=52.361942flon=4.917075tlat=52.35963 8tlon=4.906853v=bicyclefast=0layer=mapnik Helaas doet yournavigation het op dit moment het niet goed. Ik had beter een screenshot kunnen bijvoegen. (De tunnel en bijbehorend stuk weg heb ik inmiddels met bicycle=no en foot=no getagged, dus het komt wel goed met die 'shortest' route in die laatste link). Wat voor borden staan erbij? Zie voor tagging voorbeelden: http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging Waar doel je op? Dat je niet door die tunnel mag fietsen of lopen weet ik zo wel. Of een brommer er ook niet door mag zal ik volgende keer dat ik er langs kom nagaan. Yournavigation gaf een route voor de fiets die door die tunnel ging en ik wilde slechts aangeven dat het mij daar niet om ging. De 'snelle' route ging over de Singelgracht, langs de Spinozastraat, stukje Sarphatistraat om weer over de Singelgracht te gaan in plaats van gewoon de Mauritskade te volgen zoals de kortste route. Wat ik raar vind zijn die motorway tags op een weg midden in de stad. Volgens mij zijn die motorway_junction tags alleen bedoeld voor snelwegen. Heeft iemand bezwaar als ik ze verwijder? Of misschien een andere 'key name'? Ik denk dat het wel 'mag' op zich; uit de Map Features: 'Some roads - e.g., the A14 - also carry junction numbers, so the tag may be encountered elsewhere despite its name'. Daaruit lees ik dat op- en afritten van niet-snelwegen ook met motorway_junction zouden 'mogen' worden getagd. Hoe ze vervolgens gerenderd worden is mij niet duidelijk. Ik vind de tag nogal dubbelzinnig, waarom niet een highway=* en dan junction=yes? Alles mag he? :) Het gaat er mij niet om een discussie te beginnen. Ik vind die tags fout maar als er ook maar iemand vindt dat die moet blijven dan blijf ik er met mijn poten van af. Helaas is diegene die de tags heeft aangebracht anoniem, anders richtte ik mijn vraag daar. Deze afslagen hebben geen naam of nummer zoals die waarvoor de motorway_junction is bedoeld. Hier staat gewoon bij die afslag dat die kunt gebruiken om op de ring te komen. Met diezelfde afslagen kun je ook richting ring maar dan via de S116 aansluiting (ijtunnel enz). Leuk die State of the Map 2009 tag trouwens, zie ik nu (pas?) ineens. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenKVK
On Monday 15 June 2009 14:16:35 Hay (Husky) wrote: 2009/6/15 Rejo Zenger osm-talk...@subs.krikkit.nl: Ik weet niet helemaal zeker wat je onder vrij maken verstaat, maar het openkvk.nl project maakt geen data vrij in de zin dat het opeens onder andere gebruiksvoorwaarden beschikbaar komt. Het maakt de data misschien anders beschikbaar dan het nu is (anders qua vorm, anders qua periode van beschikbaarheid), maar het verandert niets aan de aard van de data. Ik bedoelde inderdaad vrij als in bier. Excuses voor de verwarring. In tegenstelling tot bijvoorbeeld de wetteksten is de inhoud van het Handelsregister niet vrij van auteursrechten, denk ik. Wetteksten mogen door iedereen gepubliceerd worden, zonder dat je daarvoor toestemming moet hebben. Bij dit register ligt dat denk ik anders. Het lijkt me dat alleen de de adressen (ik neem aan dat die alleen getoond worden?) gezien kunnen worden als feiten, en feiten zijn niet auteursrechtelijk beschermd. Wat waarschijnlijk wel beschermd is is de database, onder het databankrecht. Echter, de vraag is in hoeverre dat geldig is als je maar een deel van de database gebruikt. Misschien dat Arnoud (Engelfriet) hier eens zijn licht over moet laten schijnen. Copyright is hier niet relevant. Het zou mogelijk gewoon onrechtmatig kunnen zijn die gegevens te herpubliceren. Welk belang is met de (her)publicatie gediend tegenover het belang van diegenen die van de publicatie last ondervinden. Daarnaast, je publiceert mogelijk persoonsgegevens. Ik denk (weet dat niet zeker, ik ben geen jurist) dat indien het vestigingsadres van een kleine ondernemer overeenkomen met zijn NAW gegevens van zijn woonadres, deze vestiginggegevens als persoonsgegevens aangemerkt kunnen worden. Die mag je niet zomaar publiceren. Die zijn nu toch ook al beschikbaar via kvk.nl? Als je mijn naam intikt bij kvk.nl krijg je ook mijn huisadres. Daar verandert openkvk verder niks aan. Ik dacht dat je op grond van de Wet Persoonsgegevens zo'n database moet aanmelden en regels moet opstellen hoe je met die gegevens omgaat. Een goede vriend van mij heeft zich hier ooit erg in verdiept. Ik zal hem vragen of hij hier iets zinnigs over te melden heeft. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenKVK
On Monday 15 June 2009 21:22:47 Lambert Carsten wrote: Een goede vriend van mij heeft zich hier ooit erg in verdiept. Ik zal hem vragen of hij hier iets zinnigs over te melden heeft. Helaas niet: Dit is een uiterst complex gebeuren. Ik word op dit moment al gek van het werk dat ik moet doen. Ik was expert Wet persoonsregistraties, maar die wet is vervangen door de Wet Bescherming Persoonsgegevens. Daar heb ik me nooit in verdiept. Uiterst ingewikkelde materie waar je lang op moet studeren. Die auteurswet kwestie is ook complex. Wat ik zou doen is aan de KVK vragen of ze er problemen mee hebben en zo ja op grond waarvan. Daarna zou ik hun antwoord uiteraard goed tegen het licht houden. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] weesperstraat/sarphatistraat-mauritskade
Hoi. Twee kruispunten in Amsterdam heb ik hoop ik zodanig gerepareerd dat routing daar nu werkt: http://www.openstreetmap.org/?lat=52.36028lon=4.909zoom=16 Echter die 'motorway_junction' tags begrijp ik daar niet. Moeten die daar niet gewoon weg? En begrijpt iemand waarom dit sneller is: http://www.yournavigation.org/?flat=52.361942flon=4.917075tlat=52.359638tlon=4.906853v=bicyclefast=1layer=mapnik dan dit: http://www.yournavigation.org/?flat=52.361942flon=4.917075tlat=52.359638tlon=4.906853v=bicyclefast=0layer=mapnik (De tunnel en bijbehorend stuk weg heb ik inmiddels met bicycle=no en foot=no getagged, dus het komt wel goed met die 'shortest' route in die laatste link). Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Nieuwe Website
On Thursday 11 June 2009 09:25:59 Rejo Zenger wrote: ++ 11/06/09 07:31 +0200 - Maarten Deen: Zoals al eerder aangegeven; Een newbie zal eerder www intikken dan iemand die wat gevorderder is. En het idee is dan ook om op de niet www site wat meer linkjes te gaan zetten naar projecten. Lijkt me eigenlijk geen goed idee. Voor mij is een site zonder www gelijk aan de site met www (dat dat technisch niet zo is weet ik) en ik zal niet denken oh, er is een www.openstreetmap.nl, laat ik ook eens op openstreetmap.nl gaan kijken. Ik vind het ook erg verwarrend. Alleen al het feit dat hier een vraag over wordt gesteld wijst daar op. Dat zijn technisch gezien inderdaad twee verschillende websites. Om verwarring te voorkomen zorgen veel organisaties ervoor dat die twee wel aan elkaar gelijk zijn. Normaliter is de site zonder www ook een redirect naar de site met www. Nee, dat is lang niet altijd zo (tenminste, dat zegt mijn gevoel), maar het is vaak zo dat als een gebruiker een hostname intikt zonder de www ervoor en er geen inhoud door de webserver wordt teruggegeven, de browser er zelf www voor zet en het nog eens probeert. Ik denk dat je dan beter twee tabs op de site kunt maken. Een voor beginners en een voor gevorderden. +1 AOL. ??? http://www.abbreviations.com/AOL Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Nieuwe Website
On Thursday 11 June 2009 12:53:51 Rejo Zenger wrote: ++ 11/06/09 12:38 +0200 - Lambert Carsten: Ik denk dat je dan beter twee tabs op de site kunt maken. Een voor beginners en een voor gevorderden. +1 AOL. ??? http://www.abbreviations.com/AOL Citaat van http://catb.org/jargon/html/A/AOL-.html: | Common synonym for “Me, too!” alluding to the legendary propensity of | America Online users to utter contentless “Me, too!” postings. The | number of exclamation points following varies from zero to five or so. citaat van: http://en.wikipedia.org/wiki/Jargon In many cases this may cause a barrier to communication with those not familiar with the language of the field. :) Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Addresses and POI
On Saturday 06 June 2009 15:35:41 Chris Hill wrote: Jack Stringer wrote: If I gathered the address info from their website then that should not be an issue, should it? Yes it is an issue - the few that I have looked at have terms and conditions that specifically restrict reuse without written permission - you should expect this on most organisations' websites. The address is not some kind of creative work, there is no database just a website confirming that a known address is theirs. I really don't see how copyright comes into this. Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Addresses and POI
On Sunday 07 June 2009 13:33:21 Richard Fairhurst wrote: Lambert Carsten wrote: On Saturday 06 June 2009 15:35:41 Chris Hill wrote: Yes it is an issue - the few that I have looked at have terms and conditions that specifically restrict reuse without written permission - you should expect this on most organisations' websites. The address is not some kind of creative work, there is no database just a website confirming that a known address is theirs. I really don't see how copyright comes into this. Chris was expressly talking about contract (terms and conditions), not copyright. He also mentioned copyright. I didn't quote that bit. Please use the legal-talk list for this kind of thing. I agree, but the original question concerning copyright was asked here. Jack's idea sounds like a really good idea and it would be a pity if he was put off by Chris's over cautious (IMHO) answer. Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Openstreetmap CC-by-SA boek in het Nederlands
On Tuesday 02 June 2009 22:42:27 Milo van der Linden wrote: Ook al in gedachte! Er is echter een maar. als je op wikibooks aangeeft dat je de pdf wilt, dan krijg je een enorme lap licentie, links en een voorpagina, maar geen volledig boek Puntje van aandacht. Als iemand weet hoe de wikibooks optimaal kan worden gebruikt om te resulteren in printed press of pdf, dan houd ik me aanbevolen. Het staat in ieder geval al op mijn netvlies. Dat linkje links betreft alleen die pagina. Een heel boek moet je samenstellen uit de diverse pagina's. Van die samenstelling kun je weer een pdf maken en downloaden. Dan krijg je iets wat op een boek lijkt. Zie: http://nl.wikibooks.org/wiki/Help:Boeken Er zijn ook gebruikers die het een en ander al voor je hebben samengesteld: http://nl.wikibooks.org/wiki/Categorie:Wikibooks:Boeken Bij dat Handboek GIS-visualisatie gaat er echter wat fout wat die samenstelling betreft. Mogelijk is het resultaat te groot (!?), maar een 'eerder klaargemaakte versie' is te vinden hier (in delen): http://nl.wikibooks.org/wiki/Geo-visualisatie/PDF-versie (Dat linkje vindt je als je eenmaal het wiki boek heb geopend, rechtsonder in het inhoudsopgave blok.) Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] relatie bij punt
On Friday 05 June 2009 15:41:28 Maarten Deen wrote: Rene Dohmen wrote: en vraag 3: Er is een weggetje dat geen straatnaambordje heeft. Op een andere bekende kaart staat er wel een naam, maar hoe weet ik zeker wat de naam van dat wegdeel is, als er geen straatnaambordje is? De balie bij de gemeente? Het kadaster (waarbij de gemeente waarschijnlijk het meest logische aanspreekpunt is). Een oplossing die ik een keer gebruikte was een webpagina zoeken van iets dat aan die weg ligt (restaurant of zo) en kijken wat zij als adres publiceren. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] yournavigation weer! :)
De site komt weer tevoorschijn, maar nu krijg ik een gosmore error. Geen klacht maar ter info. On Friday 05 June 2009 08:52:05 Lambertus wrote: De server loopt wel maar de webserver laat niks van zich horen. Ik ben geen admin op die server dus moet wachten tot de admin tijd heeft om het te fixen. Even geduld dus. Lambert Carsten wrote: Hoi, Klopt het dat de yournavigation site uit de lucht is? Ik krijg een Though the site seems valid, the browser was unable to establish a connection. error. Gisteren toen ik het iemand wilde laten zien was de site ook niet bereikbaar. Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] yournavigation weer! :)
Hoi, Klopt het dat de yournavigation site uit de lucht is? Ik krijg een Though the site seems valid, the browser was unable to establish a connection. error. Gisteren toen ik het iemand wilde laten zien was de site ook niet bereikbaar. Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] yournavigation export gpx
Hoi Lambertus, Ik probeerde daarnet een gpx te exporteren op de yournavigation site. In plaats dat ik een download krijg proberen sommige browsers de file als webpagina te openen maar vinden de url wat lang. Ander browsers crashen gewoon. De gpx info wordt dus in een weblink gestopt in plaats van aangeboden in een *.gpx file download. Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] OSM_Map_On_Garmin
Hoi Lambertus, Naar aanleiding van een vraag op de algemene talk viel mij op dat jouw project: http://garmin.na1400.info/routable.php Niet genoemd wordt op deze pagina: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin Het zou volgens mij daar toch genoemd moeten worden lijkt mij, ook al heb ik geen Garmin? Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM_Map_On_Garmin
Oops, ik zie net te laat dat het achter een 'download' link staat op die wiki pagina!: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download lambert Subject: OSM_Map_On_Garmin Date: Wednesday 27 May 2009 From: Lambert Carsten lhc@solcon.nl To: talk-nl@openstreetmap.org Hoi Lambertus, Naar aanleiding van een vraag op de algemene talk viel mij op dat jouw project: http://garmin.na1400.info/routable.php Niet genoemd wordt op deze pagina: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin Het zou volgens mij daar toch genoemd moeten worden lijkt mij, ook al heb ik geen Garmin? Met vriendelijke groeten, Lambert Carsten --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Nederlandse website
On Tuesday 19 May 2009 11:24:38 Stefan de Konink wrote: En ook niet echt voor Garmin gebruikers of Mashup makers etc. Daarmee komt de vraag of we een aggregatie moeten zijn naar Nederlandse projecten, of slechts een informatie punt (in het Nederlands) voor Nederlandse gebruikers. Vooral dit mis ik (beide dus). Regelmatig lees ik hier op talk-nl over al die geweldige projecten. Als ik ergens anders ben of er is wat tijd overheen gegaan zit ik eindeloos te googelen om 'hoe heette dat ook al weer' te vinden. Maar belangrijker in dit verband is dat ik graag anderen zou willen verwijzen naar een alternatief voor googlemaps, anwb route planner enz. enz. waar zij dan vervolgens al die fantastische projecten kunnen vinden. Een makkelijk te onthouden site www.openstreetmap.nl lijkt mij (oa.) daarvoor het meest voor de hand te liggen. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Fwd: [OSM-talk] Local list contacts
Omdat 'wij' ons nog niet hebben aangemeld stuur ik dit even hier door mochten er talk-nl' ers zijn die niet de algemene mailing list volgen. Ik wil mijzelf niet aanmelden (als enige) want ik heb perioden dat ik mijn email niet lees! Wel ben ik redelijk twee-talig mocht dat een reden zijn dat niemand van de OSM-NL zich hiervoor heeft aangemeld. Dus ik kan wel behulpzaam zijn met vertalen. Lambert Carsten -- Forwarded Message -- Subject: [OSM-talk] Local list contacts Date: Monday 11 May 2009 From: SteveC st...@asklater.com To: Talk Openstreetmap t...@openstreetmap.org Dear all The various mailing lists have grown well organically and there are great contributions, debate and discussion on them. In order to more efficiently and clearly trickle down announcements like server downtime to the local lists, we've created a 'list of lists' for people to help take announcements and translate them to the local lists. http://lists.openstreetmap.org/listinfo/local-contacts If you would like to help by being the local contact for a list (which doesn't necessarily have to be the same person as the list maintainer, but could be) then please sign up. You will help by taking any announcement sent there and sending it on, maybe translating it too, to your local list. This includes English-speaking lists like talk-au, talk-us, talk-gb-midlands Please sign up here: http://wiki.openstreetmap.org/wiki/Local_Contacts and for bonus points help clean up that page. Best Steve ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] lagedijk Noord-Holland
On Wednesday 25 February 2009 14:10:57 Floris Looijesteijn wrote: Nog wat, de route die daar wordt berekend is volgens mij zo slecht nog niet. Je kunt lekker een stukje honderd, en je hoeft niet over de smalle vlotbrug over het kanaal. Voor de rest is het een kwestie van afwegingen in yournav. Het zou mij om het even zijn welke route ik zou nemen, ik ga zelf zelden over de vlotbrug. Ik was een beetje aan het spelen met Navit op mijn nieuwe eeepc toen ik naar Den Helder ging. Zelfs vlak bij Alkmaar gaf Navit aan dat ik nog 90 km te gaan had omdat de route om onduidelijke redenen niet de ringweg daar wilde nemen om vervolgens via de N9 naar Den Helder te gaan. Het leek alsof de N9 ergens niet goed aansloot. Toen ik later probeerde uit te zoeken waar het aan lag kwam ik die Lagedijk tegen waar Navit perse langs wilde. Die vlotbrug maakt voor Yournavigation niets uit. Als je een 'to' punt kiest aan de andere kant van het kanaal gaat de route toch via de Lagedijk. Qua tijdsduur denk ik dat beide routes gelijk zijn. floris Ik rij daar vrij vaak (ben in de buurt geboren) en het is een autoweg, dus volgens mij trunk. Je bent misschien in de war met de N9, die er aan het begin vlak langs loopt, dat is inderdaad een primary (alhoewel daar veel meer verkeer over gaat). Het is daar inderdaad 100km/h tot aan Anna Paulowna. Dat is al jaren zo en ik hoop dat het ook zo blijft, het is namelijk een erg fijne weg en sinds de rotondes bij de kruizingen ook veilig. Tja de N9 leek mij logischer maar kennelijk dus niet. Nu moet ik er alleen uit nieuwsgierigheid er volgende keer langs :) vr.gr. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] lagedijk Noord-Holland
Dag Floris, Ik snap de tagging niet van de Lagedijk (N249) in Noord-Holland. Je hebt het als een trunk road getagged. Volgens mij moet het primary zijn maar dat was het voordat jij het wijzigde. Grote stukken hebben bovendien als maximum snelheid 100km/uur. Kan dit echt kloppen? Ik ben er zelf niet overheen geweest dus ik wil het niet naar 'logische' aannames veranderen. De route planners willen steeds over die weg in plaats van over de rijksweg (N9). Ik denk dat die tags daarvan de oorzaak is want in die N9 kan ik niets verkeerds vinden. Als je het niet meer weet ga ik er volgende keer dat ik die kant op ga er wel langs. (kan wel een maand of twee duren!) Hier is een link naar die weg: http://www.openstreetmap.org/?lat=52.8355lon=4.786zoom=13layers=B000FTF En hier naar yournavigation waar je ziet dat de route planning een volgens mij onlogische route neemt: http://www.yournavigation.org/?flat=52.8123flon=4.73032tlat=52.837402tlon=4.754353v=motorcarfast=1layer=mapnik Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] bounderies
On Tuesday 02 December 2008 15:52:39 Eugene van der Pijll wrote: Lambert Carsten schreef: Ik heb even een screenshot van gemaakt en bijgevoegd. Helaas vallen de grenzen weg bij het inzoemen. De AND data is misschien toch wat verouderd. Dit soort informatie moet toch ergens openbaar zijn? Het is gewoon de uitkomst van bestuurlijke besluitvorming! Als iemand weet waar die informatie is te vinden dan hoor ik dat graag. Op de website van de gemeente. Googlen op gemeentegrens ouder-amstel levert de volgende link op: http://www.ouder-amstel.nl/ouder-amstel/incontact/productie/basis/ic_webge n.nsf/page?openagentid=_E0EE4AD1CBB10941C1257348004E6654 Nog een link: http://home.wanadoo.nl/sic/maps/grens.html Dus je hebt gelijk, de grens is sinds 2006 veranderd, en onze data is niet meer actueel. Dat heb je mooi gevonden, ik was nog niet zover! Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] bounderies
Hoi, Ik kwam een raar verloop tegen van de gemeente grens in Amsterdam: http://www.openstreetmap.org/?lat=52.33308lon=4.92431zoom=16 Volgens de history in Potlach zijn die boundaries ruim een maand geleden opnieuw geïmporteerd uit AND. (Het betreft hier Way: #27963078.) Weet iemand mij te vertellen waar ik informatie kan vinden om die grenzen te corrigeren? (En die ik mag gebruiken uiteraard!) Met vriendelijke groeten, Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] bounderies
On Monday 01 December 2008 18:44:41 you wrote:
Lambert Carsten schreef:
Ik kwam een raar verloop tegen van de gemeente grens in Amsterdam:
http://www.openstreetmap.org/?lat=52.33308lon=4.92431zoom=16
Wat is daar vreemd aan?
Misschien is deze link iets beter voor josm:
http://www.openstreetmap.org/index.html?mlat=52.33358488334535mlon=4.919190258055218zoom=16
Het gaat in de eerste plaats om dat industrie terrein bij ('boven') de Hemweg.
Gemeente grenzen lopen toch niet dwars (schuin zelfs) door gebouwen heen?
Het is wel een tijd geleden, maar een stuk of 6 gemeentegrens borden heb ik
toch echt niet over het hoofd gezien. Eén weet ik er te staan en die staat in
de bocht van de Spaklerweg, als het goed is middin in deze link:
http://www.openstreetmap.org/?lat=52.333732lon=4.922701zoom=18layers=B000FTF
Vermoedelijk loopt de grens daar langs (ten zuiden van) de Hemweg.
Ondanks de rechte lijn is de grens die door dat Wenckelbach gebied gaat ook
verdacht.
Maar goed ik vroeg mij af of iemand wist hoe of waar ik zo'n grens kan
verifiëren zonder meteen te gaan 'wobben'.
Vriendelijke groeten,
Lambert
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] clean gpx tracks
On Thursday 25 September 2008 17:21:59 Richard Fairhurst wrote: Lambert Carsten wrote: This decision needs more thought. Although I personally don't have a privacy issue here there are clearly those that do Just don't set your track as public - then the timestamps won't be exposed. I am not looking to just solve my own personal 'problem'. What concerns me is that someone has made a decision that doesn't seem to be motivated and it is unclear (to me at least) who made it. I think that is a problem for an organization like openstreetmap. The issue itself is not insignificant for more than one reason. My concern is about good data and this 'rule' makes it a lot harder for me to upload clean data. Others might be concerned about privacy and change the data. And others again might not make their data available to save themselves the hassle of changing the data. Lambert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] clean gpx tracks
On Thursday 25 September 2008 18:53:00 Andy Robinson (blackadder-lists) wrote: It is not intended to protect OSM against infringement at all. It's there as a statement about the ethos of the project that you don't upload data from copyright sources. Of course we all know it's possible to circumvent, but that goes against the ethos of the project and hence the community wouldn't stand for abuse if it was spotted. That is why we want all the tracks that we can get so anybody trying to 'infect' the data with copyrighted material doesn't have a hope in hell since there is so much more from non copyright sources. As far as I am aware the requirement for a timestamp was established by the project founder SteveC when he first set up the system all those years ago, it's engrained within the very basis of the project and thus unlikely to ever change. I really don't get this. Although I am not a programmer I find it very hard to believe that the 'importer' cannot be changed to accept tracks without time stamp data. O.k. so the decision was made at a very early stage, so that is why there is no real record of it. But if it is a bad decision (with hindsight of course and under different circumstances: geotagged photos, Yahoo imagery etc)), that is to say it has negative effects, it seems only logical to change it. As has been pointed out, if you don't want to expose the timestamp simply don't make your trace public. What I personally want is to upload clean data because it helps me as a mapper when there is as little noise as possible in the gps data. So therefore I don't want to burdon others with my noisy data. I want to upload my tracks because when I enter data I like every bit of confirmation that my data is good, that I can get. Obviously if I like others to upload their tracks I need to upload mine, that's the basis of why a project like this works! If I could cut out the garbage out of my tracks as easily as I can in Josm but without destroying the timestamp info the issue that triggered this 'quest' would be gone (or rather would not even have come up). However the other issues I hadn't thought about before remain. If people are not uploading their tracks because of privacy issues it is a loss to everyone. The question with any 'rule' always remains: is it useful, is it adding or taking away? Anyone wanting to know about the map data will be looking at the history of the data item for the contributor details rather than who made perhaps one of the many GPX tracks that lie underneath. Absolutely, common sense approach is best! Lambert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] fietsknooppunt
Hoi. Gisteren een ommetje gefietst en kwam op mijn route fietsknooppunt 61 tegen in Oudekerk aan de Amstel: http://www.openstreetmap.org/index.html?mlat=52.29888533560902mlon=4.899669170379639zoom=16 De hele kruising inclusief de brug over de amstel is onderdeel van het knooppunt. Als ik het goed begrijp moet een node met rcn_ref=61 getagd worden. Moeten nu al die diverse nodes die bij de kruising betrokken zijn en waar een keuze mogelijkheid bestaat met cn_ref=61 getagd worden? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsknooppunt
On Sunday 14 September 2008 13:51:26 Lennard wrote: Lambert Carsten wrote: De hele kruising inclusief de brug over de amstel is onderdeel van het knooppunt. Als ik het goed begrijp moet een node met rcn_ref=61 getagd worden. Moeten nu al die diverse nodes die bij de kruising betrokken zijn en waar een keuze mogelijkheid bestaat met cn_ref=61 getagd worden? Nee, alleen de nodes op dat kruispunt waar je daadwerkelijk een keuze kunt maken, dus waar routes naar andere knooppunten afsplitsen. Mijn probleem is dat bij het kruispunt er een heleboel 'fietsknooppunten' zijn als gevolg van gescheiden fietspaden. Wanneer de fietspaden accuraat weergegeven worden heb je op een standard kruispunt al gauw 4 'nodes' waar de fietsroutes keuzemogelijkheden hebben. In bovenstaand geval heb je dan ook nog een brug over de amstel waardoor het knooppunt nog verder uit elkaar getrokken wordt. Als de 'centrale' node van het kruispunt de rcn_ref krijgt, dan is dat nét de node waar geen enkele fietsroute precies overheen gaat. Pak ik gewoon een van de fietsnodes dan zal dat op een gerenderde kaart er prima uitzien maar route planners zullen mogelijk ervan in de war raken. Dat gaat er dus toe leiden dat op openfietskaart.nl en opencyclemap.org (naar keuze) meer dan 1 knooppunt gerenderd wordt met hetzelfde nummer. Mijn huidige voorbeelden zijn nog niet gerenderd in openfietskaart.nl, dus even een voorbeeld van de zuiderburen: http://www.openfietskaart.nl/?zoom=15lat=51.07765lon=4.16527layers=B FTTFFFTT Dat ziet er prima en logisch uit, maar daar is er maar één node bij ieder kruispunt. Ik neem aan dat je nog niet de rcn relations maakt voor het fietsknooppuntennetwerk? Nee, inderdaad, ik ben geen fietsroutes aan het fietsen, maar probeer een nuttige track te genereren en zoveel mogelijk informatie te verzamelen m.b.v. een fototoestel. Toch zou (en zal) ik die stukjes route ook moeten invoeren. Want dan kun je ook nog wat speciale dingen uithalen om zo'n gesplitst knooppunt te vatten in de relations. Is de oplossing via relations om een relation te maken met type=junction en als member alle betreffende nodes (dus daar waar gekozen kan worden) op te nemen? Zo ja, moeten dan de ways die die nodes verbinden daarin ook worden opgenomen? En verder gewoon rcn_ref=61 (en dus NIET name=61 of ref=61)? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsknooppunt
On Sunday 14 September 2008 15:37:24 Ldp wrote: Wat ik nu doe, stel het volgende idee: 7080-8090 Het uitgangspunt is dat je op een knooppunt afrijdt, en bij het eerste het beste knooppuntbordje de route naar het volgende knooppunt gaat volgen. Zo zijn de knooppunten (zoals ik ze ken) ook bebordt. Dus als je van 70 naar 80 rijdt, ga je bij het linker bordje 80 al de route naar 90 volgen, maar als je van 90 naar 70 gaat, ga je bij het rechter bordje 80 de route naar 70 volgen. Relatie 1 loopt dus van 7080-80, waarbij het stukje 80-80 een forward of backward role krijgt -- afhankelijk van de onderliggende way(s)! -- zodanig dat je die alleen van rechts naar links kan volgen. Relatie 2 loopt van 80-8090, waarbij het stukje 80-80 ook een forward of backward rol krijgt, tegenovergesteld aan die van Relatie 1. Een routeplanner die je van 70 naar 80 leidt, zal dus bij het linker bordje de conclusie moeten trekken dat a) je op 80 bent en b) dat je het resterende stukje van de relation niet kan fietsen, want dat is tegen de richting in. Uit die conclusie zal dan moeten volgen dat je vanaf dat moment de route/relation naar 90 gaat volgen. Als je een complexer knooppunt hebt, zoals in jouw geval, kun je dit ook op bovenstaande wijzen taggen, maar het is wel wat meer werk. Knap ingewikkeld maar Ik geloof dat ik het begrijp, ook als ik naar dat voorbeeld in België kijk. Ik betwijfel of deze oplossing het op termijn overleeft, maar bedankt! Gelukkig (!) heb ik maar één route om in te voeren :-) Het gevoel bekruipt mij dat het voldoende moet zijn om de knooppunten in te voeren en dat de eigenlijke routes zelf door een routeplanner moeten worden berekend. Dat lijkt mij juist de hele idee van een knooppunten netwerk in plaats van een route netwerk. Maar goed dat is een heel ander discussie voor een andere keer. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
On Monday 08 September 2008 10:36:46 Roeland Douma wrote: Trunk road is toch hier in nederland gewoon autoweg? http://wiki.openstreetmap.org/index.php/Nl:The_Netherlands_roads_tagging Want primary zijn de wegen door de een stad (Sxxx) ook en daar mag je dan vaak wel weer fietsen. Om de ijtunnel een trunk tag te geven is wel wat voor te zeggen. Het probleem is echter volgens mij dat er op dit moment voor elk type weg een lijst 'implied access restrictions' niet (lijkt?) te bestaan. Als mapper kun je dan ervoor kiezen een weg te taggen op basis van de restricties van de weg ofwel de classificatie door de overheid (wegnummering Axx, Sxx enz.) te volgen en indien nodig access tags toe te voegen On Monday 08 September 2008 11:11:16 Geert Schuring wrote: Precies. De werkgroep Tagging standaard heeft de 12e een meeting bij mij thuis waar we beginnen met het opstellen van een standaard voor autowegen, inclusief alle impliciete en expliciete tags die daarbij horen. Hartstikke mooi! Een autoweg staat echter al vast: dit is een highway=trunk, en krijgt impliciet het volgende mee: maxspeed=100, bicycle=no, foot=no. Impliciet betekend dat deze tags alleen toegevoegd *moeten* worden aan de weg als ze afwijken van de default, ze *mogen* altijd worden toegevoegd. Te overwegen valt om voor de belangrijke hoofdwegen (motorway, trunk en eventueel primary) de boel om te draaien en dus als impliciete tags access=no, motorcar=yes enz. te nemen Mogelijk dat je daarmee voorkomt dat nieuwe tags (segway, golfcart...) niet impliciet ineens de snelweg op mogen. Uiteraard kan de lijst met impliciete verboden worden steeds worden bijgewerkt, maar wij weten inmiddels dat een systeem van eerst alles toestaan en later de boel dicht gooien als er iets niet goed gaat, in de praktijk voortdurend voor problemen zorgt. De werkgroep beperkt zich in eerste instantie tot standaarden voor auto's, fietsers en wandelaars. Pas wanneer deze standaarden volledig uitgewerkt zijn zullen standaarden voor vrachtverkeer, motoren, noodhulpverleners en andere veel voorkomende vormen van verkeer worden vastgelegd. Je moet ergens beginnen! Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk] Garmin release source code
Hi, This might interest someone on this mailing list: http://www.pcworld.idg.com.au/index.php/id;1756347190 Lambert Carsten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk-nl] Welke tags gebruiken we?
Hoi Geert, Ik was even weg van mijn email vandaar mijn late reactie. Het lijkt mij zowiezo beter om naar de talk lijst te posten. Er lezen veel mensen mee en vaak komen er interessante opmerkingen. On Thursday 05 June 2008 09:18:05 Geert Schuring wrote: - Een weg met een fietspad erlangs. cycleway=lane toevoegen - Een weg met een stukje berm en dan een fietspad erlangs. cycleway=track toevoegen - Een weg met een rij paaltjes en dan een fietspad erlangs. cycleway=track toevoegen Ah het onderscheid tussen cycleway=lane/track kende ik nog niet. Heeft dat ook effect op de rendering? En neemt de fietskaart dit soort dingen goed mee? Weet ik niet, maar het onderscheid is opgenomen in de map features: http://wiki.openstreetmap.org/index.php/Map_Features#Cycleway Met name als je niet een aparte way wilt maken (teveel werk, weinig toegevoegde waarde enz.), vind ik het wel handig en duidelijk. Bovendien je vraag geeft al aan dat jij dat onderscheid (wel/niet berm enz.) ook ziet. Afhankelijk van de situatie, meestal als gevolg van kruispunten, is nodig om de cycleway=track een eigen way te geven. In dat geval is het highway=cycleway met de cycleway=track. Dat eerste impliceert het laatste, maar 'losse fietspaden' tag ik altijd met beide. Dat lijkt me niet helemaal correct. Dan heb je dus eigenlijk een fietspad met een los fietspad ernaast. Nee, ik bedoel dat in de praktijk bij een highway die tevens de cycleway=track tag heeft, het vaak lastig kan zijn een kruispunt goed weer te geven. De oplossing is dan om die 'cycleway=track' of 'cycleway=lane' te verwijderen en een aparte way te maken alleen voor de fietspad (met dus highway=cycleway en cycleway=track). Ik bedoel maar aan te geven: Is een gesloten zand weg met een astfalt fietspad erlangs gewoon een fietspad, of is het een zandweg waar je ook kunt fietsen? Ik zou zeggen twee aparte ways. Hm, ik zou juist concluderen: highway=unclassified surface=unpaved cycleway=track Zou kunnen, maar als fietsroutes rekening (gaan?) houden met de surface slaan ze deze fietspad over als om een mooie gladde fietsroute wordt gevraagd. Of een fietspad naast een weg verhard of onverhard is laten we dan maar even in het midden. Ik vind dat minder want zo'n onverharde weg is voor het overige verkeer waarschijnlijk niet zo belangrijk (waarom is die onverhard en gesloten?), terwijl een aparte asfalt fietspad voor fietsers (waar bovendien geen andere weg is?) zéér belangrijk kan zijn. mvg Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags gebruiken we?
On Thursday 05 June 2008 09:07:19 Geert Schuring wrote: - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor auto's en motoren? (rond wit bord, rode rand met auto en motor in het wit) highway=track access=no bicycle=yes foot=yes access=no is wel een goeie, maar hiermee kun je niet aangeven wat nou precies wel en niet erin mag. Een brommer mag er namelijk wel rijden, maar een motor niet. Vooralsnog moeten wij óf alles opsommen wat er wel mag óf alles wat niet mag. Het nadeel van die niet bestaande hiërarchie in de osm restriction tags is wanneer een nieuwe restrictie aan de map features wordt toegevoegd. Ik verzin maar wat segway=yes/no. Dat moet dan handmatig bij de bestaande restrictie tags worden toegevoegd op een volkomen niet systematische wijze. Ik heb erover nagedacht om een proposal te doen om (een deel) van de access tags een hiërarchie te geven, maar ik ben niet veel verder gekomen dan dat ... :} Als er eenmaal een hiërarchie is dan kan volgens mij betrekkelijk eenvoudig de bestaande tags automatisch worden aangepast. mvg Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] renederen (hoofd)steden
Hoi, Is er iemand die kan uitleggen hoe het renderen van hoofdsteden toegaat? Wat mij opviel was de (voor mij) vreemde keuzes om op de verschillende zoom levels belangrijke steden (zoals hoofdsteden) wel of niet aan te geven. Het lijkt allemaal behoorlijk willekeurig. Voorbeelden: Amsterdam is zichtbaar op zoom 4,5, 9,10 en 11 Bruxelles zichtbaar op 4 en 5 en als 'Brussel - Bruxelles' op zoom 7 en 8 Paris zichtbaar op zoom 4, 5, 8, 9, 10, 11 London en Berlin zichtbaar op zoom 4 t/m 11 (ik heb vooral via www.openstreetmap.org gekeken en niet naar de andere tile servers, maar tile.openstreetmap.nl doet volgens mij hetzelfde voor zover van toepassing) Wat ik heb kunnen vinden is wat onduidelijkheid m.b.t. tot de nog niet in de map features opgenomen tag 'capital='. Die wordt soms ingevuld met 'country' en soms met 'yes'. Dat laatste lijkt onjuist/onhandig zie: http://wiki.openstreetmap.org/index.php/Proposed_features/capital (althans zonder bijkomende admin_level tag). Verder zie je bijvoorbeeld wel 'Haarlem' terwijl 'Amsterdam' niet zichtbaar is. Waarschijnlijk is dit omdat Haarlem een population tag heeft en Amsterdam (nog) niet. Toch zou je denken dat een place=city tag zonder population tag boven een place=town tag met de population tag. m.v.g. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] renederen (hoofd)steden
On Wednesday 04 June 2008 12:38:20 Martijn van Oosterhout wrote: Verder zie je bijvoorbeeld wel 'Haarlem' terwijl 'Amsterdam' niet zichtbaar is. Waarschijnlijk is dit omdat Haarlem een population tag heeft en Amsterdam (nog) niet. Toch zou je denken dat een place=city tag zonder population tag boven een place=town tag met de population tag. Dat zou je denken, maar de code bestaat niet... Dus korte termijn 'oplossing' is om de population tag toe te voegen bij steden die op sommige zoomlevels verdwijnen? m.v.g. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] renederen (hoofd)steden
On Wednesday 04 June 2008 13:15:57 Rob wrote: de population tag doet helemaal niets Weet je dat zeker? Haarlem en Almere zijn beiden een city net als Amsterdam. Alleen Amsterdam heeft geen population tag. Voor alle zekerheid maar een population tag toegevoegd, dat kan in elk geval geen kwaad. kan ook zijn dat sommige plaatsen wegvallen door overlap prevention van de teksten.. Dat 'Paris' het verliest van 'Saint-Ouen' is toch raar. Saint-Ouen is als town getagged en Paris als een city? Overigens heeft Saint-Ouen een population tag en Paris niet! (http://www.openstreetmap.org/?lat=50.82lon=5.02zoom=7layers=B00FT) Dus toch ook daar maar een population tag toegevoegd :) On Wednesday 04 June 2008 13:40:41 Richard Duivenvoorde wrote: uit, maar de verdeling nu: cities towns en villages is wat grof. Maar die verdeling is er dus wel? On Wednesday 04 June 2008 14:59:49 Martijn van Oosterhout wrote: Tja, ik heb niet zo'n zin om elke plaats een expliciet index te geven, waarschijnlijk zal het gebaseerd worden op de place tag. Maar ja, de code is er nog niet :) Het is mij niet duidelijk of dit systeem een tag in de osmdata genereert of dat uit de osmdata die index wordt gemaakt. Wat ik gewoon raar vind is dat 'Paris' en 'Amsterdam' op sommige lager zoomlevels verdwijnen. Als ik voor het eerst op de site van openstreetmap was, dan zou het mij al snel een slechte indruk geven wanneer belangrijke steden vrij willekeurig worden weergegeven. In eerste instantie dacht ik dat Brussel geen tag had toen ik in de omgeving iets zocht en maar nergens Brussel zag staan. En omdat ik niet begreep (en misschien nog steeds niet:) ) wat het verschil maakt wist ik niet, en dus óf en wat ik eraan zou kunnen doen. Buiten deze (volgens mij relatief eenvoudige) gevallen begrijp ik heel goed dat er genoeg problemen zijn. Lege gebieden met alleen dorpjes of dichtbevolkte gebieden met veel steden, grootte van de text enz. enz. Daarvoor zal waarschijnlijk een fijnmaziger zoals de z_index nodig zijn. Heeft het zin om de capital tag te pushen naar de 'officiële' map features. Lijkt mij op zichzelf een zinnige tag? Ik begrijp niet goed waarom die niet al in de map_features is opgenomen. m.v.g. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags gebruiken we?
On Wednesday 04 June 2008 16:53:02 Geert Schuring wrote: Hallo, Ik heb een vraagje over het gebruik van tags. Bij mij in de omgeving (Ede) ben ik bosweggetjes in kaart aan het brengen, en bij het toevoegen aan OSM vroeg ik me het volgende af: Hoe tag je de volgende situaties: - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor alle verkeer. (rond wit bord, rode rand) access=no toevoegen - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor auto's en motoren? (rond wit bord, rode rand met auto en motor in het wit) Dit is een stuk moeilijker omdat (volgens mij) er geen hiërarchie is in de osm access restricties, dus motorcar=no impliceert niet goods=no (lichte vrachtwagens), terwijl dat (alweer IMHO) wel in het verkeer geldt. Dus met motorcar=no en motorcycle=no ben je er volgens mij niet. Ik zou access=no , foot=yes en bicycle=yes toevoegen. - Een weg met een fietspad erlangs. cycleway=lane toevoegen - Een weg met een stukje berm en dan een fietspad erlangs. cycleway=track toevoegen - Een weg met een rij paaltjes en dan een fietspad erlangs. cycleway=track toevoegen Afhankelijk van de situatie, meestal als gevolg van kruispunten, is nodig om de cycleway=track een eigen way te geven. In dat geval is het highway=cycleway met de cycleway=track. Dat eerste impliceert het laatste, maar 'losse fietspaden' tag ik altijd met beide. Ik bedoel maar aan te geven: Is een gesloten zand weg met een astfalt fietspad erlangs gewoon een fietspad, of is het een zandweg waar je ook kunt fietsen? Ik zou zeggen twee aparte ways. mvg Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Nederlandse BoundingBox?
On Sunday 01 June 2008 01:05:17 Stefan de Konink wrote: Sander Hoentjen schreef: Diegene die meelezen op de devlijst weten dat ik een eigen api server aan het maken ben in C. Nu weet ik uit het verleden dat er ergens een boundingbox is om alleen NL te downloaden. Dan wel NL uit een planet bestand te halen. Zou iemand me een linkje kunnen geven naar een recente NL planet? bedoel je: http://hypercube.telascience.org/planet/ Dat ziet er bruikbaar uit :) Ik ga even importeren :) Misschien heb je hier ook wat aan: http://download.geofabrik.de/osm/europe/ Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Hoe layer zien / instellen?
On Monday 21 January 2008 17:50:35 Hans Bakker wrote: Er is een shape waarmee het landuse=industrial aangemerkt wordt. Deze overlapt met het water, dus er moet ergens aangegeven zijn wat boven en onder komt. Nee, want de landuse=industrial tag zorgt er alleen voor dat de renderaar dat gebied een ander kleur geeft. De grens tussen land en water wordt niet door deze tag bepaald. Als het er dus om gaat dat er teveel water is dan moet de betreffende way (natural=water) aangepast worden. Het schijnt dat het soms mis gaat bij het renderen (bospaden die verdwijnen onder een groene deken). Dat is dan op te verhelpen door het gebied layer=-1 te geven. Het is juist goed dat de landuse=industrial way overlapt met het water want dan is die eenvoudiger te editen. Hoe kan ik in josm zien bij welke layer een node hoort? Elementen in OSM zitten niet in een layer. Zij kunnen wel een layer tag hebben om bij kruisende 'ways' aan te geven wat boven en wat onder zit. Nodes hebben voorzover ik weet niet een layer tag. Althans dat hoort volgens mij niet (alles kan namelijk). Een weg die over een ander weg loopt moet een layer tag krijgen met een nummer hoger dan wat eronder ligt. Alles wat geen layer tag heeft wordt beschouwd layer=0 te hebben. Met eilanden in water moet ook de layer tag gebruikt worden om daar droge voeten te houden. alt+P geeft in Josm de properties scherm (rechts in beeld). Als je een element selecteert zie je alle tags van dat element en eventueel de layer tag. De 'layer tag', 'layers' in Josm en de 'layers' van de tileservers hebben niet betrekking op hetzelfde! Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Hoe layer zien / instellen?
On Monday 21 January 2008 19:35:46 Hans Bakker wrote: Waarschijnlijk is het water correct en is het land er doorheen getekend om snel even de grote lijnen aan te geven, en maakt het voor de kaart niet uit omdat het water toch wel over het land heen getekend wordt. De landuse tag is niet om het land aan te geven maar om het gebruik duidelijk te maken door het een kleurtje te geven. De grens tussen land en water wordt bepaald door de water=natural. Dus aan één kant van die way is het land, de andere kant is water. Welke kant van die way water is en welke land wordt bepaald door de richting van de way. Om die richting te zien moet je in de preferences in Josm 'Draw Direction Arrows' aanvinken. Uit AND todo (http://wiki.openstreetmap.org/index.php/AND-NL:_Todo): Ik zie ook vaak (op luchtfoto's) dat het water van AND te breed is, ik weet niet of dit een lokaal probleem is maar ik denk dat je veilig een kanaal wat smaller kunt maken als blijkt dat je er met een goede GPS trace doorheen lijkt te fietsen... Freek 16:23, 26 Wegen, water en industriegebieden kunnen op bepaalde nodes'aan elkaar zitten. Dat is geen fout, maar mag in voorkomende gevallen worden geschoond, om e.a. beter te kunnen overzien. Kortom de grens is daar waar de way met natural=water (of 'coastline' elders). Ik weet dat er een tag voor is, maar die is nog proposed (http://wiki.openstreetmap.org/index.php/Proposed_features/FIXME). Mogen die dan toch gebruikt worden? Alles mag. Renderaars (of welk ander programma ook) houden echter alleen rekening met bekende overeengekomen tags. Dus hoe minder standard, bekend enz. hoe minder effect en dus zinvol. Een standard fixme tag is handig omdat bijvoorbeeld iemand die erg veel weet van een bepaald gebied zou kunnen filteren op de fixme tag, en dan correcties aan kan brengen. Wellicht dat de fixme tag in de toekomst automatisch een bericht kan stuuren naar een OSM'er die er dan op uit gaat. Voorlopig helpt het alleen waarschijnlijk jezelf. Overigens helemaal eens met de opmerkingen van Cartinus (Martijn Verwijmeren). Die Multipolygon wist ik nog niet, bedankt! Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] subway
On Wednesday 19 December 2007 10:07:27 Lambert Carsten wrote: In Amsterdam heeft een stuk van de Weesperstraat een tag railway=subway gekregen. Dit is volgens mij niet juist: -De metro kan onmogelijk nodes delen met de weg. -De layer van de metro is duidelijk lager dan die van de weg, maar een way kan niet tegelijkertijd in verschillende layers zitten logischerwijze. -Waar komt de data vandaan? GPS werkt niet onder de grond, op sateliet foto's is de metro niet te zien, of is dit laatste echt gezeur? :-) . Kan ik die tags gewoon verwijderen? Hier is geen reactie op gekomen dus heb ik die tags verwijderd. Ondertussen heeft Martijn van Exel de subway uitgebreid naar halte Wibautstraat. Het is wel een nieuwe way (dus niet de oorspronkelijke highway getagged met railway=subway), maar er zijn nodes die gedeeld worden met een highway. Verder is die way getagged met highway, ref, oneway e.d. oftewel de way is gekopieerd van de wibautstraat. Wat is hier aan de hand? Kun je (Martijn van Exel) hier even naar kijken of anders uitleggen wat je bedoeling is? Dan weet ik of ik er verloopig af moet blijven. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] subway
On Thursday 17 January 2008 14:09:28 Martijn van Exel wrote: Toevallig, ik liep er idd. ook tegenaan en was begonnen te werken aan het maken van een afzonderlijke way voor de metro, maar moest nog worden afgemaakt. Nog niet aan toegekomen. Ik wil het wel graag afgemaakt zien en heb er waarschijnlijk zaterdag tijd voor. Mooi, dan blijf ik er verder vanaf. Als jij het eerder wilt doen; laat je niet tegenhouden! Ik ben niet zo bekend met de metro lijnen dus dat laat ik liever aan een ander over. Ik ga trouwens zowiezo liever fietsen. De reden dat ik er over begon is omdat als ik fouten tegen kom dan wil ik die graag verbeterd zien. Hoe hoger de kwaliteit hoe meer kans dat allerlei professionele organisaties (overheid, routeplanners, etc.) het OSM bestand gaan gebruiken. En dan zullen zij het bestand waarschijnlijk in hun eigen belang ook gaan bijwerken. Volgens mij is dit nodig gezien de hoeveelheid informatie. Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] Roulette op de Fiets
Dag Gerco Kees, Jij hebt een stukje fietspad gemaakt die dwars door het gebouw (oa. Casino) gaat aan de Max Euweplein. Omdat het een onderdeel van een route is kan ik dat stukje niet zomaar verwijderen. Ik heb mij nog niet verdiept in route tagging. Ik neem aan dat die route over de Max Euweplein loopt. Een deel van wat jij getekend heb is wel een voetgangers doorgang, maar zeker geen fietspad. Ook is er niet een tweede brug die daar over de Singelgracht gaat. Zou je dat even willen corrigeren, ik heb geen tijd om mij in dat route tagging te verdiepen? :) Voor een overzicht van de situatie hier een link naar google: http://maps.google.com/maps?f=qhl=engeocode=time=date=ttype=sll=37.0625,-95.677068sspn=49.357162,80.507812ie=UTF8ll=52.362773,4.883487spn=0.004684,0.009828t=hz=17om=1 Hier is de OSM link: http://www.openstreetmap.org/index.html?mlat=52.3624157525781mlon=4.882094314004176zoom=15 Alvast bedankt! Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Roulette op de Fiets
On Friday 28 December 2007 19:30:55 Lambert Carsten wrote: Dag Gerco Kees, Jij hebt een stukje fietspad gemaakt die dwars door het gebouw (oa. Casino) gaat aan de Max Euweplein. Omdat het een onderdeel van een route is kan ik dat stukje niet zomaar verwijderen. Ik heb mij nog niet verdiept in route tagging. Ik neem aan dat die route over de Max Euweplein loopt. Een deel van wat jij getekend heb is wel een voetgangers doorgang, maar zeker geen fietspad. Ook is er niet een tweede brug die daar over de Singelgracht gaat. Zou je dat even willen corrigeren, ik heb geen tijd om mij in dat route tagging te verdiepen? :) Voor een overzicht van de situatie hier een link naar google: http://maps.google.com/maps?f=qhl=engeocode=time=date=ttype=sll=37.06 25,-95.677068sspn=49.357162,80.507812ie=UTF8ll=52.362773,4.883487spn=0.0 04684,0.009828t=hz=17om=1 Hier is de OSM link: http://www.openstreetmap.org/index.html?mlat=52.3624157525781mlon=4.882094 314004176zoom=15 Alvast bedankt! Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl Laat maar! Ik heb het opgelost, ook al begrijp ik er niks van. Die route loopt nu over de Max Euweplein en de 'Fiets Rouletteweg' is weg (zoals er meer weg kan raken met roulette!). Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
[OSM-talk-nl] subway
In Amsterdam heeft een stuk van de Weesperstraat een tag railway=subway gekregen. Dit is volgens mij niet juist: -De metro kan onmogelijk nodes delen met de weg. -De layer van de metro is duidelijk lager dan die van de weg, maar een way kan niet tegelijkertijd in verschillende layers zitten logischerwijze. -Waar komt de data vandaan? GPS werkt niet onder de grond, op sateliet foto's is de metro niet te zien, of is dit laatste echt gezeur? :-) . Kan ik die tags gewoon verwijderen? Lambert Carsten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
