[OSM-talk] Bulk Uploading GPX files on the OSM website
Hi, A few of my issues with uploading gpx Files to OSM which I'd like to discuss, and put forward some suggestions. This may have a specific place to be discussed? I'm really not on top of mailing lists. Each few months I have about 100meg of gpx files to upload which is a very slow process on a slow internet connection. One option is to bundle them and upload, but they appear as one trace as stated here: http://wiki.openstreetmap.org/wiki/Batch_Upload Likewise if I upload as a batch I then have to find all the files and change all the tags for purpose of organisation. So I individually and painstakingly upload them and tag them up, with each file taking about 3 mins+, and I currently have a backlog of about 500 files. So the concept of sitting for 24+ hours of solid uploading/labelling files is unappealing! So it is always a case of taking a huge amount of time, the current options are just to either take that time up with a different process or compromise the organisation with a more basic process to save time. So in short, 'save time by not doing it fully', or to put it bluntly, 'cut corners'. Part of the issue is also having to move between pages to edit tags (if batched uploaded), or just to upload a new file if manually uploading files individually. Only a few seconds loading each page but it really adds up fast. This can be partly overcome by having multiple tabs open and setting up the next upload while the other one is underway, however the 3+mins per upload was considering this. Then moving files around and finding files is not possible. Finding files has been addressed and there is a request here: https://trac.openstreetmap.org/ticket/1999 so I'll just +1 that. For moving files, currently once a file is uploaded it's stuck in that order. Again depending on your level of organisation you may be able to relate or not, but sometimes it's infuriating to have to delete files you've painfully uploaded to upload another one in the correct place, so that the files are in date order (which is how I have them organised). It would be a huge time saver to be able to manually move the files up/down the list. Also the bulk uploader, and the wiki page is far beyond the ability of the average computer user, of which I am one. Within this project I will be one of the less computer(code) able people, however within the wider world, I am very able with computers. So from that perspective it should be common for me to read much I don't understand in this project, however I shouldn't have issues with using something like a bulk uploader, or a commonly needed tool/site etc. So that is my description of some bottlenecks. My idea, for simplicity I've stuck into an image form, which I'll give a rough description of, but hopefully the concept is clear. http://i57.photobucket.com/albums/g226/ben_robbins_/OSM-DetailsPage.png http://i57.photobucket.com/albums/g226/ben_robbins_/OSM-EditingPage.png There would be a bulk upload option in on the upload file page, and you then select a .rar/.zip file etc. It uploads untagged, or can inherit the file name for description, or put your own in for all of them being the same. Once all loaded a page opens (editing page) which lists all the files and allows you to add tags in mass. As for instance the tag 'UK' would likely appear on 100's of files in a row if you live in the UK which may have been uploaded. Likewise in smaller clumps with country/region/local region/town name etc. So if you could apply tags to ticked files, or manually type names in on the same page that would be ideal. Then for the file name a 'replace' function as in Excel would be ideal, as the track name can often be part of the file name. So if you inherit the file name, then replace, you can extract the necessary section easily as in example. The replace option would need to be able to look for something such as File - or **/**/2012 - for example. Then next to each file with it's tick box would be a small up and down arrow, for shifting the file around in the order, and likewise a delete button for quick removal rather than having to shift to a sub page and taking time. Finally within the current file listings page, a tick box method of getting multiple files into a multiple file editing table as just discribed would be needed. An advancement on this would be to be able to add to a list, by leaving the page and coming back to it with more selections. Also being able to remove things from the selections page, rather than just un-selecting. (Actually in rereading that, it really sounds similar, but a less graphical version, to the facebook bulk photo uploading interface.) I have no idea about ease of enabling such a feature/features or the demand that would have on the overall system, but I hope this highlights a few seemingly small inefficiencies which are huge in mass file uploading. Any one of the
Re: [OSM-talk] Road cores and casings on standard Mapnik rendering
Can you give an example of a junction that doesn't look good to you? The z13-z18 links I previously gave seem not all to open, so instead here is a cropped z18 sections:http://wiki.openstreetmap.org/wiki/File:Z18crop.pngIt best shows the common problems, coming from the core-casing width issue. Below is a junction which I made as neat as I could but didn't touch the highway= tags. This is how it was added, and how all the junctions I've seen have been around Dubai tend to be mapped, and most of the world, where I’ve edited. At the bottom left there is an example of the issue of there not being a service_link tag, or just that the motorway_link renders early. However I do see your point, and if the _link tags were later there would be other issues gained for those dealt with. http://wiki.openstreetmap.org/w/images/2/21/Comparison_-_Junction1.png Now if we say that a road only moves 'up' in status when it joins a higher status road and not before, then I end up with this: (I have now started to map for the renderer, although I can see justification in this in reality, where link has to meet it’s higher ranking ‘parent’ before it becomes that status.) http://wiki.openstreetmap.org/w/images/0/07/Comparison_-_Junction2.png An issue here is the lack of an unclassified_link road, so in the top left the road sits on top of motorway_link.If I say that all departing roads must also drop to the status of the road they are linking where that road is lower status, and have no actual _link roads then I get this: http://wiki.openstreetmap.org/w/images/8/8f/Comparison_-_Junction3.png If I go back 1 step, but remove all 'link' status tags, I get this: http://wiki.openstreetmap.org/w/images/1/19/Comparison_-_Junction4.png So, this really brings up 3 separate considerations, and the rendering is a small fraction of it, and I'm going to try to explain what’s in my head in a clear way... here goes! If all road statuses don't increase before meeting a higher road status; and all road status's decrease, when leaving another road, in preparation for there end-connection road status, then it works on the usage of no ‘links’. If links are used, then all status's must have a link variant. This is currently not so. In the event of this not being possible, due to ‘reality’ dictating road status, and therefore going against the aforementioned criteria so as to ‘map how it is’, then ‘links’ would again have to be available for all variants. However in the event of a none-‘link’ road coming off a ‘link’ road of higher status, it would need to devolve to a none ‘link’ road, which would be messy. However common practice has the road status as increasing to meet the fore-coming road status where it is higher, and holds onto former road status, again where it is higher. So the factors causing this are: Standard editing practice – Having roads promoted to the higher of its options.Missing _link values for the smaller road types.Different Rendering Widths. This also brushes on ‘map how it is, not how it renders’, but then we should also ‘map so it may render how it is.’ And here in lies the clash. One of my favorite renderings is TopOSM: http://toposm.com/us/index.html Its rules are very consistent and I like its progression of road widths. Nice, haven't seen this before, thanks for that. Cheers, Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Road cores and casings on standard Mapnik rendering
Another Failed Link. Try this: http://wiki.openstreetmap.org/w/images/6/6a/Z18crop.png ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
I wonder that noone, so far, mentioned that we had similar discussions on talk-de. Please, do not discuss only in GB. The sitiuation is even a bit more complicated because of law (especially for bikes) and we have foot/bicycle=official, too. I stoped using footway or cycleway at all. And do not forget emergencies which could use a track but not a path. Thanks colliar Well in a nutshell, this is the debate, and how every ML conversation on the matter ends up: http://i57.photobucket.com/albums/g226/ben_robbins_/Tracks-1.png?t=1306366810 It starts in the 'blue' section. It then goes in circles for the best part, or it all ends with the renderer. Either of the 3 points where I have put an exclamation mark (but not the bottom right one) would deal with the problem I think you have described. (Ignore the other one, it was for something else) It's rather amazing the complexity of something so simple! --- So really, going along the lines of 'highway=track; designation=xyz' it just about works, but 3 issues remain. 1) It doesn't render correctly/at all. 2) The assumed access rights of highway=track in a route planner are not clear, and/or a problem as shown in diagram. 3) The need for Highway=byway/bridleway/footway...is there one; again shown in diagram. Any definite answers or advice on these points from anyone? cheers, Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Frederik, Where you map, maybe a track is public. Not where I map. A track, like a pencil or a car, is just a phisical thing. Now I'm not requesting it should be made private by default, or public by default. I'm saying that where it 'IS' just a phisical thing, it 'can coexist' with other highway tags. The whole problem is differences between the defination of track in different countries, so talking about it just in Talk-GB somewhat misses the point. Now in any ideal system both 'tracks' as you have them, and 'tracks' as we have them can be mapped/rendered. In OSM, and on Mapnik (possibly osmarender?), both track and ROW's are under the same key, and the designation= doesn't render, although is a hacky way of tackling the problem. So yes, the exposing of the problem is specific to the UK. The problem is not specific to the UK. All we need is a phisical list, and an access list. byway/bridleway/footway are access. track/path are physical. Therefore where you map x=track can be by itself, and you get what you want. Where I map x=track can go with y=footway and the UK can also be mapped correctly. It's so incredibly simple! Hi, On 05/21/2011 01:41 PM, Ben Robbins wrote: If it is a) (just a track), show just a track. If it is b) (a footway (public access)) show a footway. If it is both, we need to be able to show both. A track which does not have access=private or access=no or something is always accessible and usable for pedestrians, so why would anyone want to tag it as footway too? A footway, on the other hand, is never a track because then it would have been tagged as one. I don't understand what you're going on about, it must be something specific to the UK, and I second Richard Fairhurst's suggestion that you take this to talk-gb. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Frederik, Where you map, maybe a track is public. Not where I map. A track, like a pencil or a car, is just a phisical thing. Now I'm not requesting it should be made private by default, or public by default. I'm saying that where it 'IS' just a phisical thing, it 'can coexist' with other highway tags. The whole problem is differences between the defination of track in different countries, so talking about it just in Talk-GB somewhat misses the point. Now in any ideal system both 'tracks' as you have them, and 'tracks' as we have them can be mapped/rendered. In OSM, and on Mapnik (possibly osmarender?), both track and ROW's are under the same key, and the designation= doesn't render, although is a hacky way of tackling the problem. So yes, the exposing of the problem is specific to the UK. The problem is not specific to the UK. All we need is a phisical list, and an access list. byway/bridleway/footway are access. track/path are physical. Therefore where you map x=track can be by itself, and you get what you want. Where I map x=track can go with y=footway and the UK can also be mapped correctly. It's so incredibly simple! Hi, On 05/21/2011 01:41 PM, Ben Robbins wrote: If it is a) (just a track), show just a track. If it is b) (a footway (public access)) show a footway. If it is both, we need to be able to show both. A track which does not have access=private or access=no or something is always accessible and usable for pedestrians, so why would anyone want to tag it as footway too? A footway, on the other hand, is never a track because then it would have been tagged as one. I don't understand what you're going on about, it must be something specific to the UK, and I second Richard Fairhurst's suggestion that you take this to talk-gb. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Nelson I agree with Richard and Frederik's suggestion that this is an issue only in the UK, and that you take it to a forum where everybody understands what the heck you're talking about. See previous reply. But may I make a suggestion? That the best way to resolve differences is to write them down in a Wiki page (easy to do in your own namespace), link to places where your wisdom differs from the common wisdom, insert a link from there back to your page, and say This is how I map. If people share your wisdom, they will follow you. This has been done. Both in and not in my own namespace. There is no wisdom in this. It's just the flaming obvious! And a further suggestion: that if what you are doing does not conflict with what other people are doing, then the problem isn't a mapping problem, it's a rendering problem. Rendering problems are solvable without requiring coordination between people. This does conflict. One person may tag highway=track to what is a footway (UK access right). It is highway=footway with a track there also. Or (according to designation=) it's highway=track designation=public_footway, but this is not recognised by mapnik, and therefore is half way to being a solution. The easiest way to create order in OSM is to DOCUMENT HOW YOU MAP, and DON'T MAP IN OPPOSITION TO HOW OTHER PEOPLE MAP. We don't all need to map the same way, but the people who use the data need to understand it. Here I completely disagree. Not that it's not the commonly stated philosophy, but that it works. Standardisation is everything to data of any value. If I decide to change motorways to natural-wood then that is just wrong, it's not 'my own style'. It is important to be able to make up tags and tag as you wish where tags currently don't exist, but where something does exist unity is vital to good data. And that is why I'm posting here. I can easily get rid of the whole problem by just having a render rule sheet which has tracktype= render a track, rather than highway=track+tracktype= render a track. And yes this is a 'render' issue. But mapnik and osmarender are on OSM's main page, so it's more than just a render. There 'keys' which state what things mean contradict map features, and they influence how people map, so they are more than just a render. Now asuming progress is made on a wiki discussion page, which has happened many times, and people with similar mapping issues have come to agree with what i'm saying. The issue then is that the rulesheets for the main renders then have to follow, and then ironically lead that change, and that doesn't happen. I love the work that people have done, and mapnik is stunning, but it is vital that it and the wiki match up for the fundermental features. Now what happens is that I state the issue and a solution, and people say why it's not an issue for them, and that's that. It make's no progress. People then have issues later on, don't corralate it as being the same issue, and in dribs and drabs (rather than in it's entirety) have map feature changes made to patch there specific issue. If there was no issue, which boy I'd really like to be the real answer, then someone would say, ok tag xyz and it will render abc. Never has this happened; therefore there is a problem, becuase an alarmingly commonly appearing feature can't be mapped/rendered. And I can't stress the word 'commonly' enough. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
That said, highway= implies that the object is a public or private way (US terms, but usable by the public), except for highway=service and highway=track. actually a highway=* is any kind of way, and access by the public might only be implied if no other access is tagged explicitly. Cheers, Martin This is the problem in a nutshell. Implications, and bundling of values in a key. Let's say there is no such tag as highway=motorway. Is a 'motorway' just - highway=primary[1]; access:private[2]; car=yes[3]; motorway=yes; lorry;yes; max_speed;x; lanes:3; hardsholder:yes? i.e. do you take an implied access[1], then void that applied access[2], then state specific means of transport to build up a motorway like description through multiple specific tags?[3] now see the 'track issue' as this. highway=track; access:private; foot=yes; horse;yes; (a hundred other regulations;yes) now just like the motorway being more than just tarmack for cars motorbikes. it is 'a motorway' - a bundle of rules and regulations. A package. And this needs to render as such. The motorway example isn't a sort of primary road. It is a 'motorway'. The bridlway on a track isn't a sort of track. It is a bridlway. It can go on a track. So the aforementioned track tag combo is a 'bridleway'. highway=track; highway=bridleway not possible. highway=track; designation=public bridleway not rendering, and contradicted by what does render. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Ben Robbins schrieb: does seem like an incredably hacky way of solving this issue. Practically everything in OSM is done in a hacky way. And actually, that's probably the only way that works in a mostly unorganized, freedom-promoting community. If you want strictly logical organization, you're probably in the wrong project. ;-) Robert KaiserThe freedom is a farse, becuase people tag to render! Sad but true. I'm awair this sounds blunt and near on angry, but I'm not at all bothered by this, so long as that contributors are free to map. It's not a screech of annoyance, I'm just stating what I have realised to be true. A realist can agree with a pessimist, but just by chance; not all the time. In almost all other aspects of the project there is nothing to stop anyone mapping what they want, where they want. This is freedom. In a metaphor, a person may be free to write a story, but don't hand them a pen that doesn't work, becuase that means they can't then exploit there freedom. I don't agree at all that it can only work in an unorganised way, and my previous emails propose organisation in one specific example. However, I also elaborated before to say that the answer I'm after in this thread is for 'any' way of solving the problem, even if it's drastically irrational and hacky!. I just want to map. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Richard, I am appreciative of the lengthy reply, but I really feal like you haven't read what i have asked. Firstly let me say that I havn't been away for a long time. I simply haven't been editing much recently (I'm assuming you say this based on my edit log or something). I have read much, often, and gathered data intensively in this period. I do stand corrected however on the designation=public footway, and apologies for not finding this; however it doesn't render and is a sub-page listing, so it doesn't actually devalidate the original point. If you point was valid, then I would expect to have a clear answer returned at me, and to find myself quite stumped. Yes I have barged in, but I am welcoming a barge back out the door with an answer. Hell, I wan't nothing more than to have it thrown back at me. (question repeated at the bottom) foot=yes, horse=yes i explained the problem about in previeous emails. a motorway is more than car=yes. It's a bundle. This is more than just a word issue. It doesn't get render results, and would be hard to. we optimise for ease of mapping - I agree that this is where to go, but I don't see it in this case.You then go onto explain highway=footway bicycle=permissive etc. I understand this, this isn't new, hell it's been around years. What you are doing is taking 'tweak' tags, to modify a 'bundle' tag (yes made up terminology, but hopefully it makes it clear). Rendering a set of 'tweaks' would be a lot of work, and wouldn't correctly define something. It would also require modifcation on any change in the 'real world' which wouldn't be required with a 'bundle'. However...again, if it renders and is correctly mapped, does it matter, i don't know. Again to the 'ice the cake' I know all of this. I don't want to seem big headed, but this isn't isn't a 'new development' that I haven't considered, and it seems somewhat like what I have said is, ironically, has been walked in on and your telling me I've approached it all wrong. I'm sure many people are happily mapping, but if you look at the renders, it doesn't represent quite what is there, and i can't really explain this in any more detail. Also, I have no idea how to take this to talk-gb, except by simply replying there not here, and breaking up a string of responses. I did however justify why it's here, which your welcome to read. I'm still struggling some what with getting these replies in the right place, so sorry about that. So to get back on track, and I think the answer is clear. There is no way to get a byway on a track to render as a byway on a track on either mapnik or osmarender. Is that correct? And if so, does the current tagging scehem simply require a render change to allow this, and if so I shall move on to a render request/proposal where needed and forget about all the other points I initially stated and that have been missed. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
RichardB: I'm aware it's appeared before, that means nothing if theres still an issue. To class the tagging system as 'the wheel' is giving it far to much praise, the wheel is what would be great to have. are the following tags rendering on the main openstreetmap renderers? If so, can designation=public_footpath appear without highway=footway. If so, that does then bring up the issue of good rendering, and correlation between style and meaning, and also asks why it was necessary to have yet another key to patch up an issue. designation=public_footpath designation=public_bridleway designation=restricted_byway designation=public_byway or designation=byway_open_to_all_trafficDesignation does seem like an incredably hacky way of solving this issue. It's an attachment tag to correct a bug, where a new key is invented where not necessary. Guess that's standard OSM practice! At least there has been some progress. Simon: Access means the rules/rights you have to access something. I.e there is no public access to my house. or, there is public access on foot to a footway. Physical means what is physically there. I.e. there is physically a path in my back garden. There is also physically a path where there is a public access footway. So, a good example is the M69 in the UK, and I'm sure there are other versions in most countries. It is a fake section of motorway used for training. Therefore it isn't actually a 'motorway' it's just a piece of tarmac. Physically it has all the properties of a motorway. It doesn't however have public access, you can't go on it, and if you did, i assume becuase it's not on the highway, it doesn't have the same standard highway laws. Therefore it is physically a motorway, access is private. It is not a highway. In many countries the 2 can happily be merged together. However in the UK, there are footways(access) which are on private roads, tracks, paths, or not visible at all. The phisical properties are highly varied, the access is the same. Likewise all the aforementioned physical routes can exist with no foot way on. Renderers and OSM's tagging scheme being set out to make this easy really doesn't involve much, and it would have no effect on people in other countries where it's not an issue. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
RichardB: This also makes me wonder, why do highway=bridleway or highway=byway still exist, if designation=public_bridleway is possible? What is a bridleway if not designated a bridleway?! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Simon: To put it simply. There is 'can' and there is 'may'. Places one 'can' go, and places one 'may'. I can walk across my neighbours lawn, but I may not. I may choose to take a footway where I 'can' walk on a track, then take another footway where i 'may' walk where i 'can' on a path. In OSM track and footway can't coexsist. The 'highways' key has a mix of these as well as tags that state both, neither or something completely different. Likewise for rendering. Hope that makes sense. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
Simon: There is no such thing as a track as an access right in the UK. I merely give this example becuase I am talking generally, and apparently they do exist elsewhere, and this has been insistend relentlessly by others in the past, so I'm just going with that. In the UK there is no use for highway=track at all, but it's not 'just a UK' thing. I agree that the origins of the highway tag can be ignored and that they started in with UK definitions doesn't matter. It's what we now have that matters. The rendering rule sheets on OSM's main page are not listening it seems to what there is now. If it did, the highway=byway/bridleway/foot-way would be a rarely used tag within the UK. It is not. I think justifying why something is a mess doesn't make it justification for leaving it as such. The problem is having highway=bridleway with highway=track. Now as Richard B said there is now the designation tag so highway=track and designation=public bridleway can be done. However this isn't rendered either at all, or if it were would clash and not render correctly (brown dash for track with yellow dash for byway on mapnik). Freemap seems to asume that highway=byway is another way of saying it's a road. Which is odd becuase byways may be on a tarmacked road (can only think of 1 i've seen), but they are also on tracks or just grass. In this example the byways are mere tire tracks in the grass: http://www.free-map.org.uk/freemap/index.php?zoom=16lat=52.09726lon=-1.06801layers=B Now the 'designation' option could work. 3 things then need to be done. 1) It just needs to be listened to and rendered. WIth logic. 2) 'access' rights should be removed from the Highway tag. 2) There should be consideration as to what the difference is between route= and designation= really is, and why there under different keys. Richard Fairhurst: This is talking about highways in general, and the render rule-sheets. The fact that the problem is exposed within the UK does not make it UK specific. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tracks and there place in society
are the following tags rendering on the main openstreetmap renderers? If so, can designation=public_footpath appear without highway=footway. If so, that does then bring up the issue of good rendering, and I think you are conflating two things: in tagging, it makes sense to describe both the physical object and the legal issues. I think everyone agrees that these are conceptually separate, and that our tagging scheme often carries both meanings. In rendering, maps can be made for many purposes by anyone. You're basically complaining that the standard rendering doesn't do what you want. I'm complaining not because it's not what I want, but because 1) it's not possible to map correctly. 2) the system is not particularly neat/organised. I do want it to be better yes, but there's rational behind my point, it's not me complaining becuase I don't have what I want...I'm not that simple. In the case of a way which is physically track but is also a public_footpath but not a public_bridleway or a byway (please excuse errors - I'm the US, but I hope you get the point), a map could choose a) show a track (because that's what is physically) b) show a footway (because that's what most people can do with it) c) show a track with some tint to show both concepts (note that we already have no-access tint) d) skip it, because a clean view for normal driving is wanted Each of these 4 choices will make some people happy and not others. So having a debate about the right one for the default render is not going to be too useful. If it is a) (just a track), show just a track. If it is b) (a footway (public access)) show a footway. If it is both, we need to be able to show both. For c) it then has assumptions made about highway=track. If you need to add no=access, then has highway=track implied some access, and in which case what? For d) I'm unclear what you mean by 'it'. If you mean the public bridleway that is on the track then that is a fair point if the map render is made for drivers. However it is not, it's beyond a 'streetmap' as the footways and bridleways demonstrated from day 1. The data and the styles are all free. Perhaps you can render your own, and share your style.A proposed specific change to the style file to implement some form of c with an example rendered is soemthing that I think would be more well received. I do render my own. I have shared a style in the initial email. An additional image is here: http://wiki.openstreetmap.org/wiki/File:Tracktype_example.PNG this is some 5 years old now. I would personally propose that a track (phisical) is renderered with core/casing in some form, so that a coloured access right can render on top and there is no clash. However, this 'is' just what 'I' want. It goes beyond just addressing the problem, and even getting some acceptance of it. What I am trying to Emphasise is what map features says is near meaningless if it isn't rendering, becuase the renderer will influence what people do. So as far as I can see highway=footway still clashes with highway=track on the OSM renders, even if there is a sorta fix on map features. That said, highway= implies that the object is a public or private way (US terms, but usable by the public), except for highway=service and highway=track. See this is part of the issue. It implies different things, or many things. Ideally it should be clear, and that is what I would like to try to sort out. If values appear under the same key then there shouldn't really be the 'excepts'. Also it's more complex that just implying 'public or private'. 'motorway' implies all motorway regulations and properties. Track's in the UK don't have this, they have the regulations of the 'something else' that may or may not go along them. Those access defaults are perhaps a mess, but the main point is that there are established clear semantics for the tags. In the case of physical tracks with various public_foo status, it seems there is a clear way. Can you ellaborate on this? I'm not following. What is this clear way, and would it be possible to see an example of this please? Sorry if this isn't appearing correctly in the archives...I'm not really clear on how make replies attach to specific messages. Also,I'm off for 3 days, so apologies for a slow responce to come. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Ben's Consise Compendium of OSM issues - Tracks and there place in society
Hi, I don't usually partake in the mailing list, so it probably looks like I just appear like I'm popping up and stirring trouble, but this is such a massive problem for mapping in the UK rural areas, I've really just given up until some way of making it possible is enabled, because it’s so disheartening not being able to do things right, especially since the joy of mapping is in capturing what you see around you. I think this would be 1 of my 3 wishes if a genie popped up right now, and I'm willing to talk about this how ever long until something is sorted because it is stopping good mapping full stop. It's been a complete pain in the backside for half a decade now; it's a joke. The overall problem is OSM tags. Highway= in particular is a complete mess. Specifically there is the alternation OR merging of physical/access/usage in the same field. 1 particular tag where this is more of a problem than anything else. Highway=track. It is stopping the most simple maps being made. Highway=track. Physical track, or access track? Currently Osmarender seems to have it physically represented, mapnik has it looking like access (based on correlation of attributes) Please check the image here: http://i57.photobucket.com/albums/g226/ben_robbins_/Diagram1.png?t=1305927949 The top section has 'Physical' tracks and paths in black. It has 'access' rights in colours. The diagram at the bottom then shows how OSM works, very simplified. Physical and Access are separated on most features, be it far more messy than might be implied!, but for track they are merged. This means that a phisical track cannot exsist with a highway=bridleway. It means that such a simple and fundamental feature of a standard UK map is absolutely impossible in OSM on the main page renders. Very basically this is all a problem becuase highway=track and highway=bridleway/byway/footway cannot both be tagged together. They need to be understood and moved, or duplicated into 'routes' or another key to state access. Having them together any longer will knock 10 years off my life, I'm sure of it! We need to either move bridleways/byways and footways to routes or somewhere/anywhere else!, and just leave highway=track and highway=path. Or we need to move physical things (like tracks) out of the highway key, even though highway is apparently 'Physical', realistically it primarily states access rights. Now the problem is beyond the archaic jumble of sporadically appearing highway tags. It's the renderers. No matter what is said, they dictate everything that happens. People tag to render. If it renders the tag is used. If it doesn't it's not used. If it renders wrong, it's used, and that becomes right. I wish something could be done about this, but that's a future tangent. The aforementioned track problem was solved by 'tracktype' which when put on a way by itself states 'it is a track' 'it has surface x' this means that highway=byway could coexsist. But no...the rendering rule sheets did not follow, people tagged to render, and so it is now still as it was 5 years ago. Please check the images here: http://i57.photobucket.com/albums/g226/ben_robbins_/Example1.png?t=1305929249 http://i57.photobucket.com/albums/g226/ben_robbins_/Example2.png?t=1305929355 http://i57.photobucket.com/albums/g226/ben_robbins_/Example3.png?t=1305929355 http://i57.photobucket.com/albums/g226/ben_robbins_/Example4.png?t=1305929815 Here are a string of combinations, where I have quickly drawn (in a made up style) physical tracks and paths, and access rights for tracks and footways (assuming there's such a thing as track access outside the UK?). Finally here I have an render http://wiki.openstreetmap.org/w/images/4/40/South_Wappenham.png This is all done with out a single tag change, I have just used 'track type' as originally proposed, and described above. The difference is that I have changed the render rules accordingly. Please can we: 1) discuss highway=track and/or moving highway=bridleway/byway etc so that they can coexist 2) please update render rules. 3) After the first 2 take a long serious look at the highway= tag in general. I would elaborate, but this is long enough already. As a finally round up, I would just say, I don't care if I'm tagging elephant=cookie; yes=no. All I want is the liberation of being able to have a footway on a track in the renders. Any suggestions welcome, any method, anything. I'm now going to go up mountains for 3 days where tracks and bridleways can be tackled together! Apologies on delay therefore. I will be back! Toodly pip, Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
