Re: [OSM-talk] Postmortem analysys
Nathan Edgars II wrote: But why write routers for the one case thats theoretically possible, instead of the millions that are not only possible, but already in existance? I don't care how the routers are written. I care about people wrecking the data by merging dupes. And assuming that no nodes at different elevations but the same coordinates are allowed is just crass. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Tom Hughes wrote: On 09/01/11 10:34, Lester Caine wrote: Nathan Edgars II wrote: But why write routers for the one case thats theoretically possible, instead of the millions that are not only possible, but already in existance? I don't care how the routers are written. I care about people wrecking the data by merging dupes. And assuming that no nodes at different elevations but the same coordinates are allowed is just crass. Look people, this really is very simple and I have no idea why this thread has managed to go on so long... OpenStreetMap has, and always has had, a topological model. If two physical things are connected in real life then they should be connected in OSM by making them share a node. If they don't then that is a bug in the data that should be fixed. If two things which are not physically connected in the real world are sharing a node in the database then that is a bug in the data which should be fixed. Routing programs should rely on the topological data that we provide and not guess that things which are close are connected. People merging duplicate nodes should not do so blindly and should check what they are doing - in many cases that may mean having to do a physical survey or examine aerial imagery to verify the situation on the ground. Unfortunately the duplicate nodes map seems to encourage people to go round blindly merging which is why I don't particularly like it. It was noticeable that when I was using it and deliberately leaving some near me alone because I didn't know the real situation that other people would just come round and merge them anyway. Exactly ... Personally I will STILL use a new node if I need to even if there is an existing one with the same XY coordinates UNTIL I can establish if the elevation data needs to be different. Many of the comments as to why there is no need for the conflict since they can give examples of why the nodes on different ways do not need to overlap seem to miss the fact that splitting a way by another way such as an admin boundary needs to create a node which may well be defined on the admin boundary already, and the new node needs to be an a layer below or above that already defined. The original decision that there should be no duplicate nodes simply ignored many of the arguments that there are very good reasons for needing them, then tools like the duplicate nodes map ASSUME that the decision takes priority rather than allowing 'duplicates' which are distinguished due to their elevation? I'll be honest ... it's been a while since I had to worry, but I can remember having to edit things with the new node moved away from it's real location, and then move it back to where it should be. Deleting the other node at those bridges would have been equally wrong. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Matt Amos wrote: On Sun, Jan 9, 2011 at 12:09 PM, Lester Caineles...@lsces.co.uk wrote: The original decision that there should be no duplicate nodes simply ignored many of the arguments that there are very good reasons for needing them, then tools like the duplicate nodes map ASSUME that the decision takes priority rather than allowing 'duplicates' which are distinguished due to their elevation? the duplicate nodes map doesn't assume that all duplicates are errors (http://matt.dev.openstreetmap.org/dupe_nodes/about.html#errors). it's simply a tool for finding them - because most of them are errors, - and it's nice to have tools which help in fixing them. as Tom points out, it seems that some are simply a little too zealous in fixing them, maybe relying too heavily on the auto-fix feature in JOSM's validator, and should be looking at the data more thoroughly. Sorry was not 'blaming' duplicate nodes map directly. Unless that is it DOES highlight nodes which are at different elevations? In which case it should simply not be highlighting them in the first place? Then people would not be 'trying to correct them' ... If nodes have a different elevation then they perhaps should be identified differently if they need to be highlighted? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] ORS discussions
Where is the best place to ask openrouteservice questions? The particular question I'm trying to get an answer to is ... Anybody know if there is an option to select mile display in an openrouteservice.org url. I've got everything else working nicely, but now I need to get it displaying the distance in miles to corespond to the milometer on the vehicle ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] It's fun while it lasts
pec...@gmail.com wrote: I think we can call it a day. I really doubt Microsoft will be that interested in OSM anymore when they got Nokia on their hook. I think it's probably another example of M$ trying to stifle the THIRD horse while they come in at number 4. I don't want FG windows on my Nokia phone. Now that I have found a phone that works - with LINUX on it - I was at least happy. WHO is going to be supplying LINUX (meego). And do say 'Use Android' THAT is not linux and just as crap as iphone when it comes to using EXISTING applications. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tools for a better tomorrow
Serge Wroclawski wrote: Idea 4: Better comparison tools. A common concern by those wanting to do imports is we lack good comparison tools. While the problem is several orders of magnitude greater, the facilities provided by VCS systems would seem to be an obvious base to work from. I look at the methods I am using to manage my various code bases in a cooperative manor with other OS contributors and can accept or roll back parts of changes other people contribute. Taking this a step further, with the current vogue for DVCS, there seems to be an ideal solution to a number of problems. Distributed version control systems provide a local copy of the data and the change information, and allow local information to be added and maintained in parallel with other copies of the same data. Personally I am finding that the tools provided with the newer DVCS systems are not as flexible as the older CVS and SVN approaches. These provide me with a 'diff' of all of the information that has changed between my current view and the current 'master', while the DVCS systems still need work to get to that level. However the basic principles should still be able to be applied to OSM! The 'tool' that I think would be useful is a means of 'checking out' an area ultimately the whole world, but more practically one's local area, or perhaps as big as your country. Probably 'sliced' in line with a particular level of zoom tile? One should then be able to render that section locally, and ones own local 'overlays' of information, and finally 'commit' changes to the base master. 'Pulling' newer changes from the master should be able to display them in a 'diff' window, so that individual change sets can be accepted complete, or broken down so that changes can be 'cherry picked' and obvious errors stripped from more complex useful edits. Ultimately we should be able to provide many distributed copies of the master database spreading the load and permitting local specialist information to be managed in parallel ... using the same tools? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cost of tolls
Elizabeth Dodd wrote: and a date for the costings because they always are going up then which electronic tags can be used instead (for example E-tag) This information is not best stored in the OSM database. A link to the current information or not at all. cost:see(link) ? UK charges tend to be fairly well defined to use cost:vehicle-xxx and I have to remember to have my 5p ready when I go over the bridge near Oxford, but here they only collect for part of the day and I have yet to work out when I can get through free ;) Flagging ON OSM that there is a charge is at least a start, even if you need a ten page document then to work out how much ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap License Change Phase 3 Pre-Announcement
John Smith wrote: On 16 April 2011 17:37, Elizabeth Dodded...@billiau.net wrote: OpenOffice.org has had a major fork just recently. The LibreOffice fork has chosen different licensing arrangements, including the contributors retaining their own copyright. http://www.libreoffice.org/get-involved/developers/ and interestingly this assessment of how LibreOffice is going http://webmink.com/2011/02/11/is-libreoffice-open-by-rule/ We can also note how the new fork is handling their compound licensing issue. What's more interesting is Oracle's move to wash their hands of direct control over OpenOffice... http://go.theregister.com/feed/www.theregister.co.uk/2011/04/15/oracle_letting_openoffice_go/ Probably pertinent how current this move is ... I think that the fact that the main development team simply moved over to LibreOffice was something Oracle had not anticipated, but is exactly what open source is about? Unlike OO, OSM has a number of 'competitors' providing the same data, so a split is less likely to happen, but I do wonder if it isn't about time to readdress the area of merging data from different sources? Rather than throwing everything in the one pot and mangling it, creating a more open data interface so that third parties can supply feeds in much the same way as we use a range of background tiles at the moment. I am thinking directly here about paralleling the current OS data with OSM data. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap License Change Phase 3 Pre-Announcement
John Smith wrote: On 16 April 2011 17:53, Lester Caineles...@lsces.co.uk wrote: The whole database should be public domain, and any third party pushing 'commercial' data into that should understand that. Even the UK government have now accepted that we should have free access to this sort of data, so my own 'need' for OSM has been somewhat diluted since I have an open alternative. I was looking at mirroring my own copy of OSM, but the OS data gives me the facilities I need with less hassle. Doesn't OS require attribution if you use their data? Same as adding a link to OSM where that is the source ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap License Change Phase 3 Pre-Announcement
John Smith wrote: On 16 April 2011 19:04, Lester Caineles...@lsces.co.uk wrote: John Smith wrote: On 16 April 2011 17:53, Lester Caineles...@lsces.co.uk wrote: The whole database should be public domain, and any third party pushing 'commercial' data into that should understand that. Even the UK government have now accepted that we should have free access to this sort of data, so my own 'need' for OSM has been somewhat diluted since I have an open alternative. I was looking at mirroring my own copy of OSM, but the OS data gives me the facilities I need with less hassle. Doesn't OS require attribution if you use their data? Same as adding a link to OSM where that is the source ... So your original suggestion that the OS recognises your suggestion about things should be public domain is patently false. No I said 'free access to this sort of data'. But I don't see that having the courtesy to recognise where data can from should be any sort of a problem. 'Requiring it' just acknowledges that some people do not extend that common courtesy. I find no restrictions on what I need to do with the data. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New Logo in the Wiki
SteveC wrote: Instead of taking 8 weeks to have a process, let's treat it as 8 weeks where anyone can help fix these theoretical and technical logo issues. It's right there, anyone can help. So who's going to do it? Steve So what is being done for those of us who invested in high visibility vests which are now obsolete? And those who have paid for printing which now needs to be redone. A LITTLE notification of such a major change would have been nice. I wonder how many local groups have only just committed to expenditure that is now out of date even before they receive the product? I do not even recall any discussion that that a change was being planned? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New Logo in the Wiki
Frederik Ramm wrote: Calm down. Our merchanidse is not out of date just because the logo has been touched up. So http://wiki.openstreetmap.org/wiki/File:OSM_Hi_Vis_Back.jpg is not going to be changed? At least it does say who we are working for, while the new logo is just a fussy picture which says nothing ... Also how much stock of the current logo version is left on the shelves of those supplying it? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New Logo in the Wiki
Frederik Ramm wrote: Also how much stock of the current logo version is left on the shelves of those supplying it? I have no idea but if it were my stock, I'd probably re-print the old logo without a second thought. And just take the hit on the wasted costs out of their own pocket? The point I am trying to make is did anybody changing the logo even consider the other areas that money would have been spent? I see pictures of large banners in addition to the vests which no longer match the current style of the website! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New Logo in the Wiki
Andreas Perstinger wrote: Is the current logo change a major decision for you? See also Robert's comparison: http://wiki.openstreetmap.org/wiki/File:Oldtonew_logo.gif). Actually it just highlights all of the problems nicely. Having been required to comply with the needs of the visually impaired on a number of projects, the importance of contrast at a lower resolution IS quite critical! AT LEAST change the icon views back to the old style if it does not matter that we can all use the older style anyway. But personally I find the current image simply a damp squib in the corner ... perhaps because I HAVE to focus on it better to see any detail at all ... even with my glasses on. A logo should be 'crisp' and scale nicely from Icon through to larger image, and the loss of the distinctive outline IS the major problem. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Airspace Co.
Tom Hughes wrote: But before I do all that, I would like to hear from the community at large - you - whether you share my view. Do you agree that airspace should be elsewhere but not in OSM? +100 Perfect example of something that should be possible to implement as a completely separate database, but which can overlay any other OSM data? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] What is an ID?
Rather than comment on the id stability thread, I though it better to turn the question around ... In my own data trail, an ID *IS* unique, and is directly linked to the piece of data it relates to. If I change the data then the version number goes up. If I delete the data, then the ID number remains since it identifies the HISTORY relating to that item. The idea that someone is going to 'reuse' id's because they are no being used raises alarm bells. I thought we had history relating to every element nowadays, so how do you know what the history relates to if you reuse the ID? Also the idea of 'renumbering' everything is equally alarming, given that every old changeset would have to be updated? If we are running out of ID's, then a switch to 64 bit is an urgent requirement simply to prevent the existing data and history trail from being corrupted. Now having said all that ... USING the internal ID for external purposes, while potentially practical, is not the most sensible way forward as has been highlighted in several ways. I'm probably in agreement on a 'link server' approach, but I think that there are a number of areas where additional 'ID's need to be stored in the database and managed in parallel. Postcodes, bus/tramstop id's, Airport codes, telephone area codes, and so on. We had a little discussion on parallel databases, and that slots in with the 'link server', but I think that in order to make ANY parallel database system work, then the core ID's have to be stable and consistent, even if they do return 'deleted' ... at which point on needs to be able to ask 'why' and possibly roll back a change that should not have happened? If a item has history then it's ID can't be reused. http://www.openstreetmap.org/browse/node/xxx/history simply has to be consistent? Then what may be missing IS a tag for 'split_from' or 'merged_with' but the linked ID's must also be consistent? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is an ID?
Richard Mann wrote: I think he was joking about reusing ids (he was illustrating the point with the sort of daft temporary fix that someone might do ... if they were daft) Well someone has set up the system to reuse them http://www.openstreetmap.org/browse/node/1/history THAT is a joke :( PLEASE can someone disable that corruption before it goes too far? On Tue, Aug 2, 2011 at 5:35 PM, Lester Caineles...@lsces.co.uk wrote: Rather than comment on the id stability thread, I though it better to turn the question around ... In my own data trail, an ID *IS* unique, and is directly linked to the piece of data it relates to. If I change the data then the version number goes up. If I delete the data, then the ID number remains since it identifies the HISTORY relating to that item. The idea that someone is going to 'reuse' id's because they are no being used raises alarm bells. I thought we had history relating to every element nowadays, so how do you know what the history relates to if you reuse the ID? Also the idea of 'renumbering' everything is equally alarming, given that every old changeset would have to be updated? If we are running out of ID's, then a switch to 64 bit is an urgent requirement simply to prevent the existing data and history trail from being corrupted. Now having said all that ... USING the internal ID for external purposes, while potentially practical, is not the most sensible way forward as has been highlighted in several ways. I'm probably in agreement on a 'link server' approach, but I think that there are a number of areas where additional 'ID's need to be stored in the database and managed in parallel. Postcodes, bus/tramstop id's, Airport codes, telephone area codes, and so on. We had a little discussion on parallel databases, and that slots in with the 'link server', but I think that in order to make ANY parallel database system work, then the core ID's have to be stable and consistent, even if they do return 'deleted' ... at which point on needs to be able to ask 'why' and possibly roll back a change that should not have happened? If a item has history then it's ID can't be reused. http://www.openstreetmap.org/browse/node/xxx/history simply has to be consistent? Then what may be missing IS a tag for 'split_from' or 'merged_with' but the linked ID's must also be consistent? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is an ID?
Tom Hughes wrote: On 02/08/11 18:43, Lester Caine wrote: Richard Mann wrote: I think he was joking about reusing ids (he was illustrating the point with the sort of daft temporary fix that someone might do ... if they were daft) Well someone has set up the system to reuse them http://www.openstreetmap.org/browse/node/1/history THAT is a joke :( PLEASE can someone disable that corruption before it goes too far? Nobody has setup a system to reuse anything. All you are seeing there is the result of badly written programs and the like doing perfectly normal REST writes to node 1. When such mistakes are made people revert them. Shit happens, and we deal with it. How exactly do you suggest that we disable that corruption? I just started at '1' to see how good things were, and a few of the nodes I then worked through showed questionable changes ... Actually it's interesting looking at some of the raw history. There are a block below 1400, many of which are original nodes, but some seem to have these strange edits, then there is a jump to 77858, which I presume was a hick-up somewhere along the line very early on, except that the 1300 series nodes post date 77858, so something is/was going wrong somewhere? Some of these early node numbers have been edited earlier this year ... Shit happens, and we deal with it. still has the problem of identifying where the shit has happened and working out how to deal with it. Increasingly looking at the history I've been spotting places where useful tags have been removed when later edits were added but there is no mechanism to flag what is being deleted? I've not noted down the node numbers, but a series of edits relating to wheelchair access seem to have removed the name or other tags rather than maintaining them ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal superseded_by tag for ID stabilisation
Steve Bennett wrote: In general I think there's some value in what you're describing here, not just for id stability, but in better understanding the history and provenance of objects, which helps with attributing authorship. Some sort of more generic meta-tagging scheme might be good (superseded_by could easily be interpreted as referring to the actual physical objects, not the OSM objects), so maybe something like osm:new_id=xxx, osm:merge_into=xxx etc. new_id=xxx is an interesting thought especially if it can be used to manage the back linking of history when a split is instigated. So that an older id may well have several new_id tags as splits of the element happen? superseded_by only sounds appropriate where the original id does become historic redundant data? I think people have lost sight of the start_date and end_date though? I think that still provides an important element if people ARE will to accept that there is historic data now being accumulated? Deleting a building as demolished has a date, and creating a new building on the site has a date. While they are physically located at a similar point, they are not the same object, but it is necessary to maintain the history of that change, and similar things such as change of use ... I still live in the hope of being able to draw a map of an area with a particular date to go with my genealogical work ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Where Did You Edit
Stephan Knauss wrote: What would be the coolest way to zoom? While 'zoom' would be a nice to have, for many like myself, simply drawing the map with a boundary a little larger than the extents would be a useful next step, and a little easier to manage in the first instance? Then being able to zoom in further is probably secondary to many people at the moment? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Where Did You Edit
Stephan Knauss wrote: And I have the data in a quite high resolution available because I'm planning a zoom functionality. So an initially scaling based on the data extents could be a useful next step? If you already have a higher resolution base. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik rendering labels for unrecognised tags
Anthony wrote: Sounds good. I don't think storing these in OSM, with the non-overlapping tags, is harmful. While I'd love to see them in a separate database or at least a separate layer, the fact of the matter is that separate database and/or separate layer hasn't yet really been implemented. This is the real problem! With more and more historic mapping material coming on line, and what seems like little support for the start_date/end_date tagging of physical objects that we have fairly accurate data on when they did make an appearance or when they were redeveloped, linking to other data sources where this information can be stored would at least allow it's integration? And the creation of 'temporary' layers where material is being worked on but has not yet been fully integrated would also seem to be a way forward even for general mapping? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Roundabouts and routing
Jonathan Waller wrote: With regards to solution 1) I have never noticed a sliproad onto a roundabout tagged as junction=roundabout (UK East Midlands). Where is this common practice? If this is not too widely used then it might be worth retagging, but I don't know how easy it would be to automatically detect these. Certainly the roundabouts near here all have islands in the middle of the approach, so these need to be mapped, if only for the pedestrian route around them. They are all tagged as part of the approach road, but obviously have the correct direction arrows ... which they need! I think the main problem here is not so much anything to do with OSM, but how the portable devices work. TomTom has this very annoying habit of announcing some silly side road or even layby as a junction then totally ignoring the merges with a motorway a mile or so later. It is the interpretation of the data that is the problem, not the data itself, and if anything that needs to be handled in the conversion process to the device not on the raw map? Bodging the data so that the device does what you want ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The thread Roundabouts and routing
Anthony wrote: On Fri, Sep 9, 2011 at 7:59 AM, Robert Scottli...@humanleg.org.uk wrote: On Friday 09 September 2011, Anthony wrote: Is it just me Yes. or does the thread Roundabouts and routing (http://lists.openstreetmap.org/pipermail/talk/2011-September/060082.html) reflect a dysfunctional community? No. Does this thread reflect one? More than the original discussion :) At the end of the day we are now down to a level where the fine detail is more important than simply getting all the roads plotted. I see nothing wrong with the original post ... I recognise the scenario from tomtom as well not even using OSM data! The only thing that I think is wrong with the post is that 'Don't tag sliproads onto roundabouts as junction=roundabout' is probably not the cause of the error in garmin, but rather simply the split of the main way. It is that area that needs to be investigated a little further since 'junction=roundabout' just seems wrong anyway. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'wget'ing largish portion of planetOSM
Frederik Ramm wrote: I've downloaded all of UK from nick.dev.openstreetmap.org and extracted the bit I want, its a bit old (28 Oct 2009) but mayhap I can update it without massive downloads. I've got most of the area current to last week. It's your decision entirely of course but I utterly fail to understand why you use 2-year-old data and batter all available APIs with tons of requests when you can easily get CURRENT data for ALL OF THE UK from downloads.cloudmade.com or download.geofabrik.de, both linked from the planet page that has been pointed out to you. I think the problem here is that nick is listed as 'UK' area on the extract list, and people don't think to look at other options :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'wget'ing largish portion of planetOSM
Mick wrote: I hadn't thought of UK as being Northern Europe, I looked in Western Europe. That's where they hid it ;) I'd found the Isle of Man ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
John Firebaugh wrote: You can also set a personal default on your user settings page, so that clicking Edit will always launch your preferred editor, regardless of the outcome of this discussion. I would say that I don't remember seeing that option before ;) All right I probably need to re-read all the help files again, but a lot has changed since I first registered back in 2005, and while it may be obvious for the people creating these changes and people registering nowadays, my little rant was more a comment on the fact that there is not a clean notification on some of these changes and how they affect 'old timers'. One gets used to a way of working and when something changes. On other projects we do at least get a crib sheet on how do do things 'the new way' and -that- needs to be addressed before changing the default. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Martin Koppenhoefer wrote: As has been discussed before, we are not planning to add intrusive Are you sure? warnings to iD. Such second-guessing disrupts legitimate workflows and turns away new users, who typically already feel anxiety about doing something wrong. with that approach (letting the users incidentally damage turn restrictions or other relations without warning by deleting members or combining them in a harmful way ) new users will get even more anxious as they will get mailed by others afterwards. Relations are fragile and if they are almost hidden for the mapper a warning should be the minimal precaution (or alternatively don't let iD users do these kind of edits where relations are involved and would be damaged). I used to get irritated by what seemed to be unnecessary warnings, but now I'd prefer to see even more of them. I could make a case for an 'expert' switch to disable them selectively, but that would be something I'd probably leave off. Often the warning is a prompt to cross check what one is doing. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Kai Krueger wrote: Toby Murray-2 wrote We aren't trying to make The Perfect Editor here. We are trying to replace an aging editor with something more current. Let us not make perfection the enemy of progress. Although a perfect editor would of course be nice, it isn't really achievable so yes, we don't want to let the perfect be enemy of progress. But we do want to make sure it actually is progress. I think the fundamental problem is 'aging' ... people seem to think that all these nice new wizbangs are progress such as that informationless curved pallet. Now if there were some nice COLOURED icons on it to remind me what each button as then I'd not have to hover over every one. My main problem however is the map display itself! I currently have Id up on one screen and P2 on the other showing the same area of map with openstreetview as a background, and to be honest, the P2 display may seem 'dated' but at least it's crisp and readable. The horizontal hashing and other 'eyecandy' on the Id display make it very difficult to see the details that I could now be tracing. Move to satellite and the 'effect' on my monitor is even more pronounced. I need to switch off the hashing as optically it's distorting the view of the field boundaries below. Click on an area that you want to realign, and that pigging pallet overlays the very lines you want to SEE to move. And I'm with others here, having the 'delete' as the first 'hidden button' is not the safest of places to have it! At the very least a 'do you want to' is essential. But I WILL add here I have the SAME complaint with P2 anyway! There should be a 'do you want to' but with P2 at least it is a positive action to go down to the corner, something right under your mouse is all to easy to hit. How do I drop a simple POI in on Id? The menu on P2 may take up a large area, but simply dragging something suitable onto the map works well for me and is normally the sort of fast update I'm trying to achieve. I've not worked out how to do that yet on Id? It keeps highlighting the landuse area I'm dropping into rather than giving me a new node? OK not sure what was going on then, but now I've found it, but the list of options for nodes is going to be a lot slower to navigate ... pigging monochorme icons again ... and half of the ones I use don't even have their icon (gate for instance). NO ... I'm not finding this an improvement ... P2 has it's faults, but at least it IS usable for the quick editing. Id needs you to know a lot more already to be able to add the sort of simple stuff a novice user will be looking at first :( Add the P2 menus in place of the limited list and that would be an improvement ... with the nice coloured icons ... it makes picking up a group of similar node flags a lot easier! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Lester Caine wrote: NO ... I'm not finding this an improvement ... P2 has it's faults, but at least it IS usable for the quick editing. Id needs you to know a lot more already to be able to add the sort of simple stuff a novice user will be looking at first :( Add the P2 menus in place of the limited list and that would be an improvement ... with the nice coloured icons ... it makes picking up a group of similar node flags a lot easier! Just to expand on that ... I've added a few boundaries and buildings using both editors. On P2 I can draw a line around an area then add lines to create the building detail. In Id I can't get it to recognise the new closed line as an area? And I can't see how to make the building a house or a garage ... so I dropped back to P2 to complete that detail! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Lester Caine wrote: people seem to think that all these nice new wizbangs are progress such as that informationless curved pallet Me again ... *NOW* I'm getting icons on the curved pallet! That was blank while I was playing earlier ... did I just happen to hit something to enable them? Only having the delete button showing for nodes is even more accident prone? ... but while that pallet does get out of the way at times, both it and the other pop-up helps always seem to be just where you want to be moving to and their flashing on and off is more irritating then helpful once you have seen them a couple of times :( And I do need to work out how to get Id to properly handle areas built up by adding detail to existing areas and lines. Taking an existing block and sub dividing into separate buildings is the usual detail I'm adding and while P2 is not ideal, Id does not seem to understand a closed loop at all unless it created it as an area? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Pieren wrote: In regards to mistakes: I think it clear that iD makes delete more prominent and easy to hit than P2, and misses opportunities to have better delete workflows. I don't see this as a problem. Deleting is equally important as inserting or moving objects in any editor. When you edit a page in wikipedia, nobody complains that deleting words is so easy, even for a first contribution. What I deeply regret is that OSM website still does not offer to everyone, including newcomers, a fast and easy way to revert an edit once it is saved. Reverting is done in two clicks on wikipedia. This is something important for newcomers. They are less worry to participate if they know that they (or someone else) can revert at any time their mistakes, even after clicking the 'save' button. I'd second that. Although I think the comparison with wikipedia is perhaps not so straight forward. We can easily grab a page of text and edit it locally for our own use. In the past people have tried to do the same thing with the map not understanding perhaps the implications. A better handling of the SAVE cycle might suffice in a lot of cases, rather than a pop-up for each delete? So many nodes will be deleted from the live map ... did you really mean to do that? Then from the other end, a means of editing and printing an area of map 'off-line' so people can do their own quick customise? I have personnally more problems when I see that moving a node is simpler than moving a way, but that's a detail. I'm interested in that comment. I've had a few occasions I think on P2 but it may have been JOSM, when I've gone to realign a node ready to bring some additional way in contact, but the whole target way has moved. Undo fixes the problem, but I could not see why you would want to move the whole way especially when you can't see the ends? To me the default should just be moving the node? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Ben Abelshausen wrote: Sometimes it almost looks like some people here are afraid of new users. I still think that the general process for new users is not the easiest ... I think it is correct to assume that they will make mistakes in the beginning but also that they join the project to add new data. If they grow to be seasoned mappers the benefits of having new users will outweigh the inconvenience of occasionally having to correct some mistakes. If iD can help with this then I say: let's make it easier for new people to join and edit the map instead of being afraid they will mess up some data. Some of my own comments have been directed to all of the editors and while I can see that Id is trying to address some of them, it's also bringing along unnecessary changes. I've given it another try, but the style sheet is definitely not to my liking when working on data around here. I prefer the cleaner style of P2. Fix processes that are broken, but for the operations I'm carrying out, Id is actually getting in the way and making life more difficult. So I'd question the statement that Id is better ... it has different ways of doing things, but also has assumptions that don't seem to work for me. I've used JOSM as well, but P2 provides me with a good workflow and has more information on the screen such as the grid of possible POI's. I find the limited listing on Id something difficult, and I already know what information I can add ... it may improve as it seems to learn what I am doing, but when I switch tack then I have to find everything again where P2 it's just there. Flash may be a problem going forward, but it's the whole process that seems wrong on Id. A better way of preventing mistakes is to prevent first edits being a lonely experience and to increase interaction with local communities instead of making editors more complicated. Comes back to point one and something which I've said in the past ... the front page for new editors needs to direct them to an appropriate local 'venue' for working in their own language on their own area of the world. An alternative to Facebook might be nice, but we probably have to live with the forums that work in other areas of the world. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Lester Caine wrote: I've given it another try, but the style sheet is definitely not to my liking when working on data around here. I prefer the cleaner style of P2. http://lsces.co.uk/fisheye/view.php?gallery_id=78 to try and explain what I'm talking about ... This was the best contrast I could get on the imagery for id, openstreetview is OK, but the horizontal hatching at the top detracts from viewing the background imagery on both. Hovering over an object it displays clearly in P2, but it's difficult to see the change in highlight on iD until you actually click on a target, and even then the highlighted object is not as crisp as appears in P2. I actually cleaned my glasses to see if it helped! Contrast is important for some users, so grey on grey does not work. I had problems with 'Point' originally because the cross is virtually invisible against the imagery. I did not even realise it was there at first, but personally I'd prefer the blank area to the right displaying the P2 POI menu than having random item details appearing as you hover around. Having to search for something you do not even know about is not helpful? If you can see a set of details to select from it makes life easy - even for experienced mappers. I don't want to have to type in and try and find the right icon. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Editor problems ...
Yesterday I was using P2 happily, and my personal 'default' is set to that, today when I click on edit I'm getting id, and when selecting P2 manually I'm getting a blank page. What has changed over night? I know it's not the browser as I'm waiting for an update on that so it's not changed. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Florian Lohoff wrote: On Fri, Aug 23, 2013 at 03:40:33PM +0200, Maarten Deen wrote: I think the general idea is that track is a dirt roads fit for two-tracked vehicles (cars, agricultural) and path is a dirt road fit for one-tracked vehicles (because too narrow for two-tracked). A track is for aggricultural purposes - As soon there is the school bus or waste collection trucks passing it CANT be a track. Its either highway=service/service=driveway or an unclassified - it might have a surface=dirt/grass whatever. Sorry, but this is the whole problem with the way things had been reorganised. 'Dirt' trackways need to be rendered in a different way to highway=service, and from a rendering point of view having to search other tags to modify the base rendering, and also routing, is just wrong. So I will not use highway=service for trackways around here that are still used by school buses, refuse trucks and delivery lorries. As a result tracks that are only suitable for agricultural access get tagged as paths to distinguish them from the ones that are used more publically, but are not 'highways'. Sat Nav routing is giving some strange results and long detours avoiding some of these public trackways so sorting this out is important. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Editor problems ...
Alex Barth wrote: Works for me. Rebooted machine and we are working again ... 1. Go to account settings set Potlatch 2 as default, like so: http://cl.ly/image/0u2j0E1W3g2F 2. Save 3. Click edit - Potlatch 2 opens as expected. Potlatch 2 WAS selected as the personal default yesterday as opposed to the the 'default P2' which has now changed to 'default id' and to which my account had been switched today! Our personal choices should not have been changed when the 'default' was changed? My last change set http://www.openstreetmap.org/browse/changeset/17471395 has messed up http://www.openstreetmap.org/browse/way/83270098 ! The only change I made to the site outline was to tidy the right hand diagonal boundary against the new imagery where two new buildings are now visible, and the boundary needed a little shuffle over, but what id has saved has completely changed the area. My copy of JOSM is not loading at the moment, can someone please simply revert http://www.openstreetmap.org/browse/changeset/17471395 or me and I'll put the other fixes back in again. An explination on what has gone on would also help? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Editor problems ...
Tom Hughes wrote: On 23/08/13 20:57, Lester Caine wrote: Potlatch 2 WAS selected as the personal default yesterday as opposed to the the 'default P2' which has now changed to 'default id' and to which my account had been switched today! Our personal choices should not have been changed when the 'default' was changed? Unless you have changed it your personal default, like everybody's personal default, was set to default which means whatever is the global default. A personal default can either be a specific editor, or it can be use whatever is the global default and the last is what new users are set to. I specifically changed it to the correct setting yesterday away from 'default', noting that 'default' was still P2 ... Obviously edit went to P2 anyway, but I am happy that I had changed and save the change. The fact that the default has now changed has not been publicly announced yet! And I would like an explanation as to the corrupted data id has stored today! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Editor problems ...
Lester Caine wrote: My last change set http://www.openstreetmap.org/browse/changeset/17471395 has messed up http://www.openstreetmap.org/browse/way/83270098 ! The only change I made to the site outline was to tidy the right hand diagonal boundary against the new imagery where two new buildings are now visible, and the boundary needed a little shuffle over, but what id has saved has completely changed the area. My copy of JOSM is not loading at the moment, can someone please simply revert http://www.openstreetmap.org/browse/changeset/17471395 or me and I'll put the other fixes back in again. An explanation on what has gone on would also help? One to add to the 'beginners error' list https://github.com/systemed/iD/issues/1731 And I'm not a beginner ! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Martin Koppenhoefer wrote: So I will not use highway=service for trackways around here that are still used by school buses, refuse trucks and delivery lorries. what makes you believe it's a track and not an unpaved road if even the school bus takes that road? No footpaths, lights, tarmac or road markings but freely available to drive along. It's a track ... but the current definition prevents it's use. Adding other tags to 'service' is wrong as well as its servicing anywhere, and unclassified has a similar incongruity. Many of them have been at least hardcored, but even then 'road' just seems too grand a title for a track. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Ross Scanlon wrote: informationfreeway.org/?lat=-20.374lon=148.633zoom=15layers=00F000B0 You'll have to copy and paste the link. Actually you will have to do more than that. the domain is incorrectly set up, so only http://www.informationfreeway.org/?lat=-20.374lon=148.633zoom=15layers=00F000B0 will actually work - you need the www. Notice the broken casing on the sides of some of the roads. If what you are talking about is the change in style on the roads to the right, then how were they generated as they do not appear on the main database? It's nice to see I can just cut and paste the old style location urls and they will be recognised - hopefully no-one will remove that as redundant ;) I have an interest in this for showing what is to the side of roads. While on one hand macro mapping says add tags to a road to show things like footpaths and cycleways, micro mapping would show the all of the infrastructure actually as areas, but at least as separate identifiable ways which can be selected in preference to the road for planning waking and cycling activity. If the 'road' with no 'side furniture' is rendered with broken sides like this it makes sense. Africa has considerably more of the 'tracks' that I am talking about and there it is even more important to identify ones where the two ruts making up the track would make it dangerous for following on foot? While many parts of the world have different requirements, generally the same rules apply worldwide? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Bryce Nesbitt wrote: Sometimes it almost looks like some people here are afraid of new users. +1 We also have to see deletions as positive contributions a priori when it is really fixing something (e.g. removing an obsolete POI). Only intentional deletions are positive contributions. There are mouse mistake deletions. And haste deletions. All I ask is that before deleting a POI, that you (beginner, intermediate or guru) examine it. Can it be fixed? Should it be disused: instead? There are few POIs that can be reasonably deleted from the geometry alone... which is why I feel putting the trash can in the editing area is poor workflow. Instead set the UI up to encourage good workflow: see a POI that might be bad, examine it's current content and/or history, apply local knowledge and/or research, and then execute a course of action. Respect the prior mapper's work by actually looking at it, prior to deleting it. Until such time as we have a properly documented workflow which archives 'obsolete POI' to an historic map database, they should remain on the map, with an end date. OK the history retains when an action as taken, but the important missing information here is 'closed down xxx' otherwise one does not know if an item was removed because it was wrong or for some legitimate reason. So to my mind there should NEVER be a trash can - 'archive' with properly added tags is the only correct work flow! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Colin Smale wrote: What about when an object (perhaps a road or a boundary) is replaced by a better approximation? The history of the database objects is already dealt with (you can access old versions and see when it was deleted). Typically in these cases the new version gets drawn/uploaded, the tags are copied over and the old version is deleted. So there will be an ongoing need for a delete button. Maybe your suggestion would be well supported by a clone POI operation, which creates a duplicate of the selected POI and deletes the old version with one click of the mouse? And in this case a substantial amount of history gets lost! Case 1 ... better imagery shows that the location of a way is wrong ... so move the way to the new location! Do not delete the way and and start again from scratch. This is were 'imports' are very badly broken, and when a new import is applied it should update the one it replaces especially when other material may well now be using the original nodes? We have many years of 'history' building up, but if that is wiped every time some new raw data is loaded information is lost. Case 2 ... an area is redeveloped and the road structure and buildings replaced with a new layout. In this case the old layout very much needs retaining and is exactly the sort of thing that needs to be transferred to an historic map. Again - delete - is totally the wrong action! Case 3 ... vandalism creating havoc ... this can only be correctly handled by reverting the change set ... a delete button is not the right tool! Case 4 ... you add something wrong to the map while editing ... use undo! Bottom line - remove the delete button :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Ross Scanlon wrote: Notice the broken casing on the sides of some of the roads. If what you are talking about is the change in style on the roads to the right, then how were they generated as they do not appear on the main database? It's nice to see I can just cut and paste the old style location urls and they will be recognised - hopefully no-one will remove that as redundant ;) Have a look at what layer is selected. You see that it's not osm. Hence the question! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org - some numbers
SomeoneElse wrote: 1) A POI added without a main tag http://api06.dev.openstreetmap.org/browse/node/4295739963 I suspect that people are adding a point to a map (in this case for a shop), and are not seeing shop in the default list to the left or understanding that they can search. In my experience the search works really well, and once a point has been added by mistake the change feature tooltip is pretty obvious too - so I've no idea how to improve here! Potlatch2 works nicely by drag and drop a selected POI onto the map. It's grid does need a little updating, but on the whole is a better starting point. I will be making a case for including that into id ... the current 'blank page' when adding a point is not user friendly at all! It took me a while and a few moves to get a POI node created in id ... 3) Deletions http://api06.dev.openstreetmap.org/browse/changeset/30174 I've no idea whether things are being deleted by clicking on the rubbish bin icon or pressing the keyboard shortcut. According to comments on #osm-gb there have been a couple of attempts to find out what buttons people are clicking, but the answer is I didn't mean to do X - I've no idea how it happened. See other thread an why there should not be a delete button! I made the same case on potlatch in the past and now the reasons are even greater. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Ross Scanlon wrote: Notice the broken casing on the sides of some of the roads. If what you are talking about is the change in style on the roads to the right, then how were they generated as they do not appear on the main database? It's nice to see I can just cut and paste the old style location urls and they will be recognised - hopefully no-one will remove that as redundant ;) Have a look at what layer is selected. You see that it's not osm. Hence the question! Ok. The roads in question are not in osm, they were pre redaction, they are still in another database. The rendering based on that database is the layer shown. I had assumed that it was rendered from a database as stubs of the roads are still present, so it was not a simple graphical mashup. The main reason for the question was that the style looks nice and I would be interested in replicating it on my own tiles. Some of the historic styles are still a lot tidier than the current style sheets :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
Paul Norman wrote: Case 3 ... vandalism creating havoc ... this can only be correctly handled by reverting the change set ... a delete button is not the right tool! The revert tools just do a delete. I hope not! They roll back to the previous version of an object. I've just had to use that to fix a problem id created with a commit I had pushed. Revert rolled all the nodes back to their correct position. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org
(remember to check address!) Peter Wendorff wrote: If so, then sorry for that - but is there any documentation about it? The API description in the wiki does not mention anything like that, so IMHO it's missing there, isn't it? They upload a new version of the object with the appropriate properties. The more relevant call for uploading data is http://wiki.osm.org/wiki/API_v0.6#Diff_upload:_POST_.2Fapi.2F0.6.2Fchangeset .2F.23id.2Fupload. I don't see anything that needs adding to the documentation. Sounds inconsistent nevertheless: updating a single object using PUT /api/0.6/[node|way|relation]/#id is not possible when referring to a deleted object, but updating the same object using diff is. If nobody complains, I'll add a hint to the section referring to the diff upload section, and a hint that diff uploads may be used for real reverts, too. At the end of the day, nothing is ACTUALLY deleted. Currently a copy is retained in the changelog and that is simply used to 're-edit' changes so that as has been said a new version is created matching the last but one version. The API does not prevent using a 'deleted' node or way number so all of the change log history can be retained. But this is where maintaining historic records creates a problem. Only one copy of an object is maintained in the main live data, so accessing a previous 'view' say prior to a realignment of a road fails because it has the same way number. Using start and end dates to select a particular view is not supported ... This is where 'delete' is the wrong concept. Currently it just means it's made invisible and there is no reason it can't simply be restored. What should be happening is that there should be a mechanism to tag the reason for the 'change of state' and changes that are due to historic development need to be made available via a different route. Since the start and end date tags already exist, managing these properly is long overdue, but it's moving records that now have an end date to a view of the database where that information can be used that is currently missing? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Making iD the default editor on osm.org - some numbers
Fabian Schmidt wrote: See other thread an why there should not be a delete button! I made the same case on potlatch in the past and now the reasons are even greater. In your last 5 changesets you deleted 7 nodes. You improved the quality of the map by deleting (and adding) nodes. When you try a new editor or add a node by mistake, you might not want to save everything you added. So you need a way to delete them without throwing away all your changes. As none of the editors understand the concept of historic information, none of them do the job right. id certainly does NOT allow moving nodes as well as P2 does - although part of that is probably now learning yet another interface!!! Undo and redo are the correct way of handling things WITHIN a changeset, and yes delete is appropriate in the change set, but nodes that already exist IN the database need different handling. New mappers may not even appreciate that a node may be part of many other objects, and so while they are deleting it in the concept of what they are modifying, it may not be appropriate for the other ways using it! It irritates me that people merge ways because of a 'macro' view, but pulling them back apart to restore the the micro view is difficult with the current tools :( And has trouble with the reusing the changeset history. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Problems with new setup
OK I've raised an issue on id and it's been closed as invalid. Having now dug into the id code and got to the point where I am now playing with my own version of the style sheets and icons, I'm able to understand better why I'm HAVING problems. One of the major differences is the use of black as the background, rather than the lighter colour of P2 and the map itself. Selecting backgrounds such as Open Streetview leave much of the detail invisible as white against white, and while the use of the 50% setting allows the details to be seen, the background is then unusable. I had though this was due to the different way the background is 'dimmed' which is the approach used on P2, but it is more to do with inverting the default background and trying to use white for everything is not working. My original issue and the one raised is strange since id IS defaulting to a black background, but the recent update to the bing tiles around here has resulted in them being somewhat darker than they used to be. When one is trying to use line and area, the cursor is black on a dark image and I was having trouble even locating it. I've switched the cursor to white and for the imagery this is a lot more usable, but obviously now a problem with the lighter background imagery. Is nobody else find these problems with the defaults id has adopted? It's certainly unusable with Open Streetview when boundaries like fences and the like are involved. And while my restructure of the style helps in some areas, it's still not able to provide a complete solution. I've not worked out yet how to add back all the missing icons which are displaying as blank bubbles in the areas I'm working, but I can at least colour the elements that are present. It is amazing how similar a beer glass and a petrol pump are when both displayed in black -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Reference set of icons ...
OK I've spent most of the day playing with id trying to make it work in a manor that works for me. I'm at the point where I'm working out how to add missing icons to the library, and I'm having some trouble finding a suitable reference set to work from. https://github.com/gravitystorm/openstreetmap-carto/tree/master/symbols has rather small icons, but some varying sizes, and is not suitable as a base for larger size icons. I think the default here is only 12x12 icons? https://github.com/openstreetmap/potlatch2/tree/master/resources/icons seems to be a fairly complete 16x16 set and has all the missing icons but can't be used with id which expects circular ones. JOSM uses the same set of icons? My quick comparison would suggest so, and certainly I was seeing the same style from both. I've got the compiled png file for id, but have yet to find the source set for these and we need a 24x24 base image which is then scaled for 16x16 and 12x12, but because of the round bubbles used in id the corners can't be used. My current thought is to take the JOSM/P2 icon set and use the missing ones to complete the id library, but since these are no longer used on the main map is anybody working on a better reference set? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Reference set of icons ...
Bryce Nesbitt wrote: On Sun, Aug 25, 2013 at 1:34 PM, Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk wrote: OK I've spent most of the day playing with id trying to make it work in a manor that works for me. I'm at the point where I'm working out how to add missing icons to the library, and I'm having some trouble finding a suitable reference set to work from. https://github.com/__gravitystorm/openstreetmap-__carto/tree/master/symbols https://github.com/gravitystorm/openstreetmap-carto/tree/master/symbols https://github.com/__openstreetmap/potlatch2/tree/__master/resources/icons https://github.com/openstreetmap/potlatch2/tree/master/resources/icons seems to be a fairly complete 16x16 Have you looked at https://github.com/mapbox/maki Have found that one now ;) And to add to the collection ... https://github.com/mapnik/Cascadenik/tree/master/openstreetmap which is a much tidier way of handling things. Saman (from off list) my target is to restore the colour to the icons set on id and I'm looking at the moment to use the same set of icons as are used on the rendered map, which would benefit from something of a tidy-up to allow the easier generation of alternate sets. To be honest I had expected to find a usable set of sources, but it seems not :( Even carto is missing the icon - power_substation - that started this two days ago! But it's tidily included in josm/P2 and in my mapping area I'm seeing many blank 'bubbles' on id ( god I hate that thing! ) and had expected an easy way to initially just pinch the one off josm and add it to id !!! Not over two days work trying to untie the knots. Where I am currently at is that at least it seems the naming is consistent? So the block of icons power-* should be understood by id since carto is just missing the substation one. Although the first hit is aerodrome in carto and airfield in id ... I'm ignoring the prefix added in josm/p2 here although when coming up with a 'standard' it would be tidier to include that in the definition as it has already crept into carto with the 'power_' block. WHERE is the bast place for me to expend time next? Target wise personally I'd like to see both the older josm/p2 icon set and the newer 'inverse' ones as rendering options with a black and white variation for those who seem to think its cool. Part of the start here was to get the colour back into id, and while it's still work in progress I can complete that easily but crudely, and I will switch the id icons to use carto at least where they are missing. The problem I see is that the nice square coloured josm/p2 icons don't work with id, so making that switchable will probably not work? Technically it's just changing the sprite image, so it's only managing the master set of icons to use that needs work. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Pieren wrote: Perhaps in Germany, all tracks have limited access. But they all have traffic signs indicating the restriction(s). If the tag access is missing, we cannot assume that the mapper forgot the restriction ! What is true in Germany can be wrong in many other countries. Excepted if we admit that OSRM is a German centric routing engine. Yes - another item on my TODO list is to get the routing actually using the 'minor roads' around here. It takes me on a 3 mile detour to get over to the motorway ... so I just ignore it until it's caught up :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Dirt Roads in Mapnik, default render in OSM
Martin Koppenhoefer wrote: But I think this direction of discussion misses the point. The point was how to classify certain types of roads (unpaved connection and residential roads). tracks are a type of road set up for agricultural (i.e. local traffic of who works in the fields or forests or goes fishing) traffic. If there are other reasons for a road to be (i.e. connection for ordinary traffic, access to a plant or other technical installation) the highway class should be chosen differently. A residential road can well be unpaved in some parts of Germany as well, but that doesn't make it a track. In remote zones in Italy there are provincial roads (i.e. roads of the network maintained by the provinces) that aren't paved and are so narrow that 2 cars only at some spots can pass, but that doesn't make them a track. This was part of the discussion on tracks and paths at the time. My own reason for wanting to distinguish what I will call 'unclassified' which do not have a tidy surface or are 'residential' or 'service' which require care is that there should be a clear demarcation between roads that are generally safe to pass and those which may not be appropriate in some circumstances. Personally I was caught out with an older satnav showing no change when going from a main A road to what was essentially a 'dirt track' ( at that time not even a colour change ) ... it was still a perfectly legal road and there were warnings about single track with passing places, but I might have preferred to re-route if I was towing and I was already committed by the time the signage appeared. I think the real point is passing on the information that while a road may be part of the normal transport network, some may be less than suitable in some circumstances! Simply tagging 'unclassified' and merging with roads which are simply unmaintained by the local council while valid does not easily pass on important information while personally I feel these are 'tracks' and need to be tagged as such! It is different rendering that is the point here ... and iD is making this even more problematic by rendering everything with very similar styles even for footpaths! ( And this discussion should probably be on the tagging list, but I've still not added that to my catalogue ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Living with 'improvements'
I've started a new thread rather than reopening an old one on my ongoing saga with using OSM as a routing option. Since the only suggestion o that thread was to try OSMAnd. http://lsces.co.uk/wiki/OSMAnd has the latest set of notes which I've gatheread after a few weeks of trying to live with OSMAnd. As with the LocusPRO problems, they are bad enough to prevent it being used on it's own. I've still got the TomTom hooked up as well even if the map is well out of date now. I've logged it in an issue on the osmand tracker but while cross checking things I did not find it listed in http://wiki.openstreetmap.org/wiki/Routing and since it does have it's own separate page I assume that I should complete the loop here? One thing I do seem to have established is that it is the handling of x_link which seems to be lacking in all the options I have been testing. While the rule is 'don't tag for the routers, the x_link tag is specifically router based and should take priority when describing a move. The direction 'Bear slightly left onto the M5' is somewhat misleading when you are actually leaving the motorway, and 'straight on' is even more incorrect but is what LocusPRO announces for these junctions! Basically - does anybody have a smartphone option that correctly and safely handles UK motorways and trunk roads? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Living with 'improvements'
Lester Caine wrote: Basically - does anybody have a smartphone option that correctly and safely handles UK motorways and trunk roads? Well I'm seeing some feedback off-list, and there have been a few steps forward, but The one thing I have finally established is that off the 5 routing engines so far tested, none can handle the roads in the Cotswolds. I have yet to get some confirmation, but Yours, OSRM, OSMAnd, MapQuest and CloudMade all fail to pick up tertiary routes unless one is actually ON the road in question? As a result they make detours via other roads to get around those sections and add ten's of minutes to a journey. The biggest so far is a 10 mile diversion north, but a couple of miles are added to journey south, via four more roundabouts. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Living with 'improvements'
Greg Troxel wrote: Lester Caine les...@lsces.co.uk writes: Lester Caine wrote: Basically - does anybody have a smartphone option that correctly and safely handles UK motorways and trunk roads? Well I'm seeing some feedback off-list, and there have been a few steps forward, but The one thing I have finally established is that off the 5 routing engines so far tested, none can handle the roads in the Cotswolds. I have yet to get some confirmation, but Yours, OSRM, OSMAnd, MapQuest and CloudMade all fail to pick up tertiary routes unless one is actually ON the road in question? As a result they make detours via other roads to get around those sections and add ten's of minutes to a journey. The biggest so far is a 10 mile diversion north, but a couple of miles are added to journey south, via four more roundabouts. I find this all surprising, and wonder what's wrong. I have OSM data in my garmin 50 (with mkgmap) and (in the US, which is a different place with different data, etc.) it works fine. When I get some spare time I'll get back into the OSRM code to see what is happening. Interestingly Bing makes the same mistake but Google is finally picking up the correct route! https://maps.google.co.uk/maps?f=dsource=s_dsaddr=WR12+7EPdaddr=Ashchurch,+Gloucestershire+GL20,+UKhl=engeocode=%3BCc8Qtwf2VNEBFU9sGQMdYeLf_yktTuFVeB1xSDECJZbUk_aHhAaq=0oq=wr12+7epsll=51.997775,-2.104735sspn=0.010741,0.026672vpsrc=0mra=lsie=UTF8t=mz=12 Everything else goes via Wickhamford. From the M40 north of here we get taken over to Alcester then down the A46 to Evesham before coming back over. Rather than down the B4632 ... As long as I move off the 'A' roads it then picks up the B4632 ( the original A46 ;) ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Living with 'improvements'
Janko Mihelić wrote: Well, the A46 and A44 are trunk roads, and the Hinton road is an unclassified road. Of course the router is going to think it's much faster to go by trunk road. If you want to fix that, you'll have to put in the maxspeed tags. Then the router will have enough information to choose the better path. If the fix for this is to manually apply the national speed limit to every road, then OK, it's the first time anybody has suggested a fix and I'm willing to give it a try ... As it turns out, the 40MPH limit on the A44 was not actually recorded. I don't go that way often so I'd missed that one. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Living with 'improvements'
Janko Mihelić wrote: 2013/9/2 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk: If the fix for this is to manually apply the national speed limit to every road, then OK, it's the first time anybody has suggested a fix and I'm willing to give it a try ... It's useful to give the source of the maxspeed. So if you have a sign, just put source:maxspeed=sign. If there is no sign, and source is the law, put source:maxspeed=uk:urban for maximum speed in urban areas, and source:maxspeed=uk:rural for rural areas. I don't know the laws in the UK. http://wiki.openstreetmap.org/wiki/Key:source:maxspeed That's the way we in Croatia mark maxspeed. That way if the default maxspeed changes, it will be possible to change it automatically. The real point here Janko is there was a very major stop put to tagging ALL 'national speed limit' roads with tags as such. Short term I've added them locally, but they will need to be removed to comply with the tagging guidelines for the UK! It's the routing algorithms that need to be fixed. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Living with 'improvements'
SomeoneElse wrote: If the fix for this is to manually apply the national speed limit to every road, then OK, it's the first time anybody has suggested a fix and I'm willing to give it a try ... (I'll assume that's not an entirely serious suggestion - the last time someone tried it it was very nearly bonfires and pitchforks all round!) It would seem Andy that the 'rules' changed while we were not looking. It seems now that we should be tagging all roads :( For roads signed using the national non-numeric speed limits signs it is generally recommended that one also adds GB:motorway, GB:nsl_dual or GB:nsl_single to source:maxspeed=*. I certainly don't agree with that. It will add a vast raft of extra tags to the road way data since they will have to be added to every link road and bridge section. JUST tagging the variations still in my book the way to do this and the router algorithms apply the correct speeds based on the type of vehicle. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Living with 'improvements'
NopMap wrote: I noted that navit is currently missing from your list of options. I have missed the last two years of development there, but I used to have it on my smartphone before that as street navigation and I liked it a lot. You can set up the routing speeds by street type in a configuration file and tweak it until it matches your preferences. Naturally, I never tried it on UK streets, but I would still be using it if the onboard navigation of the new car didn't have such a great speech interface.:-) I knew there was a reason I'd crossed it off ... it will not install on the tablet and it's not using the phones own keyboard but one where one has to find the letters in alphabetical order. Basically it was crossed off the list before even getting to test it's routing capability. For those of you who haven't found it yet on Android ... Hacker's keyboard ... I am so used to the N900's navigation keys and also needed access to things like CTL, TAB and ESC when remote accessing the servers. Hacker's Keyboard gives that back and more important BOTH devices now work the same way :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Developing Countries Address Problem
bimal maharjan wrote: I understand that OSM as a whole does not define the address system. But I am taking help from our community members to find out about organizations or professionals or start ups who are working on this problem so that I can contact them to learn more about the solution to this problem. Bimal - I am sure that will be other areas which have the same problem as you. I think that the only solution to this is something that requires action at a 'higher level'. Obviously the ideal is government level, but if there is no interest at that level you will need to organise at a lower one. Since you are looking for someone to deliver items to you, the starting point could be talking to them. Perhaps it's time to set up a local 'mapping' group as a base to work from to both improve the map so people can find you just by giving them your location. And then expand on that by agreeing locally on what to call roads ... Use OSM as a base for a local campaign ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] 'Quality' of data
Not really the right choice of words, but following on from yesterdays post related to 'timezone' I've been using the tools available and viewing the current coverge of that tag, which is fairly complete - except - in some areas the smaller parcels making up an area rather than the area itself is tagged with the information. Now in theory it should nat matter as I should be able to throw away relations totally contained within another and be left with the top set, but should that 'processing' be applied in general to this type of 'relation'. ISO3166 country codes are perhaps another example. Add a note to the relevant guideline that if tagged item is totally contained within another of the same 'value' then it will be removed. This links to how one gets a list of tags related to all of the relations a query co-ordinate is located in so we can return that 'inventory' Not very well put, but I should be in the car aon the way up to Birmingham ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Quality' of data - combining 'things'
Lester Caine wrote: Not really the right choice of words, but following on from yesterdays post related to 'timezone' I've been using the tools available and viewing the current coverge of that tag, which is fairly complete - except - in some areas the smaller parcels making up an area rather than the area itself is tagged with the information. Now in theory it should nat matter as I should be able to throw away relations totally contained within another and be left with the top set, but should that 'processing' be applied in general to this type of 'relation'. ISO3166 country codes are perhaps another example. Add a note to the relevant guideline that if tagged item is totally contained within another of the same 'value' then it will be removed. This links to how one gets a list of tags related to all of the relations a query co-ordinate is located in so we can return that 'inventory' Following a couple of discussions at Birmingham yesterday, a couple of additional points came up which I am sure have been discussed somewhere. I'd like to propose the concept of a 'metatag' which is a tag which is returned for every point enquiry. We do not want to create a lot of these, but a few would make sense. timezone, and 'administrative' such as ISO3166 codes should be a useful key, but also landuse. All of these would be relations rather than areas, and would automatically but combined to provide a single 'overlay' ... one result per node on the data. This relates to another apparent anomaly when people are adding data like 'landuse' in that where two areas touch, we get two overlapping ways which may require tagging with different boundary information. The particular example was field boundaries for agricultural use. My own 'style' is to pick out the whole area as agriculture, and then add the field boundaries within that area. But others draw each field as an area, and then there is no way to pick up to tag the boundary type. The timezone data is another example where 'style' changes, and some zones have tens of small areas while the majority are single relation per timezone. I think that we need to come up with some way to assist in combining data where there is no need for duplication if the result set of an enquiry can include the relevant tags. Select all the areas tagged with the same 'metatag' and then rework them to provide a relation and separate ways where the boundary is common. I'm also thinking here that the 'addressing' problem could be helped if 'postcode' (or something equivalent in areas without) was a metatag, and when a building is selected, adjacent street tags were listed so that the correct one can be applied to the building. Saves having to type the street name every time, and would reduce the volume of data needing to be stored as that would only be entered once per 'postcode'. The administrative metatag would return the area details for a postcode. This would hopefully allow us to get around the current problem of things like 'Broadway, Wychavon' when it should be 'Broadway, Worcestershire' ( and Not Broadway, Gloucestershire which ia all Facebook will accept! ) Back off out to Birmingham ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Outperforming TomTom
Jean-Marc Liotier wrote: Since the majority of sat nav's are now smart devices, why can't they all be reporting back the average speed where they are so we can automatically map the current traffic hot spots? That data is already available for sale from mobile network operators - that is why you don't see much interest in having navigation devices provide feedback: every mobile device is already providing ample sampling. Of course that doesn't help the free world very much... That is why what I'm thinking is the 'free' version ;) A sort of agreed standard linked to the various OSM routing options? Maarten - I can understand your reluctance on always on data, currently I do get gaps in the mapping on the motorways here were there simply isn't any cover, but moving forward I think that particular problem will eventually be fixed. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Deleting data
Russ Nelson wrote: We need to make sure that the Wikipedia deletionism doesn't take hold within OSM. Because, if I have to spend time defending the data I've already entered, that will take away from my effort to enter new data. And a lot of wikipedia articles still have pointless complaints attached about threats to delete material where THEY are the best authority for storing the original data. OSM is a similar 'unique' archive of material! In case you think I'm blowing smoke out my butt (who the hell blows smoke out their butt??), I've entered about 90% of the lakes in NY that are there, and about 50% of the rivers and streams that I have looked for (so far). I've aligned the TIGER data in about 7 counties. It's a huge amount of work that nobody else is doing, and it would be a shame if I had to stop people from deleting what I've already done. I stand firm against deletionism! There should not be a 'delete' mechanism at all, only one which can amend or archive so that we can SEE the historic development of the information! This is as valuable as the CURRENT view ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
Frederik Ramm wrote: Time zones, in contrast, are * orders of magnitude less useful than admin boundaries (most countries will simply have one time zone for the whole country) * not useful for mappers * readily available in shape file form so why map them? Except that the currently available 'shape' files are totally useless near boundaries putting whole towns in the wrong time zone! The 'boundaries' we are looking for ARE in many cases the same as the political boundaries, so SIMPLY adding a timezone tag to these boundaries is all that is required ... except where there are specific variations in which case these NEED to be mapped. What we are currently pushing is that OSM provides the base for that information against the TZ database. The current arguments on the TZ database are that variations in time prior to 1970 are pointless and so should not even be recorded! Another area where historic data is being purged, but many of the details relate specifically to locational data which can only be accurately recorded as a map. Yes these are also political boundaries in many cases, but it is information that needs to be 'surveyed' by access to historic material rather than simply looking on the ground. This is an area that OHM has been set up to complete the coverage, but in a large majority of cases, this material is still current, and so should be in OSM first ... The major problem I've pointed out several times is where a higher level tag like 'timezone' is then attached to every element below the boundaries that it relates to. We need to develop the boundary relations in a manor that a search for a locations 'details' return all of the relevant higher level tags - if requested! - and where a higher level tag is applied to several adjacent areas, a single relation is created using the boundary of the whole area ... that is if one does not already exist. I've come to the conclusion that ADDING areas is where a lot of this is now breaking down when one needs to use the edges of those areas for other disjointed tagging. At a lower level fields and field boundaries where one has three ways all overlaying because two of them are parts of areas! Moving up to residential area and other small political boundaries which have been drawn as areas but need to be pulled apart to use existing ways in much the same way that nodes are automatically shared? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
Janko Mihelić wrote: It's even easier to add the tag on existing countries relations. No need for extra ways, neither tagging on ways. +1 Are there any timezones that don't follow country or some other administrative borders? This is unfortunatly part of the current problem WITH timezones ... The timezone data currently ignores any changes in 'time' prior to 1970, and so if you use a current timezone, you have to know exactly how that zone was created. Just like the 'historic' map data we need to maintain an acurate DST database for the period before 'time' started as far as the TZ database is concerned, and at that time areas were using different rules even within the same country. The current simplification aligns timezones with country codes or sub=codes, but it's accuracy is basically 'undefined' prior to 1970 :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
Colin Smale wrote: My point is, gut feelings aside, that it is not reasonable to single out TZ boundaries for this deprecation. Actually having accurate TZ boundaries in OSM is probably more important than some of the political boundaries. The reason I've been looking into this is simply because other sources of TZ data are badly broken near boundaries ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
Janko Mihelić wrote: I don't think we really need layers, but could use editors that are semantically aware of things like boundaries, and put them in the background until needed. As far as I see, if we just prevent certain ways or nodes to share nodes with others, that is as good as a layer. So if we say boundary=* can only share nodes with each other, then that is a layer. I think those rules are better then inventing some arbitrary fixed layers. I think that this is part of the 'problem' Sharing nodes was thought to be a good idea, but that only works well when all of the data is tightly related. Once one introduces 'loosly' related data, then there is a need for separating nodes depending on their 'layer'. I feel we are getting to the point where we need to think about 'sharing' ways rather than jst sharing nodes. Returning to the example of field boundaries, an existing 'way' that forms the edge between two other areas only needs to exist once, so drawing the next field can be done using the existing boundaries, and many areas simply become relations picking up a list of ways. Moving to the higher levels, boundaries of the smaller elements get used in a lest of ways bounding the bigger one. These shared ways would have their own set of nodes which may relate to underlying ways ... rivers for example ... but would not neceserally be the same way. Information would be managed in 'layers' but these may well be tagged by time rather than 'level' and just allow an easier way to filter what is being used? Currently what we are doing with areas when used for objects like land use IS wrong? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Timezones (was: Deleting data)
Bryce Nesbitt wrote: I don't think we really need layers, but could use editors that are semantically aware of things like boundaries, and put them in the background until needed. As far as I see, if we just prevent certain ways or nodes to share nodes with others, that is as good as a layer. So if we say boundary=* can only share nodes with each other, then that is a layer. I think those rules are better then inventing some arbitrary fixed layers. So many boundaries *are* the road. I think we're better off finding a way to attach a landuse to a road edge without necessarily sharing nodes. And for that matter declaring certain boundary edges are co-incident, without necessarily sharing nodes. This is a growing 'requirement' ... parallel ways rather than simply 'shared nodes' ... so one can move the boundary independant of the 'road'. Just had a simple problem where I needed to tidy 'landuse' but it was all interleaved with other elements which certainly did not want to move :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Rob Nickerson wrote: I appreciate that this may not be what you wanted to hear, but as with any big change, there is likely to be a few teething issues. Unfortunatly this has now broken many inter site links so personally I'm looking for a route to retore a more usable interface for those of us who USE the website as a tool for USERS who have no need to even think about opening an account !!! We do normally live in a democracy ... some one person enforcing their view is not acceptable and this IS now a major hassle for many of my own site links ... when I select 'view larger map' I expect to get to a larger map not a sales site :( There SHOULD be something we can add to all those legacy links to make the site acceptable! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Lester Caine wrote: I appreciate that this may not be what you wanted to hear, but as with any big change, there is likely to be a few teething issues. Unfortunatly this has now broken many inter site links so personally I'm looking for a route to retore a more usable interface for those of us who USE the website as a tool for USERS who have no need to even think about opening an account !!! We do normally live in a democracy ... some one person enforcing their view is not acceptable and this IS now a major hassle for many of my own site links ... when I select 'view larger map' I expect to get to a larger map not a sales site :( There SHOULD be something we can add to all those legacy links to make the site acceptable! I've just realised exactly why I have a problem with this ... The old layout was perfect for use as a basis for a 'larger map' when linked to from all of the embedded maps ... it WAS obviously a website for promoting OSM, and had obvious links to do other things rather than simply viewing a 'larger map'. CURRENTLY one is presented with what looks like something that one should NOT have reached ... for general users! ... It LOOKS like you are logged into something and it's not obvious what to do next !!! You are there simply because you wanted a larger map so 'learn more' and 'start mapping' simply don't apply. This new front page simply does not work on many levels and I hope I'm not the only person who thinks that? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Lester Caine wrote: This new front page simply does not work on many levels and I hope I'm not the only person who thinks that? No this is getting even more iritating ... Can someone with the capability to sort out DNS PLEASE create old.openstreetmap.org with a link to the old front page. Something is needed to replace the current 'View larger map' and at least that while wasting time having to go around and update every link would give something a lot more usable! (And the 'about' page is even more confusing despite the fact I know what OSM is) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Rob Nickerson wrote: Hi Lester, If you are after a full screen map for your website, it is very easy to create one with a simple html page that links to Leaflet (the tool for providing pan and zoom, etc) and the tiles server at OSM. I've attached something I was able to get up and running quite quickly. My web developer skills are near zero :-) You are missing the point Rob ... People are used to clicking on 'View larger map' and getting to Google Maps. The OLD website while not the prettiest was more in the style of what people are used to getting. I want to promote OSM and so I need something that is on the OSM side that is uasable. I've just switched all of the promotional links from openstreetmap.org to wiki.openstreetmap.org as THAT is a lot more informative than where people are ending currently! The new front end has a place, but THAT is probably at map.openstreetmap.org rather than the main front page. Even if I was seaching for OSM cold I think I'd feel 'What the f**k' when confronted simply with a map and a few strange links. Being forced to log in just to get to something usable information wise is just not right. None of the first clicks give any sensible support for a new user even if they ARE looking for contributing. If OSM is not going to provide a usable set of pages, then I will roll my own. I do already have that running, but it's OSM's site that needs to be linked to directly to promote it! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Simon Poole wrote: Lester Isn't a) the welcome box and b) the Learn more/About page a -lot- better on explaining what OSM is about than anything you could find within one click (if at all) on the old site? I really fail to see what you believe was better about the old layout, maybe if you could give an example? If you simply remove the welcome box, then the page looks very much as if one is already logged into something? Most of the dropdowns make no sense UNTIL one has an account and are logged in? What is 'export' intended to do? I just get a white screen when I click the button. The 'about' page seems like a waste of space? The fact that 75% of my screen is grey was the first put off, but I could not find links that took me to anything usable from that page. It NEEDS to take you on to somewhere that is a little more useful? Also the help button is equally obscure? The help list is not the easiest to understand, only wiki gives a feeling of something helpful, which is why I've defaulted links to that rather than the map. The 'improved' page is ideal as a general interface to editing the map, but what is needed is a 'community' page - which the old page provided! - at least there was some direction to other areas rather than having to search for any usable links! While the old setup was messy, it did it's job reasonably well, and we STILL need that type of page, with improvements which the new setup totally ignores! We need links to LOCAL community pages and LOCAL support and that is what the 'about' box should be doing at the very least! At least the old page was 'functional' even if it was not 'elegant' ... looking at the way 'Google maps' work, bringing back a right hand area which can be hidden is probably what is required but what is currently provided is not doing the job as far as I am concerned. What we have now is not usable as advertsing for OSM, which is what all the 'View larger map' links are designed to access? Am 30.11.2013 15:41, schrieb Lester Caine: Rob Nickerson wrote: Hi Lester, If you are after a full screen map for your website, it is very easy to create one with a simple html page that links to Leaflet (the tool for providing pan and zoom, etc) and the tiles server at OSM. I've attached something I was able to get up and running quite quickly. My web developer skills are near zero :-) You are missing the point Rob ... People are used to clicking on 'View larger map' and getting to Google Maps. The OLD website while not the prettiest was more in the style of what people are used to getting. I want to promote OSM and so I need something that is on the OSM side that is uasable. I've just switched all of the promotional links from openstreetmap.org to wiki.openstreetmap.org as THAT is a lot more informative than where people are ending currently! The new front end has a place, but THAT is probably at map.openstreetmap.org rather than the main front page. Even if I was seaching for OSM cold I think I'd feel 'What the f**k' when confronted simply with a map and a few strange links. Being forced to log in just to get to something usable information wise is just not right. None of the first clicks give any sensible support for a new user even if they ARE looking for contributing. If OSM is not going to provide a usable set of pages, then I will roll my own. I do already have that running, but it's OSM's site that needs to be linked to directly to promote it! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Simon Poole wrote: I really fail to see what you believe was better about the old layout, maybe if you could give an example? Just 5 examples to start with: I was not soliciting general input, just specific to Lesters complaint (which was not about functional issues for mappers). As to general complaints, I don't see any way forward without making somebody unhappy, we've already sunk multiple man weeks in to one re-design that didn't happen, no need to repeat that again. Functional defects that are not simply a matter of taste obviously should be documented and reported in an issue. Which is why I simply ask that the old layout is made available again as that only requires access to pages that already exist. What is currently being offered is probably acceptable to users who are there with a view to contributing, and then requiring registration makes sense, but for the vast majority of visitors brought here by USERS of the data it's just not right. I know that there is a lot of support for NOT providing services, but until a suitable replacement can be created for the many thousands of us using embeded maps, maintaining usable operation is important. The current changes are not compatible with using the embed function so THAT should have beendepricated first and time provided for us to make changes to existing usage! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Lester Caine wrote: Which is why I simply ask that the old layout is made available again as that only requires access to pages that already exist. Silly question ... where has the 'embed' option gone? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Simon Poole wrote: Share - HTML ? Am 30.11.2013 23:02, schrieb Lester Caine: Lester Caine wrote: Which is why I simply ask that the old layout is made available again as that only requires access to pages that already exist. Silly question ... where has the 'embed' option gone? Tool for creating script for http://rainbowdigitalmedia.co.uk/wiki/contact embedded map ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Paul Norman wrote: I know that there is a lot of support for NOT providing services I'd say there's a wide desire for offering services like OWL and routing on OSM.org. Of course, these take development hours, time, and money, so a wide desire doesn't translate into actually adding the services. but until a suitable replacement can be created for the many thousands of us using embeded maps, maintaining usable operation is important. The current changes are not compatible with using the embed function so THAT should have beendepricated first and time provided for us to make changes to existing usage! I looked at the embed HTML generated, and I don't see what doesn't work. All the links are valid, and the page that you land (the front page) seems more likely to covert the visitor to a mapper, because it now gives some text to explain where they've ended up. Some how I don't think we are looking at the new front page the same way ... It's the very fact that it IS designed to make 'convert to mapper' the REQUIRED result that is the problem. What is preferable is a half way house that provides the information ON THE ONE PAGE that can be used as the 'Larger View' from the embeded versions. I don't see why simply restoring the old front page for that purpose should be any additional work? The map used on that page can be the new view and switches to the mapping front end when someone has time to follow that path. I can see a compromise that gives an information panel to the right in place of the welcome box but supporting THAT needs work, where a simple 'old.osm' url would be a lot less work? It sounds as if I'm going to have to create my own site to support this ... While I can see that on the whole the new front end has a number of nice features it IS too targeted at a different goal, and as an information page for OSM it fails miserably so something better is needed! The wiki front page is a bit of a mess, but is much more useful now, but the fundamental problem of taking new mappers to LOCAL support is even less well supported now? It seems that everybody has to work in English if they want to use OSM :( And I still need to find out where the 'export' is intended to go? Is that were we should be able to create embeded frames or somewhere else? Share does not provide the material and hacking the code manually is not something novice users can do easily. In the past my clients could play with this, but at present there is nothing suitable. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Shaun McDonald wrote: osm.org is aimed at mappers and people mapping, rather than as a general purpose go to site for navigation. I'm not arguing otherwise, but at present even FINDING another site that CAN be used for routing from the new front page is a nightmare. Alright the old page was messy, but there were at least obvious links to get to other sites. The new setup seems to be saying 'if you are not here to map go away!' If this is really the case then perhaps we need a NEW site for those of us who contribute data with a view to actually using it live? The about page is VERY short on help to get to other material ( but I do not object to advertising sponsors on that page ), and I probably need to try the site as a cold user to se if registering a new account is any more helpful, but trying to establish what is needed to help WITHOUT registering is not looking good. It's not the interface itself that is the problem, but simply what material is displayed in those first couple of clicks! Perhaps all I am asking for is a simple link to 'other services' in that welcome box which take you to a wiki for accessing routers and other useful tools? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Ed Loach wrote: Lester: The about page is VERY short on help to get to other material ( but I do not object to advertising sponsors on that page ), and I probably need to try the site as a cold user to se if registering a new account is any more helpful, but trying to establish what is needed to help WITHOUT registering is not looking good. It's not the interface itself that is the problem, but simply what material is displayed in those first couple of clicks! Perhaps all I am asking for is a simple link to 'other services' in that welcome box which take you to a wiki for accessing routers and other useful tools? Perhaps click Help rather than About - that has the simple links to help and the wiki. Click on 'Help' you THEN have to decide what will be more helpful. The 'help list' is not the best choise but it IS presented first. Metion was made of 'Getting started', and to be honest THAT is something that is currently missing? After that, the wiki should be listed next. But finding the HELP button when the 'Learn More' button is presented in the welcome box? I find nothing in the About box that helps me to 'Learn More' ... Naming the button 'About OSM' would at least hint that something else may be more appropriate if you ACTUALLY want to learn more about contributing or using OSM? Having selected 'Learn More' one is in something of a dead end? It's not clear then WHERE you go? I am in two minds about routing on the main OSM website. Yes, it can be done, and it can be useful for a mapper to check connectivity of what has been mapped, and whether turn restrictions work, etc, but then you need to consider supporting for every transport mode (or just pick car to start with and wait for all the complaints from cyclists, pedestrians and lorry drivers moaning that the new routing feature is useless for them...) But there are other sites already which use OSM for routing and it might be better to use whichever of those best suits your preferred use case. This is perhaps another case where a separate site IS needed for those of us actually using OSM as a generic replacement for Google? On some of my newer 'contact' pages I have added a 'Get Directions' button in addition to the 'View Larger Map' ... and that is where the previous style change still causes some confusion! The Embeded map still has the old navigation style on the left as does the router I'm going to, but the OSM map changed to the right. I would use the Router as the large map, but I actually want to PROMOTE OSM which all this is currently about. None of the current router options are as reliable as the other on-line options, (and that is a separate problem ...) also you need to select one more suited to your country, which comes back to my appeal for a more 'locally focused' support path. Basically there is nothing I would recomend as a global routing option anyway? So no obvious candidate for a world wide link? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Good use of time ...
OK first call of the morning about the new front end ... I'm expecting to spend a lot of time this week explaining things to people, but *I* don't have the information I need to do that! PLEASE can someone who understands all the ramifications of the new changes produce a help file to explain! I've explained already that none of my own crib sheets are now usable and I need to rewrite them, but can't do that without the current information. I ask again - what is 'export' intended to do? Moving forward, I have a LOT of material in the todo file to be added to the map data, but very little spare time to do that work. The majority of my time over the last few years has been spent fire-fighting changes in the infrastructure to keep my end customers working. We now have to support windows from W2k to 8.1 simply because there is no time to rework core software that is not longer supported by others, some of which will only work on W2k! Add to this all the 'improvements' in the browser market, and all of the changes to PHP and things keep getting broken everywhere. Even Linux tools seem to get broken with every 'improvement' ... anybody got used to gimp's redesign yet ... I KEEP trying to save images rather than now exporting them :( This is why any changes to the infrastructure takes time to assimilate. The changes to 'style' applied to the OSM site still have not been reflected in the rest of the infrastructure yet. 'Id' still does not provide a suitable on-line facility for my usage, so JOSM is getting used more often, but is different again to the rest of the infrastructure changes. Asking us to 'contribute patches' to fix problems is a major headache where the infrastructure is using a less popular framework to start with. If we could get back to a much flatter playing field with fewer programming languages and variations on that, then perhaps everybody would be a lot more productive? I've had several attempts at working with elements of the OSM infrastructure but am currently stuck with an out of date slice of the planet file and code that will not run. So I'm reliant on the on-line services to do anything productive in OSM. Please can we target some of the background services such as the management of start and end dates better in general so we can make some progress on providing OHM and develop a more coherent mechanism for handling 'archive' rather than simply deleting historic data. A large section of data that I've been compiling is start_date, but this is a little pointless where it is not being managed properly? Also *IS* there a consistent way of maintaining up to date local mirrors of the data? Working with 2 week old data is bad enough, and I'd like to be working with something closer to live then I can provide my own material, but until then I'm reliant on what overs are doing ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Welcome box on the new map page
Barry Hunter wrote: The new setup seems to be saying 'if you are not here to map go away!' If this is really the case then perhaps we need a NEW site for those of us who contribute data with a view to actually using it live? http://open.mapquest.co.uk/ ? That is a site for end users of OSM created maps. In many ways OSM is a data provider, it doesnt have the resources to create website for end users (as such). Now I've now found the 'html' option on the OSM map, and along with the link and short link these target the same map. Simply replacing the URL with the mapquest one does not provide a working link, and in any case the rendering of roads in this area is simply wrong ... and that is the whole reason for using the links in contact pages. If a service is not going to be provided then it should not be prominent on the front page? In any case, the embeded map is provided via OSM and so maintaining a compatible rendering in the follow on link is important, switching to one with a different style on another site seems wrong? If we were providing these pages ourselves then we would still be using the OSM tile server? I got around 50% of the way through rendering my own set - after 7 days - but the tiles were already well out of date :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Good use of time ...
Maarten Deen wrote: On 2013-12-02 14:38, Barry Hunter wrote: On 2 December 2013 13:17, Lester Caine wrote: what is 'export' intended to do? It gives option to select an area, then download a osm XML file. Exports the map as data. If the area is big, gives direct links to various bulk options. There was an option to download to PDF and PNG, which was nice so you could make a printed map immediately. Why has that been removed? That is part of 'Share' now Maarten ... This is the sort of help file that is missing :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bitcoin Spam
Frederik Ramm wrote: I delete the ones I encounter when they're outright spam but I'm shying away from suggesting some kind of automated cleaning job because I'm not clear on what the minimum tagging should be on any node. We don't currently have any such rules but seeing people dumping things into our database that we can't use just so they're shown on coinmap seems a bit strange. A request to 'coinmap' that any information added here must include the type of premise, address and postcode? Otherwise they will be deleted as having no physical existence? And if they don't oblige then block the bitcoin tag ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The new OpenStreetMap.org design
John Firebaugh wrote: This redesign is a leap forward, but not the end-all be-all. There is most definitely room for improvement, and constructive feedback and hands-on help is always welcome. Design is subjective, and some things like the 'modern' trend to eliminate coloured icons for monochrome ones is a subtle irritation when part of the reason is simply because 'fonts' are monochrome. It's about time that the font system supported full colour, but that is not something that is easy to do. We can at least restore full colour operation in many cases simply by overriding the 'font' and my own infrastructure uses colourstrap rather than bootstrap. Yes the front end is now clean and modern, and yes all the functions can eventually be found, and I'm not going to say that the old front end was any better. Just different. There are a few things more things that need to be done as a matter of urgency, such as providing better help as to HOW to use the new front end? ( No apology here for the capitals! If I was talking to you face to face that word would have been emphasised ) Neither 'About' or 'Help' actually direct well to any real help on using the front page? The other area though is the fact that for many years we have been using the embedded map as a replacement for Google and I HOPE we still want to encourage that use? But the shift to being 'mapping' orientated as it odds with that usage? Now that I've found the 'HTML' share function ... and worked out the options ... it's not providing a tidy solution for the 'location' map. Yes this is subjective, but the 'View larger map' used to provide a single page 'advert' for OSM along with the map and it's that which has been lost? Currently it's a little 'what is going on' when non-OSM 'users' find the new version when they were used to the old one and that will change, but I still think there is a place for a 'single page' map as advertising? I'm editing the current 'HTML' link to remove the 'mapping' orientated display - including raw data on the right - but replacing that with a more useful 'advert' still makes sense to me. The 'about' page is simply too technical as an advert and something that includes many of the old front page links is more appropriate? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The new OpenStreetMap.org design
Ed Loach wrote: Lester wrote: The other area though is the fact that for many years we have been (aside: we who?) Well if I am the only person using embedded maps then why provide them? using the embedded map as a replacement for Google and I HOPE we still want to encourage that use? But the shift to being 'mapping' orientated as it odds with that usage? Now that I've found the 'HTML' share function ... and worked out the options ... it's not providing a tidy solution for the 'location' map. Yes this is subjective, but the 'View larger map' used to provide a single page 'advert' for OSM along with the map and it's that which has been lost? I must be missing something. I've just tried an HTML share and the view larger map link for my test links to http://www.openstreetmap.org/?mlat=51.80497mlon=1.15644#map=17/51.80498/1.15644 I've just been working through all the combinations again to document things myself. Yesterday when I grabbed an iframe, the large map link included a way reference! I edited it out. Not sure how I managed to get that as I would not have know the id number without it being supplied but it's not present today. I'm still having to add the marker to the larger map link. I'll produce a crib sheet when I get time, but I've a couple of websites to get finished and live ... and am working on the location maps ... ( how long will the short link references be maintained? I prefer the full version, but editing the redirect for short links could be a useful feature if they are intended to be permanent. Some site wipe them after 30 days? ) The embedded map does need finishing off with the same style navigation as the newer map, but as others have said, the old slider was a lot more mobile friendly! That still makes it clear in the very top left that this is OpenStreetMap, (and if I'm not logged in and haven't visited before AND clicked 'x' I believe I'll see a welcome box making it even clearer). Checking the old layout that didn't have the Welcome box, but had the bar down the left with lots of links. Hardly an 'advert'. What is it that I'm missing? The brief description text? http://owl.apis.dev.openstreetmap.org/#map=17/51.80498/1.15643 I just prefer that single page layout ... It is actually very clean and obvious what everything is without needing to click on other buttons? The only 'incongruous' bit is the navigation section, and since the embedded map still has the left hand navigation, having to refocus to find them is niggling. It's a bit like the instances where a few Linux apps have moved the basic menu buttons from the left to the right and you have to keep searching for them or switch apps. But the main thing coming to the 'old' page is that you know straight away you are in 'view' mode ... it says so ... there is help for the search ... and there are links to find other areas directly on the screen. BOTH need a 'using this page' help button, but from my own view, all that was ever needed was a close button for the left hand box and for it to close when logged in? But I'm working on a desktop spanning two 26 monitors so the box was never a problem, and I can have JOSM open on one screen while navigating on the other. It's not the 'map' that needed the major overhaul, it's the wiki/help that needs streamlining and all of the out of date material removed. With a getting started guide easily accessible. I know how difficult that is ... some of the crib sheets I've been updating haven't been touched since 2008 or earlier :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The new OpenStreetMap.org design
Ed Loach wrote: I've just been working through all the combinations again to document things myself. Yesterday when I grabbed an iframe, the large map link included a way reference! I edited it out. Not sure how I managed to get that as I would not have know the id number without it being supplied but it's not present today. I have just reproduced this. If you use the Share link when you are on a /way/id page then the View Larger Map link links back to the /way/id page. Whether this is by design (so it links back to where you shared) or something that needs opening as an issue is perhaps up for debate. As the way isn't highlighted in the embedded map I tend towards it needing opening as an issue. Not sure now where I was, but I suspect 'search' ... AH ... Having searched of cause it opened the info panel and then the link has the way tag. My original thought here was 'nice', but it would be nicer to have a 'user' view rather than the mapping detail one. Which is the view I've been TRYING to create for myself these last 5 years :( I'm still having to add the marker to the larger map link. I always get the mlat and mlon parameters in the larger map link tests I have done so far so can't reproduce the problem. I'm suspecting now 'conversion problems' with the ' amp ; ' ... I think that the ckeditor cleanup changed it. Having found the result was wrong I've had to spend time working back up the chain to see why, so your pick up on the info page was very helpful - TA. ( how long will the short link references be maintained? I prefer the full version, but editing the redirect for short links could be a useful feature if they are intended to be permanent. Some site wipe them after 30 days? ) Shortlinks are an encoding based on the location being shared. See: http://wiki.openstreetmap.org/wiki/Shortlink As such they won't expire. OK that all makes sense ... and explains why the marker now has to be the centre of the map. I've been tweaking that for a better display so the separate entries is useful at time. Needs documenting on my crib sheet. The embedded map does need finishing off with the same style navigation as the newer map, but as others have said, the old slider was a lot more mobile friendly! Mobile sites (at least Leaflet based - not sure about OpenLayers) tend to be easier to use pinch zooming rather than using the ± controls (at least on my phone). However, it might be an enhancement to be consistent in the zoom controls (if shown) being in the top right, rather than top left when embedded and top right in the main map. Pinch only works if the device is not fighting against you! If pinch is being used to enlarge the browser window then it can't also be zooming the map within it. So the APPLICATIONS have to be well constructed to use pinch, simply thinking you can use it on a web page is not so practical? Which is where designing to support mobile devices needs a lot more care. I've opened the embed including way/id as issue 616 https://github.com/openstreetmap/openstreetmap-website/issues/616 and the enhancement suggestion as issue 617 https://github.com/openstreetmap/openstreetmap-website/issues/617 Thanks for that ... I would have got around to it, but I'm away now for 24 hours ... hopefully working off my phone and tablet :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bitcoin Spam
Ed Loach wrote: I guess e-businesses have a legitime interest in being found on a bitcoin accepting businesses directory, but not necessarily on being shown on a bitcoin map. One I edited recently (probably - is there any way of telling for sure if the edit has come via coinmap) was a user at Discogs who had linked to his user page there. I've left his address on the node. Ah, and the user has edited again since: http://www.openstreetmap.org/node/2564289615/history I'll leave it this time though as I don't want to get in an edit war. This is where a fixed list of 'shop' designations would help. That one will never show up as a shop anyway? But the question is probably what should be in the name field? The original entries were obviously wrong, and the current tags are better ... except for name? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bitcoin Spam
Peter Wendorff wrote: but they are no shops, and they should not be tagged as being shops. You cannot go to the corresponding address and do something - as a usual client. access=email_only :) The address is not a problem since we want them detailed, it is only the extra tags? But I like the idea of 'office' rather than shop, that makes more sense? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] 'Allowed data'
a database of physical objects selected from 'The Data' and augmented with virtual lines where no physical one exists. I am thinking here that the ways required for those type of geometry can be cached easily in a separate database and either updated as the underlying ways change, or actually more usefully, where a boundary changes in the future, the historic versions are maintained! I'd like to get back to adding to 'The Data' rather than fighting the infrastructure to use it. 'The Map' is an alternative to what came before, but it only addresses a small area that was less broken than the bigger infrastructure, and so now we just need to refocus from a different angle? One can use 'The Data' without 'The Map' but accessing the information on how to is still an area that needs fixing. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
Martin Koppenhoefer wrote: I would like to request that 'start_date' is automatically populated with ad the very least, the current date, but with an option to update it based on what is being traced from? if you are refering to the tag start_date than I strongly oppose this idea. Hardly ever will the start_date of an object be the same than the time the mappers adds it. I am referring to using 'start_date' is it is currently documented http://wiki.openstreetmap.org/wiki/Key:start_date At a very minimum putting a current timestamp in will give a starting point since we know it is valid today, although a future start date is also possible. It is creating the habit of populating it and encouraging the addition where it is known. end_date is only required when an existing object is removed from the data. If you are refering to changesets or version timestamps then you are a lucky man, because this is already done. Every single version of every single osmobject has a precise timestamp with not only date but also hours, minutes and seconds. That is a completely different set of data ;) And since elaboration seems to be required. The history of the way data is created is not the same as the history of how an object came into existence. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
Andy Street wrote: On Thu, 05 Dec 2013 15:20:58 + Lester Caine les...@lsces.co.uk wrote: Martin Koppenhoefer wrote: I would like to request that 'start_date' is automatically populated with ad the very least, the current date, but with an option to update it based on what is being traced from? if you are refering to the tag start_date than I strongly oppose this idea. Hardly ever will the start_date of an object be the same than the time the mappers adds it. I am referring to using 'start_date' is it is currently documented http://wiki.openstreetmap.org/wiki/Key:start_date At a very minimum putting a current timestamp in will give a starting point since we know it is valid today, although a future start date is also possible. It is creating the habit of populating it and encouraging the addition where it is known. The start_date is the date that it feature came into existence not the date it was mapped so automatically populating it will just lead to junk data that is indistinguishable from the real valid data. What you really asking for is an auto-generated start_date_sometime_before tag but that data is already logged in the changesets. There is also the matter of *what* started. Take the following example: building=yes amenity=pub name=The Mappers Rest start_date=2013-11-15 Was the building first opened on that date? or was it when the pub began trading? Perhaps that was when the name changed? To do this properly you'll need to automatically add a start_date_sometime_before tag for every tag in the database! Changes to details on the object would be covered by the changelog entries. At this stage simply a date that physical building came into existence would be nice. That only the current view of the object is provided is what 'The Data' is designed to supply, and in this instance the start_date is when the building physically appeared ... You are perfectly correct that there are more start_dates needed, but starting today, any information change such as 'The Mapper Rest'-'The Mappers Arms' would be fairly accurate using the changelog dates. When it is scheduled to change at a future date, we have no means of recording that data. 'The Data' does not do history even if it relates to live data? We have to make those changes in real time rather than relying on the API serving the time correct view! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
Joseph R. Justice wrote: On Fri, Dec 6, 2013 at 10:56 PM, Russ Nelson nel...@crynwr.com mailto:nel...@crynwr.com wrote: Andy Street writes: Was the building first opened on that date? or was it when the pub began trading? My main use of start_date and end_date would be for railroads, and even that isn't sufficient, because some railroads were built, used, ripped up, and laid down again, and then ripped up again. How would that be tagged? start_date, end_date, start_date_1, end_date_1? Head asplode! The first obvious solution to that would be to create two entities in the database which just happen to coincide, and which should probably be linked somehow. One entity would be for the land, the physical ground underlying the railway, and would represent the land easement for the railroad, the physical location. The other entity would be for the actual tracks in the ground, the rails and ties and switches and the like, setting on top of and supported by the physical land easement. It would make sense for the entity representing the tracks in the ground to link back to the entity representing the physical ground, the land easement. (The tracks cannot be there, or at least not usefully there, without the land easement for them to rest on.) It might or might not make sense to link the other way; in the example you suggest, should the land easement continue to link to tracks which have been ripped up and are not physically present any more? (Does or should an entity in such a status remain in the database?) I'm certainly not going to say this is and must be the correct way to handle this situation; it's first quick thoughts concerning the issue and how to resolve it and as such might be horribly incorrect given more knowledge of the database and all. But, at least to this naive and ignorant person, it's not obviously and completely and immediately apparent to be wrong, at least at a first surface look. Certainly where roads are rerouted they can either be dragged from their existing path to the new location, but my point is exactly that the information that there HAS been a change of route is as important as the fact that it changed on a certain date. It's modelling this information that is missing currently and while some people would rather simply wipe the prior route out of the history books, even just moving that already mapped information to OHM requires a little more consideration. Delete is simply not a valid concept unless the object never existed in the first place? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
Martin Koppenhoefer wrote: 2013/12/7 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk Delete is simply not a valid concept unless the object never existed in the first place? While I find this concept appealing at first glance, it would raise complexity much more if we not only had present but also past objects in the db. We had a mapper in Germany (Mirko) who has mapped underground installations and old road infrastructure in that area that afterwards has been restructured. The density of objects (namely a second system of ways that wasn't in any way correlated to the current ground) made editing in this area much more difficult than without these objects. If we want to be the map for everybody we also have to take care that complexity remains on a level that you can contribute even if you are not a full-time mapper or have studied OSM 1+2 at college ;-) Which is exactly why the 'start_date' and 'end_date' become important elements. Rather than simply wiping those historic layers they get an end date, and the editors simply ignore them unless one has enabled a date range. This then replaces simply deleting perfectly good data and instead hides it away properly. The original proposal was that this data would get moved off to OHM, but that simply does not work when the bulk of the surrounding data is still required from the OSM version. I can see the 'need' to plot things like war campaigns on a second database, but the sort of historic data we are talking about here on the whole is closely linked with the rest of the live data and creating a 'date' slider to display an area over time would require a complete copy of the main database anyway? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 'Allowed data'
Russ Nelson wrote: Which is exactly why the 'start_date' and 'end_date' become important elements. Rather than simply wiping those historic layers they get an end date, and the editors simply ignore them unless one has enabled a date range. This then replaces simply deleting perfectly good data and instead hides it away properly. The original proposal was that this data would get moved off to OHM, but that simply does not work when the bulk of the surrounding data is still required from the OSM version. Yeah, OHM doesn't work, not when railbeds get reused as hiking trails, as some of the Dunderberg railbeds have been, and when the trail gets rerouted onto railbed, as the R-D trail has been. I was looking for railbed off the trail, and found old Red Dot blazes instead. As a simple starting point, it is a fact that much of current history is being mapped and then destroyed! I have been adding roundabouts and new housing developments which involve 'moving' roads that already exist and renaming them. In these instances we have the historic versions already recorded ... just no means of tagging the older versions with the real facts? Some people have no interest in even adding buildings to the data, but as a first step I'm talking about simply retaining the data that we are NOW gathering. I don't think it's unreasonable to guess that 99.9% of that data only needs a start date to then be a complete historic record? YES a small percentage of material is a lot more complex, and developments get started, and evolve beyond what was originally planned, or abandoned. That material may well be a candidate for OHM? Yes once one digs deeper into the life of an object there is a lot more history each element of which needs start and stop dates, and my own 'day job' involves that fine detail, where essentially every 'tag' has a created, start end date. In a hundred years time the current view of OSM will be history, both because data has yet to be recorded, but also because that data has evolved, and it is simply recording that evolution correctly which needs to start now. There are people who will want to add the history going backwards, and that is just another aspect, but it only requires that the mechanisms are in place to correctly manage the data going forward? The existing data is already an historic record if only we could get at it easier? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] NYPL / map-vectorizer - An open-source map vectorizer
Gregory wrote: Although I'm not too impressed with the example picture on the blog post. Ditto Gregory Quality looks similar to the digitization of pdf plans in France. The raw outline may be vaguely useful, but a lot of fine detail simply gets lost? The digitized versions may be useful as sources for details to be manually copied, but fully automatic importation is to be avoided! As with the French data, and a lot of third party data, the main problem when working with an historic view is combining objects which are the same between different maps. Has a building shape changed because it's a new building, or has had an extension for example. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSRM-talk] R: Re: problem OSRM compilying
marcos...@virgilio.it wrote: Hello, thank you for the answer, but I don't understand how to install the package you said, what I have to do? Sorry but I have been using Ubuntu only by a little. marcosi66 I've been using Linux for some considerable time now and even I have problems with this one :) But my problems are mainly because of the Linux setup I'm using. http://www.cyberciti.biz/faq/find-out-if-package-is-installed-in-linux/ is a useful crib sheet, but I'm on the second half so I can't test what you will see ... dpkg-query -l 'lua*' should give you same output as Stephen ... I think ... it will at least say if the packages are installed. I had trouble myself with the lua side of things on SUSE -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ OSRM-talk mailing list osrm-t...@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSM-talk] Street cabinets
François Lacombe wrote: For electricity, we do have power=cable_distribution_cabinet but IMHO it's definitely to specific. It would be replaced by man_made=street_cabinet + street_cabinet=power_distribution (+ operator=* + ref=* if applicable) Sounds a very reasonable expansion allowing finer detail to be recorded. And obviously there are traffic control, road lights and all other public facilities. Certainly traffic lights have similar street furniture ... In France, we have kind of postal boxes where a postal service employee deposits letters as for allowing a second person to distribute them later. We have the same thing in the UK as well ... This should probably be in the tagging list ... but I'm probably not alone in not having even joined that :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
