Re: [OSM-talk] Roadmap for deprecation of name tags in OSM
On 09/08/2020 09:42, Mateusz Konieczny via talk wrote: Aug 9, 2020, 10:25 by pang...@riseup.net <mailto:pang...@riseup.net>: I suggest we create a roadmap for deprecating of storing and updating names in OSM for objects with a Wikidata tag. Absolutely no. tagging name tag is a fundamental part of OSM tag, offloading it to a third party service is a mistake that will not happen https://josm.openstreetmap.de/ticket/19655 contains several misleading, wrong, mistaken and problematic claims, statements and implications but I have no time to process in detail as the entire idea is fundamentally bad, mistaken, problematic, broken, not workable, not acceptable, not going to happen and wrong. Seconded ... However sensible LINKING to third party services does make sense such as with geonames which already has services linking back to OSM ... geonames is a useful source of local time data for example. -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On 24/05/2020 23:45, Mateusz Konieczny via talk wrote: There are also many roads signed as "No HGVs except for access." It is tempting to tag them as "hgv=destination" but that doesn't cover the case where you are allowed to follow that route for many miles and make several turnoffs IF you "need access". The current definition of "access=destination" doesn't allow routers to distinguish between truly "first/last segment only" and "its fine if you are going to/from this general area". AFAIK this awaits solution, at least I am not aware about even a tag proposal. A delivery driver following a drop list may have a drop on that road, and then go on to their next drop out of the other end of the road. In fact it may be that the road is impractical for the vehicle to turn around. The 'legal' restriction is to prevent lorries using it as a short cut through a residential or similar area and physically it is perfectly practical for the biggest legal vehicle. The router can simple avoid that road if there is no stop on it, but the tagging should ADDITIONALLY indicate if it is physically possible to get the vehicle to the destination so obstructions such as tight corner, overhanging buildings, weight restrictions and the like will prevent some of the examples of lorries blindly following their sat nav without their brains in gear? It is the routers problem to pick the best route, which may be to approach the destination from the other end and perhaps even indicate 'back up to destination' ... now that WOULD be an intelligent router ... but if there is no information on which to base that decision even the driver has to guess. -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] our Q&A site help.openstreetmap.org is dying
On 20/05/2020 20:32, Frederik Ramm wrote: Not copying past answers, at least the last two years or so, would mean we'd have to write all these answers again because the questions will inevitably be asked. I'm with you on that ... I've seen far too much material simply ditched because it been to difficult to 'recover' it after systems stopped working. So where would I head to get my hands on an XML dump of the current data to see if I can push it into the copy of Q2A I've just set up ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] our Q&A site help.openstreetmap.org is dying
On 20/05/2020 08:28, Tobias Wrede wrote: The site is based on OSQA, a software which has not been maintained in some time. Some application errors have surface in the past but had to be ignored since no fixes are coming from OSQA any more. Until now we could live with that. They were annoying but not critical. There are open tickets on OSM github to move the help site to some other framework (https://github.com/openstreetmap/operations/issues/149, https://github.com/openstreetmap/operations/issues/377) but there isn't exactly an abundance of volunteers to take care of that. Question2Answer looks like it's being well supported. At least it has a release that works on the latest PHP and while it's a little long in the tooth, https://github.com/jamesspittal/osqa-q2a offers a hope that there is potential to pump existing material across? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects
On 25/02/2020 23:39, Alan Mackie wrote: Vector tiles that prefer either the browser's requested languages or something selectable would be ideal, but we aren't there yet technically for the main 'editors map'. When we are it might be worthwhile revisiting this discussion. There are complaints about what language to use everywhere. Even such a fundamental part of the infrastructure as 'timezones' has an ongoing debate about just how to spell the ENGLISH name of some identifiers and there has been a growing push to simply drop the 'names' and use abstract references so close the discussion once and for all. The argument here HAS been a problem since day one, and I remember discussions on converting tagging to use ID numbers rather than names ... what ever language they are written in. Just as with timezone identifiers, many of the text strings used can be 'translated' into any language one likes to DISPLAY them, and what has always been missing is a part of the API that simply allows one to select the language one would like to see ... and something which vector tiles could easily support ... but just as browsers still have problems with the simple stuff like returning a clients ACTUAL timezone (time offset as ALWAYS been the wrong information), the basic simple steps have never been defined in any standard? That the current 'map' is missing names for many graphic objects is just a matter of who controls the style sheets. Personally I prefer the French tile sets over the main version and have to accept that road colours are wrong. None of that affects the flexibility that the raw data provides, although a nice 'United Kingdom' colour set on OSMAND is still on my own todo list, and the vector maps THAT produces have potential to solve many of the 'complaints' ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] BuzMap - Global Transit Map http://buz-map.com
Hello Mappers,I've been building this http://buz-map.com, there's a couple of read me's at the top. There are a stack of issues but this now looks eminently doable. My pitch on all this is that people like maps. Give people a map of a transport network and they will follow the wiggly lines. They will notice that an island has a connecting ferry and a bus network (see Estonia). Envisage mountainous and wilderness areas and their transit geography more easily (see Sweden). Be able to scan an entire metropolis network to it's extremities without having to use trial and error (see Paris, Prague, Petersburg, Athens). And generally be intrigued and want to zoom in and discover. I am not having much success evangelizing this view with regard to a global transit map. If I can get this to a production state with all known GTFS, and sex up the high level areas that have no listed transport with a much deeper road network than you normally get at higher tiers, we will at least have the "intrigue me" travel map that I personally want. Obviously I haven't got very far with the front end. In particular it's not interacting very well on mobile, it's lousy in fact. I need help in any way shape or form available but if anyone knows how to get a thin line to interact in Leaflet on mobile, please suggest. I did try to paint a massive invisible one on top but it didn't work and I got nowhere with the debugger, so even help with that would be appreciated. I also want to do funky stuff like flipping the railways or buses to the foreground on touching. In a dense centre of a metropolis, being able to flip the metro or tram network to the top is already an important requirement. The Mapbox stuff does this but I haven't sussed the layers within tiles stuff and how to do it yet. I've got a game plan to fix most of the other bugs, especially in the rail routing which is quite screwed right now once you zoom in. I will get the whole of the visible GTFS world on there, so all of USA that's available, and anything else that I can find. It's going to take a few months, probably most of the year including downtime. I say visible GTFS, as oppose to existing. There is an awful lot of bus data that patently exists as it's in booking engines, and in GTFS form if it's on Google, but isn't anywhere easily found. What I want to investigate is to use the reduction method I have to draw efficient level 8 to 1 vector tiles of simplified road networks. So you can look at say all of India, US, Canada, China, Russia, Brazil or any area of that size, and get a decent view of the national road infrastructure even if I haven't got any bus data yet. I still will need to do some of the same simple reduction used for doing the detailed lower tier standard rendering of levels 7-16, i.e. filter road classifications down once it becomes an unavoidable mess even with reduction, leaving only motorways for the top two or so tiers. I think we will get a usable, readable and "representative" map of these upper layers, which by default are either road light or completely vacant. The bus network I have in Europe, which is just a tiny subset, is messy at the high level, I will try to refine it, but the trains work, so I am sure motorways will too and we'll tune in the lower road classifications and with appropriate clustering radii as we proceed down the tile tree. Any input gratefully received. Apologies for the spam of three lists, please respond directly unless it's something of interest to more than just me. Also I am in contact with OSM folks, I know I am using free tile servers. How we run this as a public self funding service is one of the many things I need help with. It seems an obvious gimme for anyone selling bus tickets but it's not easy to get anyone to pick the phone up. I have resigned myself to having to build a production system in between doing not a lot. Mark Lester ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] handling street names in speech
On 17/07/2019 08:29, Jo wrote: Unfortunately TTS is not perfect and it never will be, for one thing because it's often difficult to decide with TTS (which language) to use for each word in a name string. For many years I used a TTS engine called Rhetorical on a caller management system we supplied. It was used to allow calling people by name rather than ticket number ... we will ignore the privacy debate ... there was a general consensus that at that time the personal style was better. The nice thing about Rhetorical was that even without any help it did a better job pronouncing foreign surnames and some of the staff did ;) It also had a very good mechanism for adding improvements to words when there was any particularly obvious mispronunciation. In addition selection of a different 'output language' worked well, possibly because the company involved was based in Scotland, and the clarity of Scottish pronunciation worked well. We had already had to re-work the older 'English' segmented announcements using a Scottish voice because of complaints ... but perhaps the main point here is that this was providing THE SAME English text! Rhetorical was bought up by an American company and essentially dropped, but I think CereProc is using the same engine and a large range of 'voices' are available on Android ... if only OSMAnd could access them :( Text to Speech rendering is exactly the same problem as tile rendering and adding tagging for particular processes will always be wrong. The real problem is that there is no mechanism to add corrections in a secondary system in much the same way as there is no translation system for the key English elements of the data. Even IPA strings depend on the context and accent that is being vocalised! -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ways divided by paint?
On 04/07/2019 15:24, Mike N wrote: What if strictly following the rule of "no split ways unless physical divider" results in wildly incorrect turn-by-turn instructions? I have the same problem with the right turn lane being removed from https://www.openstreetmap.org/#map=19/52.11366/-1.94141 ... one can transition from the A46 to the A44 heading north WITHOUT having to stop for the roundabout. Because the only separation IS a crosshatch area the slip road has been removed but there is NOTHING to indicate that this slip road even exists by any other tagging! Unless someone has an 'approved' way of adding it back? Personally I think that micro-mapping complex junctions does require multiple ways even if the planned routes through a junction can be abused by taking the wrong path ... -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Documenting controversial iD decisions
On 29/05/2019 01:10, Clifford Snow wrote: Why should one editor be held to higher standards than others? Shouldn't they all be held to the same standard? As someone who still fights to keep potlatch2 working locally then yes all options should be judged to the same standard, and there are defaults on all editors that simply don't work or contradict what another editor 'defaults' to providing. Invariably I end up on 'advanced' so I can override choices given even in potlatch2. The 'standard' should be the current tagging guidelines and NOTHING should prevent an editor from adding changes that ARE still evolving. lifeguard facilities are a good example of the sort of additional detail that is still developing. So being able to add that detail is important even if it needs manual assistance. NO editor should enforce it's own restricted view of tagging here. I'm still of the opinion that what I will call 'primary' keys should be more regulated, and that the API provides the standard for key elements like highway and building. highway=platform is a key element of my view of the data and simply extracting 'highway' should give all of the key material for moving around the world ... along with waterway although in my mind navigable 'waterway' elements are simply highway as well along with railway. So fragmenting all these across other 'new' detail tags is simply wrong in my higher level view of the data. Pedestrian areas linking between road, rail and water transport DO need a little more consistent tagging as it is not at all easy currently to decide just what IS a correct set of tags to cover all pedestrian areas? It should not depend on which editor was used to create the data :( -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Update email address not working?
Some time back I changed my email address, but missed that the confirmation email never actually happened. Just tried to post and of cause the new email address got bounced to moderation. Checked my profile again and have twice had the messages about watching for email, but as yet no email ... where next to fix this? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Remove validation rule asking to add highway=footway to railway/public_transport=platform
On 24/05/2019 09:27, Wiklund Johan wrote: As a frequent mapper of public transport features, I agree with the opinions of Markus. Adding footway to the platform serves no purpose but to please poorly built routing engines. Same here ... Routing for rail passengers should be handled correctly by the routing engine as it's separate from 'public right of access' and access to platforms is an additional area that requires management separate to simple public footpaths? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared
On 09/05/2019 23:21, Michael Reichert wrote: JOSM runs its validation rules only on objects modified or created in the current session. This seems more sensible both for experienced users and newbies for two reasons: - Uses don't get overwhelmed with dozens or hundreds of reports on objects they did not touch. - If users follow suggestions how to fix blindly (we cannot expect an unexperienced iD user to have the same knowledge as the average JOSM user), they are used as living bots running validation rules on randomly selected areas of the map. One might call this a hidden automated edit. Been some time since I put buildings in, but surely the the right way to handle ADDING a square building is just to select 'box' and position 2 diagonal corners? With the logic picking up the adjacent corners of another square building? This is a drawing problem rather than something that gets tagged to sort out later? A row of houses simply square off an existing wall. Editing a block of building drawn as a single block to provide individual units needs the right tools rather than some tag saying 'this block was not square last time I drew it'? -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- Lester Caine - G8HFL - Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] We're erasing our history in wiki
On 22/04/2019 11:45, Ilya Zverev wrote: It’s history. Ilya ... it's the same problem we have with with a lot of the historic material. Personally I'd prefer to see the history accessible in some way, be it the history of the development of a area of mapping data, or the history of how we got to a particular style of recording that data. The data is in reality not totally lost, all that is missing is some general consensus on making it visible when appropriate. There has been a request for 'namespaces' in the wiki to help manage such things as the historic discussions on how tags have evolved and why some have been rejected. I'm not sure that it is the appropriate way to manage it, but an historic time line view of wiki pages is something that would not require 'manual management' and with a switch to display or not deleted pages would fill the gap? People investigating a particular tagging development could then see the past history of related pages. Doing the same with the map data is somewhat more difficult, but I still think it's a development that would replace the need to marry OSM with OHM for material that is substantially linked to current live data? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMF makes a political decision where should be a technical solution?
On 22/11/2018 18:53, Victor Shcherb wrote: In that case I would actually support idea of deleting all country boundaries to avoid this question completely. There are numerous sets of data within OSM that are disputed and one 'controlling body' or another would prefer was not published at all. The best that can be done is for local displays of that data to provide local filters. Simply deleting data is never going to be the right solution, but allowing tools that censor the data is equally controversial. For the point of view of OSMAND, the display needs to know where one can drive and where one will be stopped and need paperwork to proceed. THAT in my book is the simple ToTG because it is flagged by something physical. That some areas don't actually have 'border posts' does create a problem, but as an 'outside visitor' to the Ukraine or Cyprus, where can I drive and where could I run into difficulty if I do drive into a disputed area. It's the grey areas that are something that will cause problems and may require projects like OSMAND to censor data based on the user view? I doubt that OSM services are really able to manage this area in a generic way? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Plus code grid service
On 19/11/2018 17:16, Rasťo Šrámek wrote: A plus code is not intended to have the same function as latitude and longitude. It is intended as a replacement for "street name, house number" address parts where those don't exist and cannot be reasonably created. If you write Firstname Lastname WF8R+H6 Praia Cabo Verde on an envelope and drop it off at your local post office, wherever you live, it will be delivered. As long as they know just which code system you are using. This is just another in a long list of 'postcode for no postcode' areas. Have any of them actually gained traction on the ground? -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Really heavy browser load with Overpass-turbo map display
On 24/09/2018 20:36, Dave F wrote: Switching to an older version of a browser isn't neutral and raise security considerations as always. Usability is the same & 61.0 works OK & is only 2 months old. Personally I wouldn't rely on browser security. There are a number of problems resulting from the major surgery Firefox recently went through which are only slowly getting fixed. It would have been much more sensible to maintain the original build in parallel until more of the core functions and disabled extensions were made functional and compatible. I'm still struggling with the lack of Firebug as the replacement has problems with font sizes at least on linux and does not provide some of the nice features Firebug STILL provides on my development machine. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Representing places with no housenumber
On 23/08/18 10:16, Mark Wagner wrote: As a rather extreme first-world example, the address of https://www.openstreetmap.org/way/132723167 is: name=Grand Canyon North Rim Lodge addr:city=North Rim addr:state=AZ Not only does the building not have a house number, house name, or other house identifier, the road it's on isn't named either. When there's only one road in town, and that road only has one building that receives mail, you don't need much in the way of identifiers. But I see nothing wrong with that. MANY places the name is also the building name ... I don't think anybody is saying there HAS to be a building number and if they are then THAT is the error. Many rural buildings simply have a name which in the case of the UK gets listed in the PAF file and I would simply expect 'Grand Canyon North Rim Lodge' to be the address if USPS had a similar postal address listing? I find the practice of adding ANY tag that does not enhance the data as pointless. There is no need to TAG that there is no number ... you just don't add the tag ... just as the example here ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=* + area=yes vs area:highway=*
On 11/08/18 07:02, Andrew Harvey wrote: > No, all highways are areas :) Mapping them as a line is a manual generalization ;) Yes, but you're mapping the road centerline, which isn't a generalization but a real world feature. Mapping the path of a highway as a 'way' is a generalization. This can be extended by adding additional tags to describe all the fine detail such as width, number of lanes, associated cycle and footpaths, and so on, but this is a simplification to the actual fine detail. I'll repeat what I said, 'highway' SHOULD only be attached to a way and not to areas so that we have the simplification for lower resolutions of the data. ADDING areas to map the fine detail that is associated with the information also contained in the additional tags should be tagged by association and not by adding additional 'highway' tags to the areas. IN THAT CASE area=yes could be used to identify that there are associated area objects that can be used on higher resolution mapping. I don't think 'area:highway=' has place especially where the 'centerline' way is used to combine several highway=xxx types such as road,cycleway and footpath ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=* + area=yes vs area:highway=*
On 08/08/18 11:49, Tomasz Wójcik wrote: As highway=footway etc. tags are set to "should not be used on areas" on Wiki, and mapping them in combination with area=yes is not documented at all and considered as wrong tagging by part of users, there is a key "area:highway=*" (133k uses at the moment). Part of users still map footway areas as a combination anyway, propably because it's rendered by default style. Due to our rules, that we shouldn't have 2 active tagging schemes for the same feature, so we should discuss this topic. I vote for area:highway=* key, because it's simpler, and it gives a possibility to show also street areas with crossings in the future. * Wiki with specyfications of a:h=* for certain keys: https://wiki.openstreetmap.org/wiki/Key:area:highway * TagInfo: https://taginfo.openstreetmap.org/keys/area:highway * area:highway=* visualisation: http://osmapa.pl/w/area As more and more detail is added to the data, the switch from 'macro-mapping' to 'micro-mapping' needs to be considered. There has been some discussion on park areas being 'footpaths where you can walk anywhere', so rather than creating multiple ways covering all combinations of access points, a pedestrian router would understand that they can enter and exit the area at any valid gateway. I don't know if any routing software actually does use this approach. Boats on lakes have a similar problem ... so at a macro-mapping level a waterway or highway can have a sensible reason for being an area. Switching to micro-mapping which is starting to expand, one has areas for each facet of a route. Footpaths, grass verges, roadway, private drives off the roadway across verge and path and so on. There is however no current method of converting all of these area elements into 'ways', so one needs additional highway=xxx ways to provide the routing information that provides the macro level view. So you do not want an 'area:highway=footpath' if there is a highway='road with footpaths' way that covers the same object ... -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] building=grandstand vs leisure=bleachers
On 14/07/18 07:23, Tomasz Wójcik wrote: Building=grandstand is not perfect for me, beacuse building=* tag suggest that is some kind of typical building (with walls, roof, etc.) and most of the OSM styles render building=grandstand like every other buildings, where you can go inside, which may be confusing with grandstands areas. On the other hand we have leisure=bleachers , when the "bleachers" word is propably used only in USA. What do you think about it? Many of these are a compromise, but I would expect more tags not less. The problem with these two are they span different 'domains' as a number of others do. A built structure is a 'building', and there are a range of structures covering seating, so grandstand, covered_seating, open_seating ... move the leisure tag to a more appropriate tag? In addition, many of these can well be temporary structures for a particular event but present for some time perhaps every year. -- 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] proposed mechanical edit - moving FIXME=* to fixme=*
On 03/07/18 13:21, Dave F wrote: Removes duplicated, reduces confusion, easier to search. A good Spring clean improves the database. I really think this fear of bulk edits has gone too far. I would probably ask just how many of the tags you think are duplicated? The point here is that there is no NEED for this edit, and it basically does nothing to improve the database. It simply hides this block of tags within the later larger bulk of 'fixme', when as has been said, if these have been around for so long they should be addressed. Miss-spelt tags being bulk edited is one thing, but 'FIXME' is clean and changing them just because you can adds nothing to the data. Get on an deal with them to remove them all together is the right tack ... -- 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] proposed mechanical edit - moving FIXME=* to fixme=*
On 03/07/18 09:28, Frederik Ramm wrote: On 02.07.2018 19:42, Mateusz Konieczny wrote: It would make development of QA tools easier as authors would not need to discover and implement support for this duplicated key. I think the downsides of such a large mechanical edit far outweigh the advantages. Don't forget that new FIXMEs will continue to appear all the time. Software should be able to deal with both. I'm with you on this Frederik. The correct fix for a 'FIXME' tag is to deal with it or remove it completely if no longer valid, and adding extra change events to 'fixme' only gets in the way of that. IF there is a general consensus that some tags are no longer acceptable, then the first step is to fix the API to prevent their use? Once the source of the problem is eliminated THEN address the historic data. Is there any case for not enforcing lowercase only tags? The fact that 'FIXME' and 'fixme' can exist on the same node just seems wrong in ANY case? -- 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] About OSM social implications and what can/should be displayed on the map (or not)
On 29/06/18 16:27, Carlos Cámara wrote: Second: The very foundations of OSM as a project are techno-political in terms that it was created to overcome the lack of certain geographical information about certain areas or topics. This is even more obvious in HOSM or the not-at-all-accidental use of open licenses from its very beginning. Yes and No ... 'the map' is NOT the project ... the raw data is. I find it difficult to use the current style of the SAMPLE map provided simply because it gets the road colours wrong now. So I'm using a source of map tiles that use a more UK friendly colour set. The bottom line is that what is displayed on the map is already in conflict with many uses ignoring adding any additional censoring. What SHOULD be done is provide our own versions of the map for our own applications, as wikipedia is doing with names (although I can't see how to access them). Whether something has it's own icon is not a political decision - everything should have an icon - but the PRIORITY of displaying should be a non-political decision - not censorship! Moving to a more interactive map would be a positive step, rather than the continual churn of 'views of what is important' on a single static map and I know the technology is there, just not the resources to generate 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] Please do not re-use old node IDs
On 06/03/18 10:26, Frederik Ramm wrote: Long story short, please don't do it - let the API assign you new node IDs to your stuff instead of building ingenious contraptions to recycle old nodes. The reality is they are not 'old nodes' simply nodes which are not currently visible. I think I know the answer, but should the API be able to accept these ID's anyway? In an ideal world, the previous now hidden data should perhaps be flagged when the ID is used? -- 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] Highway=trunk : harmonization between countries ?
On 24/02/18 20:49, Martin Koppenhoefer wrote: Every country may have different peculiarities, but the general concept is the same: a road usually restricted to motorized traffic, typically grade separated and distinct carriageways. We’re normally using British English in tagging but this doesn’t mean we couldn’t map things that don’t occur in the UK or for what they don’t have a word. I think the main problem is that there are well established guidelines for various areas on mapping data at both country and region level but in may cases even those rules do not harmonize. We need the several levels of highway that are currently accurately mapping UK roads, but other areas of the world do not need that degree of classifications ... so they just don't use the ones that are not appropriate ... ( And I am battling getting my computer working again as it was such as getting email replies properly handled on different lists :( ) -- 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] Highway=trunk : harmonization between countries ?
On 24/02/18 09:30, djakk djakk wrote: There is 2 « independant » things in the debate : 1) trunk definition - what is a trunk, a motorway-like road - based on physical characteristics- or a super-primary road - based on the importance ? Since the classification initiated from the UK, that is still the base and a motorway has restrictions that do not apply to a trunk route such as 'no learners'. In addition they were maintained 'nationally' while primary roads are a local responsibility. That was been muddied much as the idea that trunk routes are faster. For the UK the road structure is well defined and it would be nice to get back a rendering with the proper colours ( and a selection for that on OSMAND ) ... 2) wordwilde trunk definition ? - should we have the same definition all over the world of what is highway= trunk ? (value that are country-dependant are not that common, aren’t they ?) Since there are no distinctions in many countries there is no need to include truck if there are no such roads in a country, and perhaps for 'world wide' trunk gets rendered the same as motorway or primary? Only local rendering actually benefits from the distinction? Do any countries not have motorways at all? Certainly the current default rendering is useless for many of us anyway so we have to ue an alternate 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] iD news - v2.6.0 lots of new features...
On 23/01/18 09:37, Martin Koppenhoefer wrote: 2018-01-23 10:06 GMT+01:00 Lester Caine <mailto:les...@lsces.co.uk>>: Actually it's more likely to be the estate name so for my near by estate it is messy since I've ended up using 'housenumber' so that it renders better and the street is 'Weston Industrial Estate' as it appears with the postcode. https://www.openstreetmap.org/way/145295590#map=18/52.07347/-1.82250 <https://www.openstreetmap.org/way/145295590#map=18/52.07347/-1.82250> from my understanding, you should not use "addr:street" for the estate, I'd suggest "addr:place". NO ... the postal element "addr:street" is 'Weston Industrial Estate' so building a postal address from addr: elements needs that element. The adjacent road does not form part of the address. However larger estates with multiple roads will have the name of the estate separate. Using "addr:place" if it is displayed before "addr:street", but other uses of "addr:place" need it AFTER street. Construction of an address from addr: elements should be consistent but *IS* something that will have a different template for each country, and adding more addr: fields just complicates that template? This is what is currently not documented? I don't like the idea that addr:number could be a housename, there is addr:housename for this. My point here is to loose the confusing mess and just have "addr:number" and then -> addr:property might be an option, if you deem addr:place inappropriate "addr:property" is the expanded format of the number. "addr:place" is an area with multiple premises and "addr:property" is an individually identified unit of accommodation/workspace/storage ... for a UK address template addr:place comes after addr:street and before addr:town while the estate name would normally come before addr:street ... but a UK addr:postcode would provide all the addr:street and later elements, just needing a tidy property reference ... -- 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] iD news - v2.6.0 lots of new features...
On 22/01/18 22:27, Tom Hughes wrote: I wouldn't say unit is common at all in the UK to be honest. It's only really used for commercial units on industrial estates and things - you wouldn't normally see it in residential addresses like you do in many countries. For the UK all that is required is 'property' and 'postcode' and for an industrial estate property may be 'Unit X' and postcode provides the rest of the street details. Adding 'street' is a little belt and braces, although people asking for your details will ask for 'first line of your address and postcode' in which case the 'Unit X' may or may not include the street. Actually it's more likely to be the estate name so for my near by estate it is messy since I've ended up using 'housenumber' so that it renders better and the street is 'Weston Industrial Estate' as it appears with the postcode. https://www.openstreetmap.org/way/145295590#map=18/52.07347/-1.82250 does not want 'Unit' in front of the numbers, so should the 'addr:housenumber' now be changed to 'addr:unit' ... on one hand yes that would seem better, but I still think 'addr:housenumber' is wrong, and we should have 'addr:number' and 'addr:property' where 'number' would be the shorthand style of property reference ( and may even be a house name where not numbered ) and 'property' would be the expanded for. For 'unit' ... 'X' and 'Unit X' ... for office 'blocks' this may be something like 'B4A' for 'Block B, Floor 4, Office A' or something similar. Units on a storage site may well be more complex than just number. -- 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] Automatically generated changeset discussion comments by OSMCha
On 17/01/18 09:46, Frederik Ramm wrote: It's like clapping your hands to the supermarket cashier every time he/she prints you the receipt. I had to smile at that one. Reminds me off the developers lists where there is more traffic of the 'I like that' than actual constructive contributions. I think users should either be able to opt out of automatically generated changeset comments, or perhaps such changeset comments should only ever be generated to users who have actively opted in (the "review requested" could be interpreted as an opt-in even though it doesn't exactly mean that). Requesting the review of an edit should always be optional, but for new editors it should be a part of the process anyway. TAGGING a changeset for review should not simply be a comment. OSMCha should perhaps be pushing feedback to the contributor and ONLY to the database when there is a problem. Can we keep that hand clapping to a separate channel to the live data in the database please? 2) I've always been using the "changesets w/comments" line of the HDYC page to double check suspicious mappers. Usually a mapper with a ton of commented changesets was to consider suspicious, from now on this osmcha feature is going to add a crazy amount of positive/useless comments Could auto-generated changeset comments be marked as such, so that HDYC could ignore them or at least treat them as less relevant? We live in a world where much of the traffic on social media is automatically generated by a bot of some sort. Adding that 'feature' to OSM to improve quality should be part of the edit process so it informs a contributor at the time, not generating feedback later. And certainly as with any contribution, it should be tagged in a way that you KNOW just how it was generated, and can filter the 'social media' contributions from the 'constructive' ones. -- 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] What would make MapRoulette better?
On 21/11/17 04:02, Marc Gemis wrote: > I'll agree with Yuri that is has to be the choice of the mapper to > work in a specific region and not the challenge creator. I stopped using MapRoulette simply because it was taking me well out of my comfort zone ... -- 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] Woods vs Forests
On 02/11/17 10:34, Warin wrote: > On 02-Nov-17 09:21 PM, Lester Caine wrote: >> On 02/11/17 09:40, Martin Koppenhoefer wrote: >>> ONE tag to say what? You are still owing an answer to this. >> I think the problem is similar to the multiple areas problem. There are >> several layers of complexity so should landuse=residential enclose the >> whole area including the grass and wooded areas or should they all be >> isolated areas? Adding leisure=park within landuse=residential area just >> makes things even more difficult? Just what is a small area of trees? >> within the leisure=park or landuse=forest because it's not a >> natural=wood 'creation' ... it's something the planning authorities have >> requested as perhaps a barrier or simply as an amenity ... or has been >> preserved as it has been there for hundreds of years ... >> >> We need to build a proper hierarchy of LANDUSE into which more detail >> can be added if required? >> > If you want to tag the presence of trees then it is a land cover you > want, not a land use. Rather than natural= ? ... My point was that there should be an agreed non-overlaping set of landuse=tags ... landuse=agricultural for areas between landuse=residential or landuse=industrial where appropriate with the farm builds, yards, orchards, coppices, and other detail secondary tags to the landuse one ... rather than having to define every field with it's own landuse tag. Actually ... how difficult would it be to identify areas that don't have a boundary around them? I have always though it would be useful if one could fill in the gaps between things like landuse= areas. > The difference between a large group of trees compared to a smaller group? Size of the area is not relevant ... But adding landcover=trees inside landuse=residential is perhaps a better solution? But should a large park outside a residential area still be tagged leisure=park? To fill in the landuse coverage it should perhaps be landuse=park ... with wooded areas tagged within it. > What next - the difference between a large group of houses and a smaller > group? We can accurately every building cleanly that is not a problem! It's adding the other details of the development which is ... somewhat hit and miss? > landuse=forest does not mean there are trees there all the time, they > could be logged and later replanted. > > With landuse=residential there are no sub tags to indicate the kind of > houses there or apartment blocks, colours, height etc. > > If you want that kind of detail then map the physical houses with that > detail. > > You could do the same with trees .. map each one with its height, > species and genus .. I'll leave that to others... Actually the plans for the current local developments HAVE all of that detail. Not that I expect them to actually follow the signed off plans on the ground ;) But it does define the areas of the developments that are not covered with buildings, highway elements, private gardens and fencing. But again for consistency should the whole area be re-tagged residential from farmland, or the preserved wooded areas inside the development be tagged differently? One of the developments south of here has individual trees that have to be protected but they are less of a problem since they are individual objects. -- 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] Woods vs Forests
On 02/11/17 10:17, Warin wrote: > A botanic Garden contains lots of different plants, including grass for > the ones I have been to. > Mapping each individual plant with its species and genus ... no thanks. > I did map one tree though, just to be inconsistent. :) But there is nothing stopping the staff of that Botanic Garden adding all the footpaths, private areas, beds, features and so on if they are working to produce their own map of the site? In much the same way that universities and collages are mapping campuses in more and more detail. Some areas have considerably more detail than others depending on who is generating the data. It's Tomas's interpretation of landuse=forest and natural=wood which is a little at odds with others who would tag large 'unmanaged' forests as natural=wood ... we need perhaps two levels of tagging for macro and micro, rather than implying different interpretations on existing tags depending on where they are used? -- 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] Woods vs Forests
On 02/11/17 09:40, Martin Koppenhoefer wrote: > ONE tag to say what? You are still owing an answer to this. I think the problem is similar to the multiple areas problem. There are several layers of complexity so should landuse=residential enclose the whole area including the grass and wooded areas or should they all be isolated areas? Adding leisure=park within landuse=residential area just makes things even more difficult? Just what is a small area of trees? within the leisure=park or landuse=forest because it's not a natural=wood 'creation' ... it's something the planning authorities have requested as perhaps a barrier or simply as an amenity ... or has been preserved as it has been there for hundreds of years ... We need to build a proper hierarchy of LANDUSE into which more detail can be added if required? -- 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] Woods vs Forests
On 02/11/17 09:13, Tomas Straupis wrote: >> IMHO there are semantic implications in the key, as has been said many >> times, <...> > > And that is subjective -> nobody is wrong -> everybody is right -> > everybody thinks THEIR proposal is the right one -> this topic is not > settled for so many years -> I suggest doing a compromise and agreeing > on ONE tag. > (Compromise is currently done on rendering/data extraction side. > Nobody cares there about natural/landuse/landcover whatever. It's one > forest and that is it) > > The only other way is to use de facto situation - natural=wood and > landuse=forest - and forget this discussion. In terms of topology, the idea from some that 'landuse' only applies to land that is 'used' for something implies that large areas of the planet are 'unused'? A single layer of areas defining the current 'landcover' should be something that is managed even if that includes 'wood-managed' and 'wood-unmanaged'. The current historic situation has never been right but then so have other long-standing compromises in tagging. > P.S. And all I wanted was to talk about topology rules... BTW: here is > an example of topology rules in Lithuania: > https://wiki.openstreetmap.org/wiki/WikiProject_Lithuania/Topology_rules In terms of the UK, Land Use and Land Cover is well defined with a set of clear classifications https://www.gov.uk/government/statistics/national-land-use-database-land-use-and-land-cover-classification except they are not really THAT clear. In your rules #2 and #5 seem to be at odds? and in the UK classifications, just how do you define the wooded areas of a park ... which may or may not be 'managed' ... and are combined with 'grassland' and other natural or managed landcover. We can define landuse=park, but that park can have a lot of detail contained within it ... We are looking to render blocks of trees, grass, and other objects how ever created? -- 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] Adding wikidata tags to the remaining objects with only wikipedia tag
On 25/10/17 12:42, Andy Mabbett wrote: >>>> wikidata objects often don't say what they are about >>>> (besides the name), they are just a bunch of links to wikipedia articles >>>> in different languages >>> Once again, please stop making things up. >> I was replying to "A Wikidata tag is just as verifiable as Wikipedia tag" > Whatever you were replying to, the claim you made was - not for the > first time - false, as others have demonstrated. I'm with Martin on this one! As others have demonstrated, there are a number of holes in the way wikidata works which may be fixed over time, but 'just' using a wikidata reference is not 100% reliable. What *IS* nice is the fact that having looked up a wikidata reference, there may be further links to a number of data sources from which the data was downloaded but that may NOT currently include wikipedia pages that are useful to provide background information on object in question. It would be nice to follow a similar pattern when using any third party ID. One currently being worked on in the UK is the 'fhrs' database, and these references are being added to the identified establishments. BUT it would be nice is these were tagged ref:fhrs in the same way as ref:edubase was populated previously, and a link to the reinvent data can be created automatically. ref:wikidata should follow the same pattern where an object is a one to one match for the referenced page, but wikipedia tag should be allowed where the referenced page contains general information about the object ... as in the case of a link to an artist where the object is a sculpture. Until the wikidata id actually identifies the sculpture there should not be a wikidata entry. What is currently missing is a clean set of guidelines for using any third party reference? -- 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] Could we just pause any wikidata edits for a month or two?
On 18/10/17 05:14, Yuri Astrakhan wrote: > Lester, I agree with you that Wikidata should not contain an object for > everything that OSM may have. I don't believe there should be an entry > for every McDonalds on the planet, or for every artist's work that > someone may decide to include in OSM. But that's up to Wikidata > contributors. Lets instead talk about practical usages of our data. A good example, a list of every McDonalds on the planet is a job for McDonalds. Does that database exist as a freely indexed? I've not looked, but if all of the objects in OSM have an operator=mcdonalds:MCID then an automated bot can identify problems with that cross referenced list. With a growing access to these sorts of datasets a standard method of using them would be nice and I include using using wikidata feeds in that 'good practice'. > Here is a wonderful site I saw at a conference a few days ago. It lets > you plan your trip based on the places you are interested in. You can > visualise all sorts of places - cultural, religious, hotels, bars - > anything, and plot your course. And it uses Wikidata, images from > Commons, and Wikipedia text itself to describe the places. The authors > spoke at length how Wikidata tags in OSM has helped them build it, and > the difficulty they had in all sorts of "data voodoo" to figure things > out. For example, they often correlate OSM & Wikidata locations by > proximity, and try to guess if it's a match. They have done an > outstanding job making sense of our data, but I think we could have made > their job a lot easier with our communal data curation capabilities, and > also help others who may have similar needs. > > https://opentripmap.com/en/#14/40.7355/-73.9806 > <https://opentripmap.com/en/#14/40.7355/-73.9806> Nice example of cross referencing but it would be enhanced by links back to the websites of the various locations identified ... and this would also allow things like my daughter fell foul off recently ... she was in London and being 'vegan' went to a vegan restaurant ... which was closed short term for refurbishment. Road closures and other short term changes are not something OSM can really manage ... > You do raise an important point about 1:1 vs part of vs ... In order to > be useful in data processing by 3rd party, data needs to answer a > simple questions: does the linked Wikidata/Wikipedia represents this > whole object, or is it simply related to it in some way. Here, the 1:1 > is meant somewhat loosely - there are some cases when things don't align > perfectly, but that's a separate topic. > > If wiki* page is about that object, the consumer may choose to use > multilingual names, show a portion of Wikipedia articles in the user's > language, use Wikidata statements, and show images from Commons. Current searches on wikpedia for things like 'sculptors' and the location of their installations is somewhat difficult when there is not an english article. wikidata is helping to find other language references to subject or object, but in many cases currently 'commons' is still not well indexed into that mix. Not an OSM problem but one that holds up adding links easily currently. > If wiki* is only *related* somehow to the object, no such automatic > usage is possible. The link is still very valuable for the editors of > the map, but not as much to the data consumers. Examples include a wiki > article that has just a section about this work of art, or wiki page is > a list that includes all churches in the area, or describe a class of > these objects (e.g. brand) but not this object itself. Moreover, I > suspect our favorite tools like Nominatim would also be mislead if they > rely on Wiki* links that relate to the object, but not about the object > itself. After all, if the object is well known, it would probably have > its own wiki page, or at least a wikidata entry. Past 'bad' experience of wikipedia have not helped in my adoption of that as a repository of material but I think the sort of material I've had stripped from wikipedia in the past SHOULD have a safe home in wikidata. > Some translations are completely different articles? > > I'm not sure what you meant here. I have heard of rare cases when > unrelated wikipedia articles are connected to each other, but usually > those get fixed as soon as someone notices. Again ... wikidata by it's nature is probably helping to identify 'multiple' articles across the different wiki language bases. Again it's articles on artists that I've hit with different content where there is not an english version currently. > The problem I still see is that many of the items I am looking to > link t
Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?
On 16/10/17 05:24, Minh Nguyen wrote: > When a Wikidata item is modified to link to a Wikipedia article (or > Wikivoyage article etc.), the Wikipedia article automatically links back > to the Wikidata item. This is a software feature made possible because > Wikipedia and Wikidata are colocated in the same database cluster. No > bots are involved; this is unlike the process by which interwiki links > used to be maintained before Wikidata was introduced. > > When a Wikipedia article is renamed, it does temporarily get detached > from the Wikidata item because the task of updating the Wikidata item > falls to a process that runs asynchronously on a job queue. It isn't > possible for OpenStreetMap, as an external site, to automatically update > its wikipedia tags via the same mechanism. However, in principle, one > could write a bot that consumes Wikipedia's or Wikidata's recent changes > feed, looking for features to update. I'm not personally proposing to > run such a bot, to be clear. And one of the benefits of wikidata tags is > that such a bot would decrease in necessity over time, since Wikidata > QIDs are more stable. Minh ... I can see that there is potential to use the Wikidata QID's as a more stable path into wikipedia data. The way it is solving the problem of accessing translated versions of wikipedia articles is looking good, but I think it will be some time before it is totally mastered? Some translations are completely different articles? The problem I still see is that many of the items I am looking to link to are elements of an article rather than the whole article, such as the location of the works of a particular artist. At some point in the future wikidata may well have a complete index of QID's for every artist's work, but currently I don't have the time to add wikidata entries where they don't exist, so a link to the artists wikipedia article which may or may not actually list this particular work is second best and in many cases there is not even an english version :( Some bot then modifying that link out of context is not helpful and while the idea of 'nobot' flags may seem a solution, it's just adding another layer of complexity which potentially needs to exist for EVERY tag on EVERY object. Something I don't think should be allowed! This is just an example but there are hundreds of areas where the object being identified is part of one or more wikipedia article in one or more language, so the use of this data in the OSM dataspace needs to be managed by OSM and only a small part can be automated using the feeds from the wikidata bot's? Even if it is OSM bots that are doing the processing. The annoying thing here is that the hierarchy of places that wikidata provides could be useful to OSM searches ... but it still needs the likes of Nominatim and/or GeoNames to cross reference that data which provides an alternate secondary database. -- 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] New OSM Quick-Fix service
On 15/10/17 22:04, Frederik Ramm wrote: > You've built a query engine to work with OSM and > Wikidata and are pushing that relentlessly, to a point where the > decision of just how much Wikiadata linking we want in OSM is totally > taken out of our hands. Seconded ... personally I have still to be convinced that wikidata is an independent and reliable source, so will not be using it as a cross reference. It may well be that OSM needs it's own secondary database with the sort of cross references material SOME of which is slowly being added to wikidata but wikidata is an independent and unrelated project with it's own agenda ... -- 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] A thought on bot edits
On 02/10/17 15:13, Martin Koppenhoefer wrote: > Of course considering the big volume of editing activity that would > likely take place in the 'bot:' namespace in that scenario it might be > a good idea to put those tags into a separate database for efficiency > reasons. > > yes, keeping a lot of additional tags for a huge amount of objects in > the main db would still be a burden on everyone working with the planet > file or geographic extracts, so it seems logical to externalize the > bot-tags. But how would you link one db to the other? If people don't > see those tags (or only by request), their edits will erode the > information in this external db (e.g. by splitting ways, deleting and > redrawing parts, combining ways, etc.). What about versions, will there > be different versions of the same object in the main db and this bot db? > Is this a serious suggestion or just another way of saying there are too > many automated activities going on? There are many reasons for wanting unique id's IN OSM that can be used to cross reference external databases. Add to your list archiving historic versions of the objects, something that should be automated into OHM. So there should be serious consideration of the idea but what section of tags should be moved to a separate database? There is a good case for using wikidata to provide a higher level of hierarchy such as street names, and all of the place data that overlays that, so OSM only needs to use the wikidata namespace for all of that material. I don't think that the idea of 'bot' space actually fits into that model as it is the unique ID that is fixed and 'bot' tags either need to be accessible in 'mapping' space, or remain in the secondary data space. -- 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] Adding wikidata tags to the remaining objects with only wikipedia tag
On 19/09/17 21:03, Yuri Astrakhan wrote: > There is now a relatively small number of OSM nodes and relations > remaining, that have wikipedia, but do not have wikidata tags. iD editor > already automatically adds wikidata to all new edits, so finishing up > the rest automatically seems like a good thing to do, as that will allow > many new quality control queries. I would like to auto-add all the > corresponding wikidata based on wikipedia, for all remaining objects, > using JOSM's "Fetch Wikidata IDs". Yuri I'm going to wind things back in a bit here as the discussion seems to be widely disjointed. I think there needs to be a formal discussion as to just what secondary data sources are preferred when adding additonal data to OSM objects. Wikipedia is a useful secondary source for a vast range of material, but some objects in OSM will not be 'notable' enough for wikipedia to allow an article to exist, so an alternative mechanism is needed for those objects. wikidata may well be a suitable alternative, but the simple fact that a more detailed article for a wikidata object by not be accepted makes wikidata something of a problem as well. While wikipedia/wikidata provide a sort of standard framework for additional data, the primary link from an OSM object should perhaps be to websites specific to the object rather than the filtered wikipedia view of the world? Some of the tangential debate has been re ADDING links to OSM object that have not yet been tagged with something suitable, and this is where cross matching these items depends on the information already available on in the OSM tags. I have still to be convinced that wikidata is 'independent' enough to be a reliable source of cross-reference links, especially where other reference tags are already used. UK Schools we have added the reference from the schools database. I've not looked to see if a wikidata 'view' of that data is available, but I would not look to add wikidata id's in addition to the school id's - BUT the wikipedia reference has been added where the schools are notable enough to warrant an article. I WOULD only look to tidying these objects to ADD the wikidata id if one was also checking that all three elements are correct, rather than simply automatically adding them. Whilst I was processing that data during the UK group push on it there were often a lot of corrections made to get the right 'set' of data on a school object. While only a small number of objects were actually wrong, that is enough to justify needing a manual cross check of some sort. -- 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] Links from wiki* back into OSM
( Done it again ) On 28/09/17 11:57, Andy Mabbett wrote: >> I have found wikidata entries that don't have wikipedia pages and I would >> expect that but it would be nice to have confirmation that this is >> actual practice? > Yes, it is. for example this: > > https://www.wikidata.org/wiki/Q18983100 > > is the Wikidata item about an ornamental gate, made by a locally > well-known artist, which exists in OSM as: > >https://www.openstreetmap.org/node/2312982822 > > Never in a million years will it qualify for its own Wikipedia article. That is exactly the sort of object I'm talking about :) wikidata links to an image and the Artists page, but the Artists page does not link to the Gate back to the wikidata object. I would expect other data to be added to the notes entry on the Artists page, but https://en.wikipedia.org/wiki/Tim_Tolkien has no way to add the anchor for each object on his Catalogue? Moving forward, every artist's catalogue would be a list on wikidata and managed from that list? Another simple example from the wikidata walk through is the location of the headstone for Douglas Adams burial in Highgate cemetery. wikidata should probably have an object for that with links to Highgate cemetery and OSM could have a complete set of all gravestones on the site, or link to an external copy of that list. -- 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] Links from wiki* back into OSM
On 28/09/17 10:55, Andy Townsend wrote: > Obviously wikipedia/wikidata's rules for inclusion are very different to > ours (in some cases the opposite - wikipedia says "no original research > - please copy from some other source"). There are plenty of examples of > things that people think should be in wikipedia and aren't, and also > things that shouldn't be in wikipedia/wikidata (because they don't > exist) and are. While I'm not up to speed with the latest state of play on wikidata, I understand that it is a lot better at inclusion than wikipedia. My main complaint about wikipedia has always been that it is rather to 'elite' in the way it blocks articles someone takes a negative view about. I have found wikidata entries that don't have wikipedia pages and I would expect that but it would be nice to have confirmation that this is actual practice? In the UK taking an open source list and adding it to wikidata should be a starting point for things like say 'streets', but many of those objects do not need wikipedia articles, just an automatically generated page from wikidata direct. My own problem is that buildings on those streets add another order of magnitude of of objects and should every one have a wikidata id? OSM in many areas does have a large number of objects against which building details can be added ... such as the brand/operator/chain of the shop or service located at the property. In the UK, NLPG provides ( if it was open sourced ) a complete list of properties in the UK, and would be the best source for an accurate list against which to work. Add similar databases around the world and one can build a complete model of the whole world. Not something I think wikidata would want to duplicate fully? But wikidata could perhaps provide links to the other databases containing fine detail much like the NSG lists streets which are then used as the base for NLPG objects. On my day job I've got material that needs indexing, and more often than not there is no article on wikipedia or in wikidata and at that point I have a chicken and egg problem. Do I create a wikidata stub so I have the ID with which to cross reference ... do I add a stub wikipedia article ... or do I just manage things with my own id's. OSM only comes into the picture here in managing and displaying location data but it's the ID of premises such as birth, death and activity locations that overlay all the objects I'm working with. Premises listed on the UK national census are a typical fairly reliable source I'm working with daily ... -- 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] Fixing wiki* -> brand:wiki*
On 27/09/17 20:56, Yuri Astrakhan wrote: > That formed no part of the early discussions on how wikidata should > work? I bowed out when the discussions were going down a path I did not > find to be at all useful. The current offering is certainly a lot more > 'organised' than those original discussions. > > Getting the initial points across is always a process. Hard to get it > right from the start :) I hope we can progress in a more organized and > beneficial way. I've been working with data involving addresses and other material for over 25 years using relation databases, and I don't find many of the 'modern' approaches add anything to managing that data. > I WOULD still like to see a > storage model that allows third party lists to be managed and cross > referenced, but that does not fit the wikidata model. It is why I think > > 'another' cross-reference tool may be more appropriate with OSM and > wikipedia/wikidata simply being sources. > > I am not exactly sure what you mean here. What goals do you have in mind > that cannot be stored with the current system? I'm not sure that every third party source will want their data included in either OSM or wikidata. I have a large volume of data that I can't provide access to. I can currently access OSM via coordinates, but I would like to tie every National Street Gazetteer entry to the matching objects in OSM. wikidata should probably have an entry for every street in the UK, but since the NSG data is not currently public domain using this source is not CURRENTLY possible. Other data sources are linked using NSG references so mapping those to OSM objects allows that data to be used where it's licence does allow. Other countries have this same mix of open data and private stuff which is nowadays a manageable minefield from which the public domain content can be accessed. > THAT requires OSM to have a > 'unique id' one can use to cross reference though :( > > If a third party list has a list of OSM objects, any time a new object > is added or existing one is changed, that 3rd party list needs to be > updated. Generally you don't want that. Also, it would require a > substantial fundamental change to OSM data structure and social dynamics > - the "ID" would have to be placed above all else, like it is done in > Wikidata. The ID meaning should never change, and merging two IDs > should leave a redirect from one to the other. I doubt that can be > easily achievable. The whole point here is that any change should be easy to pick up. If a new bus stop is added to that database, a bot monitoring this will pick up the change and make the change available to other users. Similarly when a record is updated, and changes that affect the monitoring bot's target can be flagged. More and more sources are being made open access and using suitable data to improve OSM's quality should be something that is easy to manage. YES the current OSM data structure has a problem when adding this layer of management. A database like wikidata might be an option to provide higher level lists of objects, which can then be linked to bot's which manage primary data such as the NSG's update reports adding new streets and changes to location hierarchy. But I should prefer that this layer is part of OSM rather than a third party service. -- 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] Fixing wiki* -> brand:wiki*
On 27/09/17 19:46, Yuri Astrakhan wrote: > Lester, first and foremost, Wikidata is a system to connect the same > Wikipedia articles in different languages. The "read this article in > another language" links on the left side comes from Wikidata. Wikidata > has developed beyond this initial goal, but it remains the only way to > identify Wikipedia articles in a language-neutral way, even if a > specific Wikipedia article is renamed or deleted. That formed no part of the early discussions on how wikidata should work? I bowed out when the discussions were going down a path I did not find to be at all useful. The current offering is certainly a lot more 'organised' than those original discussions. I WOULD still like to see a storage model that allows third party lists to be managed and cross referenced, but that does not fit the wikidata model. It is why I think 'another' cross-reference tool may be more appropriate with OSM and wikipedia/wikidata simply being sources. THAT requires OSM to have a 'unique id' one can use to cross reference though :( -- 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] Fixing wiki* -> brand:wiki*
On 27/09/17 17:40, Andy Mabbett wrote: >> Not on a number of articles I've recently been looking at while checking >> out the CURRENT wikidata offering. I've not found wikidata id's on the >> wikipedia articles I looked at ... but wikidata does seem something I >> should perhaps reassess. > You not having found them does not mean that they are not there. > > teh only Wikipedia articles with no Wikidata ID are those that are > newly created. > > Otherwise, you will find the "Wikidata item" link in the left-hand > navigation pane (using the default desktop view) AH - so it's stripped when you grab a printed copy of the article :( There may be a link to Wikimedia Commons material, but not to wikidata material in external links ... that is where I expected to find 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] Fixing wiki* -> brand:wiki*
On 27/09/17 16:48, Andy Mabbett wrote: > On 27 September 2017 at 16:06, Lester Caine wrote: > >>> While it is not yet complete, in what way is Wikdiata failing to be >>> sufficiently reliable? >> >> Much of the work I did on wikipedia was stripped for all sorts of >> reasons. > > My question was about Wikidata's reliability, not yours ;-) My experience of 'wikipedia' is bad and so that colours my thinking about using wikidata! I know many of us who used to be contributors are in the same boat ... >> critically I'd prefer to see the wikipedia pages containing a link to >> the wikidata entry! > > They do. Not on a number of articles I've recently been looking at while checking out the CURRENT wikidata offering. I've not found wikidata id's on the wikipedia articles I looked at ... but wikidata does seem something I should perhaps reassess. >>> That is exactly what Wikidata is for. >> >> But has yet to be formally adopted by OSM ... at which point the >> wikidata id becomes the OSM unique reference? > > I've not seen anyone advocate that. Personally I'd prefer to see an OSM id I can use as an alternative to wikidata ... with a few links to other datasources without relying on wikidata. -- 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] Fixing wiki* -> brand:wiki*
On 27/09/17 14:40, Andy Mabbett wrote: > On 27 September 2017 at 14:28, Lester Caine wrote: > >> wikidata provides a section which documents a range of LINKS which >> identify the same object on other databases. It would be nice if there >> was a stable identity on OSM that would populate an entry in THAT list. > > Indeed so, but OSM does not, nor is it likely to in the foreseeable future. The current 'risk' is that the wikidata identifier becomes the defacto 'standard' for defining OSM objects, and then we have to create wikidata entries for new objects. In the past I did write wikipedia articles to fill gaps in the past, but when entries get tidied up by other editors, titles can be changed and we get broken links. At least wikidata id's are static ... hopefully. >> At some point it might be nice to eliminate all of the unnecessary links >> like this in OSM if wikidata or somenewopesourcedata become a more >> reliable source of such data. > > While it is not yet complete, in what way is Wikdiata failing to be > sufficiently reliable? Much of the work I did on wikipedia was stripped for all sorts of reasons. HOPEFULLY facts that exist will not be subject to the same arbitrary treatment in wikidata, but I don't have much confidence still to spend time contributing these days. I did not like the way wikidata was structured originally but it does look like the problems have been eliminated. We still need a lot more stubs replacing with real data? And critically I'd prefer to see the wikipedia pages containing a link to the wikidata entry! >> Just a single link to a substantial set of additional data. > > That is exactly what Wikidata is for. But has yet to be formally adopted by OSM ... at which point the wikidata id becomes the OSM unique reference? -- 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] Fixing wiki* -> brand:wiki*
( Thought I hit 'reply list' :) ) On 26/09/17 23:47, Yuri Astrakhan wrote: > Here is a query that finds all wikidata IDs frequently used in > "brand:wikidata", and shows OSM objects whose "wikidata" points to the > same. I would like to replace all such wikidata/wikipedia tags with the > corresponding brand:wikidata/brand:wikipedia. Most of them are in > India, but there are some in Europe and other places. This query can be > used directly from JOSM as well. wikidata provides a section which documents a range of LINKS which identify the same object on other databases. It would be nice if there was a stable identity on OSM that would populate an entry in THAT list. This would then allow cross checking of any link. At some point it might be nice to eliminate all of the unnecessary links like this in OSM if wikidata or somenewopesourcedata become a more reliable source of such data. Just a single link to a substantial set of additional data. So ... where does 'brand:' come from? Should this not simply be '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
Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag
On 20/09/17 08:22, Sarah Hoffmann wrote: >> If the Wikidata ID can be fetched automatically based on the Wikipedia >> tag, can we delete the Wikipedia tags from everything that has Wikidata >> afterwards because it is redundant? > As a reminder: the OSM search engine relies havily on wikipedia tags > to distinguish the important results from the unimportant ones. > > If you are interested in keeping a half-way functional search on the > main site, it might be a good idea to find somebody to implement > support for Wikidata IDs in Nominatim before you enagage in a mass deletion > of Wikipedia tags. While wikidata does seem to have come a long way and sort out a lot of the 'tagging' problems that it had early on, there would still seem to be a long way to go to use it as a general cross reference replacing existing data IN the OSM database? Perhaps when the wikipedia pages cross reference the wikidata entry? But currently one probably needs both references even if Nominatim was able to handle either. I followed the wikidata example of Douglas Adams and while it's a little thing, the same problem we have with OSM cropped up. Douglas went to St John's College ... I know he went to Cambridge, but OSM search gives Oxford first! Where ambiguous data exists it would be nice that a better title was used ... while links take you to the right place, it's an unnecessary step if one is just scanning the raw data? It took a couple of minutes to find the right location to see what data was in OSM for the collage and some material that has not yet made it into wikidata came 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 https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On 24/08/17 15:16, Andy Townsend wrote: > No idea what router you're using, but a common-or-garden Garmin satnav > using OSM data is pretty much bang on timing-wise for rural routing > around here. > >> - and get my blue motorway, green trunk and red >> primary road back :) >> > I don't think we're actually short of map tiles with those colours :) > The UK/IE ones that I create are like that, and many others are too - > either styles not updated since 2014 or deliberately chosen to look that > way. OSMAND on a Samsung S6 phone :) My old dedicated sat nav did a good job as well as handling hands free calls on the N900 mobile. Modern options are going down hill fast and can't even do the basics! Simple reception of a signal would be nice to have once again ... -- 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] Highway=trunk : harmonization between countries ?
On 24/08/17 13:15, Greg Troxel wrote: > I might experiment with a few roads. But people should not worry that > I'll do anything large scale (more than 30 minutes in JOSM, the unit of > editing :-) -- I agree this is complicated and not resolved. I view it > as an eventual step towards better routing. The starting point is the raw data in OSM ... but when something does not look right in using that data just where do you start? I know my own problems are mainly how the data is used and if I had more time I would look to adjust the assumptions to give a more realistic 'fastest' route for UK rural areas - and get my blue motorway, green trunk and red primary road back :) -- 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] Highway=trunk : harmonization between countries ?
On 23/08/17 02:38, Martin Koppenhoefer wrote: > b) situations where the posted speed limit is off the actual context, so > that nobody respects it and the police doesn't enforce it It's not helped when some people in the UK seem to think the whole country limit is 50MPH rather than just a few counties. Driving at 45MPH in a queue of cars held up by one slow one down miles of 60PMH road that are safe to do that speed on but no where safe to overtake makes something of a mockery of even posted speed limits. Took an extra 15 minutes to get home yesterday ... on a main UK trunk road :( -- 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] Highway=trunk : harmonization between countries ?
On 23/08/17 00:52, Greg Troxel wrote: > If I drag the start point NE just a bit it flips to the route you like. > > I don't have enough Copious Spare Time, but I'd like to see a way for > routers to export their estimates of time/distance per leg, and to match > that up with GPX, and essentially find legs with bad estimates, so they > can be looked at indvidually. This is more complicated because there is > intersection behavior, so I think it needs to have time for the middle > leg out of 3, or something that I haven't figured out, but still, one > should be able to ask "Did what the router said would happen happen". Time being the same problem here ... and finding OSMAND working differently every time I do jump into the car does not help :( I still keep trying to set routes as I used to and have to try and remember what the new sequences are ... I'm doing a lot less driving these days and only to established sites so the time even to fix things like road colours is not worth the effort. The A46 is a 'nice' test case as the main route has many poorly designed roundabouts and at some times of the day the whole Evesham area just grinds to a halt. Stratford is just as bad and the new roads planned will make things even worse rather than helping. We don't stand much chance of designing a harmonized routing process when the planners can't even fix the problems they create :( -- 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] Highway=trunk : harmonization between countries ?
On 22/08/17 20:45, Martin Koppenhoefer wrote:
> Generally it might be interesting to add a preference to routing engines
> ("I'll be going 20 more than allowed where possible")?
Actually that is a niggle with OSMAND ... it only allows a fixed over
speed amount before warning ... what it should be using is a percentage,
so 5% would be tidy and 10% pushing where a traffic camera would be
'within tolerance'. Since speedometers are only required to be 'within
10%' currently ... you get the idea ;)
--
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] Highway=trunk : harmonization between countries ?
On 22/08/17 17:19, Philip Barnes wrote: >> called differently, but this is it: >> https://wiki.openstreetmap.org/wiki/Key:maxspeed:practical >> > Isn"t that going to be rather subjective? And will depend on 'time of day' ;) -- 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] Highway=trunk : harmonization between countries ?
On 22/08/17 12:29, Colin Smale wrote: > I would like to take a closer look at your example route... Can you give > start and end locations? http://map.project-osrm.org/?z=11¢er=52.149501%2C-1.577225&loc=52.048797%2C-1.856918&loc=52.258912%2C-1.619625&hl=en&alt=0 43.4km 33min Dragged to normal route via Mickleton it becomes 32.3km 34min, but anybody who uses this section of the A46 will tell you that it's often stationary traffic even on the dual bits ... so the quoted times are simply wrong a lot of the time. To add to the fun Warwickshire has decided they will enforce a county wide 50MPH maximum overriding the national limit so some of the long straight sections we 'should' be slowing down while some sections of the A46 are 70, but the same 50 limit applies to other long stretches on the A46 as well ;) I have a smaller problem heading south to the M5 and again 'shortest' picks the quick route but then avoids the M5 as well :) Interesting ... checking OSRM is getting it right so I need to check OSMAND again on 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] Highway=trunk : harmonization between countries ?
On 22/08/17 11:41, Colin Smale wrote: > I agree, classification should be largely irrelevant to routing. > Routing needs timings from node to node, which are best derived from > bendiness, number of lanes, junctions etc and then capped to the legal > maximum. A four-lane secondary, primary, trunk or motorway will all have > the same effective speed in the absence of bends and junctions. The problem here is that most routing systems use the highway= tag as the initial key to defining the 'defaults' for a link and the delay elements added moving from one type of road to another. I am convinced there is a problem with the tagging of the B4632 which is preventing it from being seen as an alternative to the A46 10 mile detour but as yet I've not spotted anything wrong. Shortest routing will pick it up, but then avoids the M40/M6 for the next stage :( It's not just OSM routing that gives problems, other routing engines are showing similar detours around local 'shortcuts' ... so even within a single country harmonization is a 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On 22/08/17 11:16, djakk djakk wrote: > Lester, why the little "main road" was not tagged as a tertiary road ? The 'minor' roads are 'both secondary and tertiary' ... one example used to be the 'trunk' road A46 but is now 'secondary' B4632, so many of the routers using OSM data use the 'new' A46 which results in a 10 mile detour :( I was hitting the same problem in Wales! ... the main through route A66 is just that and not designed for local journeys. Selecting 'shortest route' often hits the 'single track' roads one DOES want to avoid ... > I'm afraid that you can't use speed_limit : on small roads, the official > speed_limit is not signed but follows the default one (90km/h in France > even on a lanes=1.5 road !). Single carriageway roads here are 60MPH out of town and 30MPH in town but I'm not sure OSMAND actually understands that anyway applying 20MPH limit to all secondary and tertiary roads? The routes I am talking about are tertiary roads with 40 and 50MPH speed limit sections ... I do add them in where I find them, but many were not showing in North Wales :( But I see no way to harmonization world wide. Even for just 'trunk'. The 'rules' for a country or area need to cover the differences that apply in that area? Just as the routing rules need to know France is Left Hand and UK is Right ... with different default speed limits. > Le mar. 22 août 2017 à 11:16, Lester Caine <mailto:les...@lsces.co.uk>> a écrit : > > On 21/08/17 21:09, djakk djakk wrote: > > Actualy, "highway=*" shuffles importance and characteristic of roads. > > May we add an "importance" key to roads ? > > Having spent the last week using OSMAND to navigate around the > Welsh/Cheshire border area (UK ;) ), the 'importance' of roads is > something of a problem even where the 'classification' of roads exists. > Same problem in my own home area. OSMAND treats lower and unclassified > roads as much lower importance when in many cases they ARE the main > local route and this results in poor routing decisions! Importance can > depend on why you are using the road? Things like 'speed_limit' need to > be handled before adding another 'classification' 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] Highway=trunk : harmonization between countries ?
On 21/08/17 21:09, djakk djakk wrote: > Actualy, "highway=*" shuffles importance and characteristic of roads. > May we add an "importance" key to roads ? Having spent the last week using OSMAND to navigate around the Welsh/Cheshire border area (UK ;) ), the 'importance' of roads is something of a problem even where the 'classification' of roads exists. Same problem in my own home area. OSMAND treats lower and unclassified roads as much lower importance when in many cases they ARE the main local route and this results in poor routing decisions! Importance can depend on why you are using the road? Things like 'speed_limit' need to be handled before adding another 'classification' 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] [Talk-GB] Coordinates in OSM. Really annoying
Looks like I fell fowl of another annoying 'standard' ... just how replies to an email list are handled! If only people would use the same standard everywhere ;) On 22/04/17 16:23, Dave F wrote: > In this context I'm unsure what you mean by "interface standards" Working from the bottom ... nik2img is a python application, so expects the list of parameters to be listed with spaces ... https://code.google.com/archive/p/mapnik-utils/wikis/Nik2Img.wiki it IS actually using the box parameter, but in python scripts this is --bbox mapnik supports several interfaces, and url style links prefer not to use the space character, preferring the comma to break up strings. Overpass actually comes with a number of interface standards and the comma string can be used in OverpassQL (but the wrong pigging way around ;) ), but the XML standard requires each element has it's own name. Osmosis is a java application and that brings another layer of 'flexibility' which requires every element of --bounding-box to be named ... and as with python each element is flagged by a space ... essentially similar to the XML rules but with different element titles. Each programming language has it's own well defined standards and there is little chance we will be able to change those, so we end up with wrappers which pass a coordinate set in the right format. http://osm.duschmarke.de makes a number of those formats available in parallel for those times when you may need to swap between languages ... > On 22/04/2017 15:45, Lester Caine wrote: >> On 22/04/17 15:28, Dave F wrote: >>> As they're parameters, the format can be standardised for the end user & >>> any programme should be able to sort out syntax behind the scenes. >> Totally agree except passing box="w,s,e,n" is STILL a matter of the >> passing mechanism the target application is built around. There would be >> no problem with the box selector simply providing the right input via a >> link to the target application, and a graphic interface providing a >> suitable 'box' into which to put the coordinate string into for GUI >> interfaces, but as I said ... the problem is the vast number of >> interface standards currently in use and not a simple one to solve for >> one piece of 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coordinates in OSM. Really annoying
On 22/04/17 14:19, Dave F wrote: > It's to provide the numerous coordinates format for each of the > programs. Select a boundary box (Alt+LButton mouse drag) & you get: > > https://pbs.twimg.com/media/C-BP_QdWsAEN-Ac.jpg > > I can't understand the need for the variations in syntax Not worked out how to stop 'ALT' moving the window so I could not see the results. :) Essentially there are two 'problems'. Overpass using different orders on the different API has been a problem with other API's, but the other 5 are all essentially the same and it would not take much for them to take box="w,s,e,n" as an alternative input. But the range of 'standards' for passing parameters is the problem here not simply what is being passed. With each OS and programming language having it's own style of working there is simply to many variables to create a single standard :( -- 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] Coordinates in OSM. Really annoying
On 21/04/17 15:34, Max wrote: > On 2017년 04월 21일 16:28, Dave F wrote: >> This is one of my OSM bugbears: http://osm.duschmarke.de/bbox.html > > Can't use this tool, because alt + mouse click moves the whole window in > my desktop environment. Shift/Mouse works to zoom but no idea what the tool is supposed to do :) -- 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] it may be useful
On 30/03/17 19:47, Lester Caine wrote: > On 30/03/17 18:38, Lester Caine wrote: >> Kind regards, Lester Caine > > *I* did not sent that email! Which is why it has another email address > since forging my own would fall fowl of my spf record! OK anybody know who to report 'The Brit Method' website to for forging other peoples details to spam via groups. SEVEN different copies of the same crap with my name on across a number of lists, and I see they are using other list members details as well ... I will not publish their real web address as that just plays to their tactics :( -- 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] it may be useful
On 30/03/17 18:38, Lester Caine wrote: > Kind regards, Lester Caine *I* did not sent that email! Which is why it has another email address since forging my own would fall fowl of my spf record! -- 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] OpenStreetView name change
On 08/11/16 18:54, Richard Fairhurst wrote: > FWIW, I like the "-scape" suffix, e.g. OpenStreetscape: Get's my vote Capital 'S' though OpenStreetScape -- 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] Which type of highways are used by routing software?
On 02/11/16 11:04, Milo van der Linden wrote: > As a devops I understand your pain ;-) but for OSRM, I found that using > docker and staying on a fixed docker version for OSRM makes the pain a > lot easier. You say you are using GPS in the car, do you also have a > OSRM server running in the car? And is this server docker-ready? Because > then I would strongly suggest you follow the instructions at > https://hub.docker.com/r/osrm/osrm-backend/ it works like a charm for me. OSMAnd can be switched to use OSRM I think, but that requires a reliable wireless broadband on the android phone, something that is becoming worse rather than better. Even driving down the M5 I get gaps in reception, so everything has to be local, which OSMAnd does a good job of for most things ... just not B/unclassified roads :( Docker is yet another infrastructure tool to get ones head around ... -- 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] Which type of highways are used by routing software?
On 02/11/16 10:07, Milo van der Linden wrote: > In OSRM routing profiles are scripted in lua files. I suggest you take a > look at them and see if they fit your needs. The current requirement is for something that actually works when I switch on GPS in the car. It's bad enough that the user interface seems to be different every time I NEED the thing - even having 'automatic update' off ...downloading new maps complains when the program has not been updated. I had a working OSRM service of my own, but I've not had time to rebuild everything to use the 'new' formats. Another distraction that was not really necessary? Just about every part of the current computing infrastructure seems to be subject to daily often pointless changes? :( I've just spent two days trying to get email services working again for clients because of breaks from the likes of yahoo and google ... just leave working systems alone ... -- 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] Which type of highways are used by routing software?
On 02/11/16 08:41, Paul Johnson wrote: > On Wed, Nov 2, 2016 at 3:00 AM, Lester Caine <mailto:les...@lsces.co.uk>> wrote: > > On 02/11/16 00:57, john whelan wrote: > > If OSMand etc treat them differently then we may not be showing the > > shortest route. > > OSMAnd currently does not use the best routes in any rural area! While > the roads even in the UK may be 'unclassified', in many rural areas they > are the main routes and I have asked before how this 'bug' can be fixed. > Reclassifying the road is obviously wrong, but similarly changing the > routing rules is wrong for other parts of the world, so it's not just a > case of which routes are used, it's how the bias is applied to those > routes ... and currently OSMAnd is simply wrong for the UK! > > > Try playing with the routing settings in Osmand. My part of the world > can get similarly obscure at the low end, but usually setting shortest > route helps. Unfortunately it needs a little more than just that. The end points need 'shortest route', but once one has avoided the - in my case 10 mile detour going north - one wants the motorway rather than the slightly shorter 'old road'. I have tried playing with the biases in the past but invariably they get reset by some update and I'm back to square one. So now I just take the 'b' roads and let the routing catch up later :) There is room for a more general discussion on standardising some of the tagging data along with the routing biases so that one can select a set of rules that best fit personal experience rather than having to try and live with less optimal generic rules? -- 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] Which type of highways are used by routing software?
On 02/11/16 00:57, john whelan wrote: > If OSMand etc treat them differently then we may not be showing the > shortest route. OSMAnd currently does not use the best routes in any rural area! While the roads even in the UK may be 'unclassified', in many rural areas they are the main routes and I have asked before how this 'bug' can be fixed. Reclassifying the road is obviously wrong, but similarly changing the routing rules is wrong for other parts of the world, so it's not just a case of which routes are used, it's how the bias is applied to those routes ... and currently OSMAnd is simply wrong for the UK! -- 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] What3words
On 13/07/16 11:44, Dave F wrote: > On 13/07/2016 10:03, Iván Sánchez Ortega wrote: >> If written/spoken language is the barrier, maybe we should try >> something more cross-cultural, like signwriting language. >> http://signbank.org/iswa/cat_1.html what3hands anybody? > > How about musical notation? We could sing our parcels to their > destinations. ;-) Or even more radical ... just use numbers for time and location :) -- 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] What3words
On 12/07/16 21:44, Paul Johnson wrote: > The way I see it, it takes a simple problem and tries to make it > simpler, but at the same time, as soon as you start talking about a > situation in which language commonality is not a given, the whole thing > makes you understand the simple elegance of latitude and longitude, > particularly in decimal form. Along with storing all times as simple UTC. W3W and OLC both have the same problem. They are trying to fix something which is not really broken. I'd commented in the thread about "Open Location Code should we support it?" that all these re-coding methods are just a second layer to the lat/long and that is something that the LOCAL client view needs to handle. The words used in W3W and the language used where places are included with OLC makes using either of them difficult for a 'Nomination' search. Even something as simple as identifying the local time given some sort of location identifier becomes unreliable when local variations of language and custom are added in. -- 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] Open Location Code should we support it?
On 11/07/16 20:58, john whelan wrote: > In Canada suite 201 would be understood to be 2nd floor suite 1 of the > building. Where did the name of the building come into it? Sub-building element of any addressing scheme. BUT OLC specifically excludes adding something like that ... unless they have changed the spec again? > Do you have > a suggestion for Africa that is less than a very long string of latitude > and longitude remembering that any encoding system would need to be > understood by both the person creating it and the person using it? > > Are you saying there is a better solution for encoding the co-ordinates? I'm saying that OLC is just one of many methods, and it is simply a conversion of the already stored latitude and longitude. The interface tools are the only element that needs to support any of these conversions. Nothing needs to be stored in the database. -- 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] Open Location Code should we support it?
On 11/07/16 19:43, john whelan wrote: > True but suite 201 followed by the location code should do the trick. I > was thinking not so much of sending mail in the UK so much as providing > something fairly basic to countries in Africa etc. and even in the UK I > would at least provide a location. The use of the Open Location Code as an alternative to a postcode by adding a building identify is exactly against what it was designed for, but there is no reason that one can't directly use the latitude and longitude anyway, encoding them to a short form if you want. Any 'recoding system' for the physical location can be used to display the raw numbers? But for readability, just as OLC does, one uses the town and country and simply provide a GPS location limited to that area. A bit like 'national grid' in the UK > Cheerio John > > On 11 Jul 2016 2:36 pm, "Lester Caine" <mailto:les...@lsces.co.uk>> wrote: > > On 11/07/16 18:12, john whelan wrote: > > I would basically give everyone an address in the world, its Open > source > > and as far as complexity goes the UK uses what is called precise > or the > > street number plus postcode which often is 9 characters and digits to > > uniquely identify an address so using ten wouldn't be that much more > > complex. > > For a UK address, the sub building name and building name can be up to > 80 characters to fit in the Royal Mail PAF record and building number up > to four digits. There are additional 'premises elements', and even some > of the thoroughfare elements may be additional to the postcode itself, > so 10 characters is never enough. > > Open Location Code lacks the ability to handle multi-story housing. It > only gets you to the apartment block. This is an area where OSM still > needs some more 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 https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Open Location Code should we support it?
On 11/07/16 18:12, john whelan wrote: > I would basically give everyone an address in the world, its Open source > and as far as complexity goes the UK uses what is called precise or the > street number plus postcode which often is 9 characters and digits to > uniquely identify an address so using ten wouldn't be that much more > complex. For a UK address, the sub building name and building name can be up to 80 characters to fit in the Royal Mail PAF record and building number up to four digits. There are additional 'premises elements', and even some of the thoroughfare elements may be additional to the postcode itself, so 10 characters is never enough. Open Location Code lacks the ability to handle multi-story housing. It only gets you to the apartment block. This is an area where OSM still needs some more 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 https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Failed water proposal reversal
On 21/06/16 22:44, Greg Troxel wrote: > I don't see any reason why this can't be > > landuse=reservoir [entire parcel that has the reservoir on it, or the > region that has "water supply area - no trespassing" signs, etc.]] > > water=reservoir [the water part] That makes a lot more sense than ALSO adding natural=water to the water area. If the area of water is covered we have man_made=reservoir_covered and no 'water' element. water treatment plant tagging is similarly erratic with waste having an assortment of tags and clean water not. water=reservoir may well part of a clean water supply and treatment site. The problem is not that water has failed to gain traction, but rather that the whole area is still a mess that can not easily be defined. Nothing actually flows well? Adding ... landuse=wastewater_treatment or landuse=water_supply wrapping man_made=reservoir man_made=reservoir_covered But then we have currently landuse=basin and landuse=pond so dropping the natural=water and rendering all water= as blue then the use of water on it's own does make more sense? JUST use water=reservoir water=basin water=pond man_made=reservoir_covered -> because water is not visible so may be landcover=grass over the top? But where there is navigation passing through the reservoir waterway=lock and waterway=canal makes the water version of those obsolete? There is no way 'water' will replace any of the waterway data structure given all of the secondary tagging to http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver and the like. But where lakes - natural and man-made - have navigation routes through many of the waterway tags also apply but this has been another area of discussion to map the actual routes across the water areas. -- 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] Failed water proposal reversal
On 20/06/16 15:38, Martin Koppenhoefer wrote: >> > Il giorno 20 giu 2016, alle ore 12:04, Tomas Straupis >> > ha scritto: >> > >> > My main point is to get back to reservoir/basin being tagged as "landuse" > > why would that be desirable? Basically landuse is a property of land, and > generally it's not very clear how to apply (it depends on the scale, and our > db doesn't have a scale). As opposed to this, mapping a reservoir or a basin > as a feature is much clearer, you don't have to worry whether you include > auxiliary stuff like the service road leading to the reservoir, or the > non-water-storage but legally associated areas around it to the feature (you > won't). The simple fact is that there is not a consistent structure for identifying 'landcover' on OSM and even natural=wood and landuse=forest make it difficult to decide what is naturally occurring and what is man made. landuse=reservoir is a lot more practical where at times of the year the majority of the surface area is exposed. That is a totally man made situation for which 'natural' does not apply. And when moving onto areas like marinas which take several forms including basins on the waterway system, including land elements as 'retail' or 'residential' and water elements as waterway tags as part of the Relation:waterway. But the overall area's landuse is marina even if we currently tag it as leisure=marina without any agreement as to just what area that should cover. It's the insistence that water only applies to natural elements which just does not fit properly, and man_made=reservoir while much more accurate does not fit in with a consistent landcover/landuse overlay? -- 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] Failed water proposal reversal
On 20/06/16 08:54, Tomas Straupis wrote: > Accepted by 16(!) wiki editors but ignored by thousands of mappers. > 5 years after acceptance according to tagwatch: > "new" tag usage > water=reservoir 79937 > water=riverbank 1085 > > "old" tag usage > landuse=reservoir 387793 > waterway=riverbank 293319 The very first check of a 'reservoir' may well fail. One does not tag an artificially created body of water as 'natural' and many of the 'water' extensions to natural=water directly describe man made features. And the Idea that natural=water should wrap what are quite clearly man made waterway features just reinforces that and while the effects are small, many parts of the world even 'coastline' is now a man made construction. But the 'tags' list is probably the place to open a discussion on this ... not that I bother following 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] OT: How do you read OSM Emaillists?
On 20/05/16 14:12, Hakuch wrote: > Hey, Iam currently using thunderbird to manage my mailinglists (most of > them are osm-lists). But Iam regularly peeved because thundebird lacks a > lot of useful features. For example, when I mark a thread as ignored, > new posts are still counted, even when there are no new mails for my > visible threads. > > However, Iam interested what you use to read the osm mailing lists? I > know nabble for example, but dont like it to use another tracking (?) > service. Arent there better Email Clients than thunderbird? I have to agree with some of your comments about thunderbird, and some of the quirks introduced over time are a pain, but I currently manage some 25Gb of email traffic going back 20 years and thunderbird is the only client that does not complain as well as providing fast local searches. What we do perhaps need is a more concerted effort to engage with developers like he thunderbird team and explain why some choices do cause problems. My own pet hate currently is I think related to your 'ignored thread'. If I have messages threaded, but hide some then the 'nice feature' that handles then as a group simply fails to display properly ... but here is not the place to be complaining :) -- 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] Guides to improve navigation data in OpenStreetMap
On 10/03/16 17:46, Philip Barnes wrote: > You will also need to consider bus lanes as well. Complicated by selective operating times and contraflow problems :) I got caught out by that going to SOTM at Birmingham ... OSMAND was telling me where to turn ... -- 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] OsmAnd financially rewarding mappers
On 04/03/16 11:06, Janko Mihelić wrote: > Paying mappers should have a very intricate web of defined jobs and > reviewers. Ideally, OSM Tasking Manager should be used. "Map all forests > and roads in this square, I review, and you get 0.1 bitcoins". Anything > less strict is prone to misuse. A mechanism that reduces entitlement for reverted activity is essential and I don't think the OSMANDLive process even acknowledges that. (and trim properly if you must top post please) > On 03/03/16 11:17, Marc Gemis wrote: > > If I understand the discussion on [1] correctly OsmAnd will reward > > mappers with bitcoins. The bitcoins seem to be paid via a formula > > based on the number of changesets you upload. > > > > I think this is a bad idea, (just like Jack Burke illustrates with the > > Dilbert strips in the linked topic). > > What do you think about this ? How should we deal with this ? > > http://osmand.net/osm_live#information seems to be the correct > information? Personally I would associate 'live' in relation to a > routing application to be live updates of traffic conditions, and I > could understand the monetising of that data, but this does not seem to > be addressing that particular problem at all? > > As someone actively contributing currently, while an income from that > would be welcome, I don't think this third party activity is helpful to > OSM! In the first instance I have no intention of contributing to > bitcoin since I think it's main reason for existence is to hid scammers > and until that secrecy is removed ... I will not be signing 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 https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OsmAnd financially rewarding mappers
On 03/03/16 11:17, Marc Gemis wrote: > If I understand the discussion on [1] correctly OsmAnd will reward > mappers with bitcoins. The bitcoins seem to be paid via a formula > based on the number of changesets you upload. > > I think this is a bad idea, (just like Jack Burke illustrates with the > Dilbert strips in the linked topic). > What do you think about this ? How should we deal with this ? http://osmand.net/osm_live#information seems to be the correct information? Personally I would associate 'live' in relation to a routing application to be live updates of traffic conditions, and I could understand the monetising of that data, but this does not seem to be addressing that particular problem at all? As someone actively contributing currently, while an income from that would be welcome, I don't think this third party activity is helpful to OSM! In the first instance I have no intention of contributing to bitcoin since I think it's main reason for existence is to hid scammers and until that secrecy is removed ... I will not be signing 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 https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile Server manual build 15.10 troubleshooting
On 04/01/16 05:16, Skyler F wrote: > Nevermind, it decided to work finally yay! Skyler ... have been following your efforts and totally understand the frustration ;) I HAD all of this working on an earlier build of SUSE having jumped through all the hoops, and I thought carefully documenting every step. Many of the problems are not so much with OSM but with the way every distribution adds it's own complexity to running essentially the same tools. Currently my own attempts at restoring the service have cost a lot of unpaid time ... service apache2 reload systemctl restart apache2 or what ever esentially running /etc/init.d/apache2 restart or what ever is replacing the init.d service Even running LTS servers in order to keep things working is not always the safest way of doing things as a recent exercise in porting a PHP application has proven. The PHP5.2 builds are running stable in production, but moving several years of data over to the 5.4 version takes time, and once converted, can no long be used on the 5.2 build. But while both are still available on LTS servers, both are end of life, and moving them to 5.6 introduces another incompatible build, and PHP7 messes things further. Python has much the same problem with Python2 and 3 needing incompatible versions of code, and while many projects stick with P2, pressure to upgrade resulted in a number of broken P2 projects over Christmas. Then add in all the other languages used to produce a working OSM setup! MANY of the tools listed on the switch2osm site are no longer actively supported by their originators, so we do need an overhaul of the whole process, but a reliable base framework does not exist and the diversity between linux distributions is making that more and more difficult. Personally Ubuntu is not practical for me as all my production servers are SUSE based, and when I have tried alternatives the subtle command line differences such as restarting apache catch you out at critical times :( And apache is perhaps not the best choice for production web servers anyway ... I HAD a working system which I was hoping to make live to produce a UK style service, but currently only the OSRM layer is working fully. I'm at the pink square stage on the tile server ... and need to pay the bills so don't have time to 'start again' with a new framework. -- 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] Fixing Starbucks Wikipedia Tags (Was Nominatim Weakness)
On 15/12/15 18:05, Eugene Alvin Villar wrote: > On Wed, Dec 16, 2015 at 1:36 AM, Clifford Snow <mailto:cliff...@snowandsnow.us>> wrote: > > My adding the wikipedia tag to the original Starbucks store... > > I disagree with this tagging. You only tag wikipedia=* if the Wikipedia > article and the OSM object refers to the same thing. The Wikipedia > article is about the company/brand and not about the original store even > though the article would certainly mention the store (as part of the > company's history). Just to expand this, a website URL should also only link to a particular branch and most corporate websites have a 'store finder' which provides that link. Certainly the wikipedia link should follow the same convention. The store link if well implemented will provide all of the extra data that some people think should be added directly to the database and the Starbucks finder is a particularly good 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: [OSM-talk] Nominatim weakness
On 15/12/15 16:37, Sarah Hoffmann wrote: >> Do end users want to find a coffee shop local to them or one >> thousands of kilometres away just because it has an extra tag >> attached? > > I sincerely hope not. > > Given that we have a simple data issue at hand here and that > the target audience of osm.org are mappers who happen to have > the knowledge and skill to fix data issues, one would hope that > a positive feedback loop unfolds and both the bad data > and the bad search results are gone in no time. I still consider that the initial problem is that there are two different requirements and only one selection option. Results far away are a little of a red herring, and a result of WANTING to find POI's that are not local so you can move quickly to that location. THEN looking for results filtered to that location makes sense. It is not any bad data, but simply overly wide results set. Add a flag for local/global to filter on the current window and the bulk of problems go away without thinking it's the data that is bad. Make the search 'only local' and add a note to search for the area first then one can do 'holland' then 'starbucks', but of cause the 'holland' search needs to be global ;) -- 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] How does one tag a business that closed and was replaced by something else?
On 14/12/15 17:18, Andrew Wiseman wrote: > In this case, two businesses closed and were replaced by a single > business that took over both buildings (they are adjoining.) How should > I tag this? I didn't see anything about closed: or former: on the wiki. If the units are individually identified simply re-tag each with the new name. While some people will say 'historic data does not belong', the change record for each building will retain the history. If you delete each and create a new single building a lot of history which IS recorded will be lost. At some point the two units may split again. I presume that both already have their own address entries 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] Nominatim weakness
On 14/12/15 09:00, Maarten Deen wrote: > IMHO it is a programming error on the account of importance. No amount > of importance could be so great that local results get flooded and > pushed down so much in importance. > In the Netherlands there is one Starbucks I believe (Schiphol Airport) > and even standing at that location does not return it in the search. Now I can see both sides of this debate. If I am looking for POI's near by it is a different search to asking to find say 'Starbucks, Birmingham' and having the focus change to the selected result. As a new user I'm just as likely to put in my home location and select it as I am to look for something adjacent when the map is not already centred on my location. ASSUMING that the computer IS defaulting to one's physical location is a mistake. *I* use the search to find places that are not 'within range' and can then make an educated guess at wanting 'Birmingham, UK' over one of the American alternatives, and having selected Birmingham, UK, a search for Starbucks, Birmingham, UK fine tunes the results. That is not to say that options for 'near by' would not be useful, but just that 'importance' is difficult to gauge if you don't know what the user expects to see? (An the pigging change of motorway colour really does not help a new user in the UK! One can not readily distinguish the motorways around 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 https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What3words
On 30/11/15 14:28, Ian Dees wrote: > so could we maybe let this thread die? The Abu Dhabi perhaps shows a better understanding of the problems of managing addresses than the w3w project? But I've not looked to see if OSM is picking up on that initiative yet. Certainly since it is in effect a local postcode system it would be more appropriate to be using with OSM data ... especially since it is adding the missing names to many of the new roads in the area as well as giving a smartcode tag which can be converted to a rough geo location. It's not clear from the citymetric article if the smartcode goes down to individual postal addresses, or just the building? -- 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] What3words
On 30/11/15 13:43, Marc Gemis wrote: > On Mon, Nov 30, 2015 at 1:50 PM, Colin Smale wrote: >> > In my example the party that needs to do the translation from w3w to >> > lat/lon >> > would be Amazon, and they will probably be paying w3w for a licence to do >> > that. > Wouldn't it be more likely that Amazon would invent their own system > where customers get a mat with some sensors or build-in GPS tracker > (so I can move and take the mat with me) that can be used by the drone > ? Why would they rely on a (broken) third-party solution ? And of cause why rely on some optical barcode marking when a wireless based tag would be better. May need to change the battery every few years, but it only need to be in receive mode until a drone is in range ... with a button to 'sync' location with 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 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What3words
On 30/11/15 12:50, Colin Smale wrote: > Correct, but the accuracy issue is a weakness in lat/lon based > coordinates as well. If you use your consumer GPS or phone to find your > lat/lon, you might indeed be a long way adrift and you might get > different values on different occasions. Imagine that you were relying > on that to get your shopping delivered... Which is why you need something on the premises you are trying to access even if that is only 'the pink door' > In my example the party that needs to do the translation from w3w to > lat/lon would be Amazon, and they will probably be paying w3w for a > licence to do that. But if two adjacent doors both have amazon landing mats there is still no guarantee that the w3w tag is correct for one or other of those mats. But I expect at some point some sort of bar code cross check would evolve and the correct mat can be identified. As has already been pointed out on the discussions on these droids, it only works when there is a single story dwelling. Add 100 flats with one front door on a busy street ... but personally I think there will be more losses due to droids being intercepted in flight? :) > On 2015-11-30 13:30, Lester Caine wrote: > >> On 30/11/15 11:59, Colin Smale wrote: >>> I think their big attraction is the 75% (their figure) of the world that >>> doesn't have a functional address system. The added value in the UK is >>> indeed zero. In some tribal village in Africa for example where an >>> address might not get any better than "3rd mud hut on the left after the >>> group of 3 trees" the idea of giving all the dwellings a simple address >>> might open the world of e-commerce up to them. They will have an address >>> to use, and Amazon's drones will be able to find them. Maybe not today, >>> maybe not even tomorrow, but soon. >> >> But 'What3words' can't actually locate them ... you HAVE to convert it >> to the GPS coordinates. Third hut on the left at least works without >> needing a mobile phone :) Doing the reverse process you need an accurate >> GPS system to establish the coordinates before you can convert that TO a >> w3w title. If the mapping system is only accurate to 10mts your android >> drone has a selection of targets. I've just looked up my own address in >> the UK and depending on which map overlay I select I got four different >> answers, some the next door addresses. -- 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] What3words
On 30/11/15 11:59, Colin Smale wrote: > I think their big attraction is the 75% (their figure) of the world that > doesn't have a functional address system. The added value in the UK is > indeed zero. In some tribal village in Africa for example where an > address might not get any better than "3rd mud hut on the left after the > group of 3 trees" the idea of giving all the dwellings a simple address > might open the world of e-commerce up to them. They will have an address > to use, and Amazon's drones will be able to find them. Maybe not today, > maybe not even tomorrow, but soon. But 'What3words' can't actually locate them ... you HAVE to convert it to the GPS coordinates. Third hut on the left at least works without needing a mobile phone :) Doing the reverse process you need an accurate GPS system to establish the coordinates before you can convert that TO a w3w title. If the mapping system is only accurate to 10mts your android drone has a selection of targets. I've just looked up my own address in the UK and depending on which map overlay I select I got four different answers, some the next door addresses. -- 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] What3words
On 22/11/15 14:32, Colin Smale wrote: > By the way, just to be absolutely clear, I am not thinking of w3w as a > coordinate system in OSM, but as an addressing attribute similar to postcodes. On one hand, one plugs in the three word location to their app and get a coordinate which takes you approximately to where you want to be. One needs the map to find the location in the first place, so if nothing is mapped one needs a precise coordinate ... so one logs the coordinate as well? I get the idea of 'what3words' but not while it has a page for pricing! It is something that should be a free world standard and there is nothing stopping the likes of HOT providing an alternative? But when one adds proper support for 6500+ languages building something inherently based on English is perhaps not the best starting point? All the uses I am seeing for it ALSO have the coordinates so it seems somewhat contrived trying to make it commercial in the first place? The second you NEED an app to convert from one 'system' to another is there really any need to have some human readable name? Can I go to amuses.sizing.stream without an app, when I can go to uk.worcs.broadway.xxx by following signs? -- 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] What3words
Sent from my android device so quoting is crap! -Original Message- From: Colin Smale To: Daniel Kastl Cc: talk@openstreetmap.org Sent: Sun, 22 Nov 2015 12:57 Subject: Re: [OSM-talk] What3words On 2015-11-22 13:49, Daniel Kastl wrote: The difference in their proprietary system (if you want to call address systems in in countries closed and proprietary) is, that when their API (and "algorithm") goes away, you won't find any address anymore. It's totally unreliable to depend on a proprietary API to locate an address, and a waste of time to add such data to OSM in my opinion. From their website: If we, what3words ltd, are ever unable to maintain the what3words technology or make arrangements for it to be maintained by a third-party (with that third-party being willing to make this same commitment), then we will release our source code into the public domain. We will do this in such a way and with suitable licences and documentation to ensure that any and all users of what3words, whether they are individuals, businesses, charitable organisations, aid agencies, governments or anyone else can continue to rely on the what3words system. Translation- if we can't make money from this then you are on your own There is nothing stopping anybody creating an open source alternative now perhaps directly extending the already open source data? what3words is not a good base to start from o why would we provide them free support? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Undiscussed (?) edits removing lesser-used highway=* tags
On 10/11/15 10:08, Martin Koppenhoefer wrote: > One of the great strengths of OSM is that you can invent tagging on the > fly and trying to suppress that just so that the data consumers have it > easy, is misguided. In the end the main way our tagging evolves is be > contributors trying to map stuff that doesn't have a popular tagging > scheme associated and not allowing that will reduce new tagging to that > decided by a committee. > > +1, very well put. I have in the past seen this more than once: invented > a new tag to try something out, someone else comes along (typically a > remote mapper with no knowledge whatsoever about the place) and tries to > "normalize" the new tag into something common (but not applicable). Even > fixing "typos" has to be done very carefully and hesitant, limited to > actual typos like "highway=residental" and not extending to assumed > synonyms. Plus and minus on that ... Yes adding tags has to be flexible, but there are still a few areas that we need perhaps a tighter control, and adding highway types that do not then get displayed is probably one? As with the current discussion, key elements need a few ground rules, but that does not prevent additional data being added via extra tags. The rule about not tagging for renderer or router works both ways since one may need to add information that can't easily be accessed or simply does not exist on the base tagging? -- 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] highway=residential_link
On 10/11/15 09:40, Martin Koppenhoefer wrote: > 2015-11-10 9:36 GMT+01:00 Mateusz Konieczny <mailto:matkoni...@gmail.com>>: > > In theory, it is possible that former motorway/.../tertiary with slip > roads/ramps was converted to residential road, without changing road > infrastructure and traffic is still grade-separated. > > sounds not very likely. At the point where a motorway or even tertiary > road becomes a residential road, it will clearly change a lot (or > otherwise it would remain a tertiary etc. road). A residential link > would be a road between 2 residential roads (or a residential and an > inferior road like a service), because if it were a higher road class to > which the residential connects, the link would be called after that road > class. > > There's not really a problem calling a road that connects 2 residential > roads a residential road as well. > > Examples /(also covering unclassified and even tertiary): > http://www.openstreetmap.org/way/35022603 > http://www.openstreetmap.org/way/24038678 > http://www.openstreetmap.org/way/27854328 The third example is the sort of link I would expect to see approaching a motorway where restricted traffic gets redirected, but I think that as in this case, the lowest level would be 'unclassified' rather than residential or service. Of cause in the UK most roads ARE classified in some way, so the residential or service is simply a way of avoiding having to look at 'landuse=residential' or 'retail/industrial' as these are all still link roads between other higher classification routes? So this is just a matter of agreeing terminology, and while 'tertiary_link' may well pushing the limits still, any other _link not listed on http://wiki.openstreetmap.org/wiki/Highway_link should be re-tagged. The best description of how a link should work is probably when creating routing instructions. What still grates with me is the 'Bare slightly left onto M5' when the instruction should be 'Take slip road onto Axx' and that in my book is where the _link information has an important element but could also be a second tag. However like 'highway=residential', 'highway=trunk_link' is a shorthand that works at many levels ... but should the link be tagged for the road it provides the link to rather than the one it obviously comes from? -- 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] New OSM Carto: White Roads & Road Widths
On 04/11/15 12:08, Pieren wrote: > On Tue, Nov 3, 2015 at 5:58 PM, Martin Koppenhoefer > wrote: >> > tertiaries are still rendered, they just don't have a different colour >> > than other roads (but they are thicker). In German we say: remain on the >> > carpet ;-) > Well, I would say in English "you play with words". It's not visible > as a specific class. And for the minority who will see it's thicker, > they will think it's based on a physical attribute (width or lanes), > not on its importance. The simple answer is secondary, tertiary and unclassified roads in many areas of the world have the same importance, so rendering them drastically differently is a mistake! -- 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] New OSM Carto: White Roads & Road Widths
On 04/11/15 01:06, Dave F. wrote: > > Hmm... Interesting; I notice nearby that motorway & links are now > rendered as I suggested: > > http://bl.ocks.org/tyrasd/raw/6164696/#18.00/1.29498/103.87800 > > However it doesn't for trunk_link: > http://www.openstreetmap.org/#map=18/51.39961/-2.33758 > > Maybe it should? (I haven't test the other *_links) That is a part of the jigsaw of why the rendering around here is looking 'messy'. The motorways are at least rendering with a central reservation, while the primary routes are loosing that boundary. On smaller devices the problem is worse than on high resolution devices. -- 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] New OSM Carto: White Roads & Road Widths
On 03/11/15 14:39, Christoph Hormann wrote: > Note ultimately design decisions are always subjective. If at the end > of a long process a decision is made without once more listing in depth > all arguments for and against it this does not mean the decision is > arbitrary. A 'long process' carried out in a small area of discussion is proving problematic for the wider user base. This is one area that once exposed *IS* proving to be the wrong subjective decision followed closely by the changes to road width. The world is a large area with a large range of data spread, so trials may well have missed numerous examples of where something that looks good for a few limited examples fails in the wider coverage. -- 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] Improved new Icon set for Open Street map
On 02/11/15 18:08, nebulon42 wrote: > However, there is of course always the possibility to improve things > further. I'm welcoming contributions at https://github.com/gmgeo/osmic, > which is a repository that holds all icons I have done for the Standard > map style (some I have also adapted from Maki and other free sources). > You can also directly contribute to osm-carto at > https://github.com/gravitystorm/openstreetmap-carto. As a dinosaur who actually liked full colour icons on websites, I've my own version of bootstrap using full colour ones, and I'm now looking to extend that into the icon map for my own rendering. While the styling for OSM is quite complicated it can easily be broken down into manageable elements such as road colours, or icon library, so switching elements is not particularly difficult once one has a working local rendering system. -- 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] Release openstreetmap-carto v2.36.0
On 01/11/15 12:39, Max wrote: >> not long ago (maybe even today?) pharmacies were not only selling goods but >> > also producing many kinds of ointments and possibly other things as >> > ordered >> > by the prescribing physician. >> > >> > So "shop" would be a too narrow definition. > With that argument you should also change stuff like shop=florist, > because they aren't just selling the flowers they buy in bulk, they > actually make arrangements and bouquets and stuff... The irritating bit is the miss match of things like amenity, shop and now 'healthcare'. In my tag list the local doctors surgery is an building=clinic and has within it an amenity=doctor, nurse, dentist and pharmacy. Just as my local hospital has various additional amenities such as podiatrist (who CAN be a medical practitioner here!), optometrist and the like. But just down the road from the doctors is a shop=chemist which also provides a dispensing pharmacy amenity and has a visiting podiatrist. The doctors pharmacy carries out no over the counter sales ( apart from the extra tax con ;) ) so is an amenity, while the chemist is clearly a shop providing various amenities, some of which may not be 'healthcare' ... do we really need yet another complicated tag in this mix? Adding 'office' as another option of "A place predominantly selling services." also confuses the picture. The building is an office, shopping_mall or retail premise, and once again, the amenity provided is the job function. The estate agent is next to the chemist's shop in the same building, so tag the building 'retail', and each unit with is amenity(s)? -- 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] Release openstreetmap-carto v2.36.0
On 30/10/15 21:01, Matthijs Melissen wrote: > * Major rewrite of road and railway rendering, as part of Mateusz > Konieczny's Google Summer of Code project. See BUGGER I still haven’t got the backup system working and now all my UK stuff is screwed up :( This really does not 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 https://lists.openstreetmap.org/listinfo/talk
