Re: [Talk-gb-midanglia] Sidney Street, Cambridge : access=no — why?
It looks rather like that's a typo for node to me Tristan Scott BSc(Hons) Yare Valley Technical Services 07837 205829 01603 858441 On 4 July 2010 23:08, Tim Morley t_mor...@argonet.co.uk wrote: Hi all. I've noticed this odd behaviour in CloudMade's walking route planner: http://bit.ly/armS4y It appears that even for pedestrians, parts of Sidney Street are treated as inaccessible, and the answer *might* be the access=no tag that certain parts of the street have, but I don't know enough about the tag to jump in and correct it without asking. According to http://wiki.openstreetmap.org/wiki/Access the meaning of access=no is Access by this transport mode is not permitted, public does not have a right of way but it's not clear to me *which* mode of transport that sentence refers to. So, does access=no mean no vehicular access or does it mean no access to the public at all? Is CloudMade's route planner mis-interpreting the tag? Is the road wrongly tagged? Is the problem something else completely? Thanks in advance for any clarification you can offer. Tim ___ Talk-gb-midanglia mailing list Talk-gb-midanglia@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-midanglia ___ Talk-gb-midanglia mailing list Talk-gb-midanglia@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb-midanglia
[OSM-talk] Small village high detail low angle orthorectification
I happen to know a chap who has quite a lot of aerial imagery of Norfolk villages. Because he publishes the images, I cannot release the images to the public or to other mappers, but I can use them myself to generate mapping data. Some of the uses I have in mind is to map landuse in villages and missing roads, for villages where most of the roads have already been gps-mapped, giving lots of known points to perform the rectification from. Now, the images are taken at quite a low angle, so I'll need to recify them using software, ideally some sort of orthorecification thing in JOSM, if such is availiable. The tranform will be a basic trapezoid shape, but with a bottom probably half as long as the top (so the image taken at 45 degrees) possibly with slightly bowed sides for any barrel distorion in the lens. Obviously this will only work from items on the flat plane, but handily that pretty much describes norfolk. Does anyone have experience of this, who could point me in the direction of the appropriate JOSM plugin, or external software? I have Linux (Gentoo) and Windows XP on systems used for mapping. This must be a fairly common issue for mappers, right? Tristan Scott BSc(Hons) Yare Valley Technical Services 07837 205829 01603 858441 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Spam on wiki?
13:18, 22 November 2009 Firefishy (Talk | contribs) deleted Gps tracker (Spam) nope, but it appears Firefishy did without consulting anybody. It was rather obviously spam. Tristan Scott BSc(Hons) 07837 205829 2009/11/22 Dave F. dave...@madasafish.com: Tristan Scott wrote: http://wiki.openstreetmap.org/wiki/Gps_tracker Just been poking about the wiki,... It appears blank now. Did you delete it? Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Who contributed most?
There's a interesting tool written by a chap in my area, Peter Ito. http://www.itoworld.com/product/osm/map?area=923:1show=session:35714:1236607544:1236608289 If you set up an area on it, then you can track the area (via RSS) to see who performs edits on it and when - I use it to track my areas to see what other people are up to (and someone's doing some fantastic mapping on the west side of Norwich which is a delight to watch) So a tool like this would be a good way of viewing the last x users to edit an area; this sort of tracking is possible. I don't, however, know of anything capable of dealing with countries, or anything capable of doing the sort of general analysis you speak of. It wouldn't be massively difficult to write, I suspect. Tristan Scott BSc(Hons) 07837 205829 2009/3/10 Lars Aronsson l...@aronsson.se: In the discussion about the license change, somebody mentioned the idea that we might have to delete contributions by users who refuse to agree to the license change or by users who we fail to contact. I have no idea if that suspicion is real or not, but it made me think: Has anybody tried to estimate the size of contributions from an individual user? Only counting the number of edits doesn't say much, because a user can make many small edits to convert roundabouts from squares to circles, another user contributes streetnames to an already mapped city, a third user has mapped the country roads of an entire county. We sometimes hear that OSM has 100,000 registered users, but many haven't contributed much. Well, how many have contributed much? Who contributed the most? For a particular region, such as Sweden, who are the 20 or 200 most valuable contributors? Do we know? I think this has an interest (or at least curiosity) on its own, quite independent of the license change. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Voting on enforcement (traffic law enforcement)
Can people please have a look at this proposal and vote please? http://wiki.openstreetmap.org/index.php/Proposed_features/Traffic_enforcement This is modified after the previous proposal threw up comments about collionions with highway=traffic_signals last time. As for the Compass directions as well as way-ward directions... I expected some nodes to apply to directions rather than specific ways, and also for some nodes to not be on a way and have no specific area of effect (van commonly behind this bush here pointing north towards this motorway junction for example) enforcement_direction which is on a way and applies only to the way it's on would use the (proposed) along/opposite/both tags. Maybe that needs to be made more clear in the proposal? Anyway - Can people have a look and vote please! -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Contraflow bus lane
In my experience (Norwich, UK) a so-called bus lane is often a Bus, taxi and cycle lane. The overlords of roads in norwich often nobble cars by shutting down a small portion of a short-cut (rat run) by making a bottleneck area bus lane. Therefore taxis carry on using the shortcut, and cars must go join the queue on the main road through. the point is that it's not often (at least in the uk) that a bus lane does not also mean taxis. Not sure if cyclists are allowed in bus lanes but in my experience cyclists, by virtue of not having numberplates, are immune to all traffic laws, and simply ignore any and all restrictions anyway. Tristan 2008/10/26 Stephen Hope [EMAIL PROTECTED]: Passenger service vehicles (PSVs) are: * vehicles used in a passenger service (no matter how many seating positions they might have) * vehicles with more than 12 seating positions (whether they're used for hire or reward or not) * heavy motor vehicles with more than nine seating positions So Taxis, Shuttles, Buses, some minivans (the big ones have 14 seats). I have a friend with a horse float that qualifies. In reality, it's almost always buses that use the PSV lanes, but some other vehicles are allowed in some places. Stephen 2008/10/23 Matthias Julius [EMAIL PROTECTED]: Stephen Hope [EMAIL PROTECTED] writes: Not all PSV's are buses. What else? Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Broken Coastline?
I changed the direction of cockshoot broad (it was indeed spun backwards) but couldn't fin anything wrong with the coastline - possibly someone had already fixed it, possibly a bad tile temporarily? anyway, seems ok now. Thanks, all! Tristan 2008/10/22 Rob Reid [EMAIL PROTECTED]: Tristan Scott wrote the following on 20/10/2008 04:27: I've modded the coastline here: http://www.openstreetmap.org/?lat=52.7145lon=1.695zoom=14layers=0B00FTTT And yet all I've done is move about 4 points in a bit, and add a section of beach where I went for a walk. And now some of the new tiles in osmarender seem to have gone blue... I can't see what I've got wrong. Can someone have a squint and see if there's something wrong? (I've never edited a coastline before, so don't know how they work) Not sure if anyone else has made changes since your email but I just had a look and everything looked fine so I re-rendered the problem tile and everything looks good again. The re-render covers zoom 12 -17, it may be a few days before lower zooms are updated. rcr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Broken Coastline?
I've modded the coastline here: http://www.openstreetmap.org/?lat=52.7145lon=1.695zoom=14layers=0B00FTTT And yet all I've done is move about 4 points in a bit, and add a section of beach where I went for a walk. And now some of the new tiles in osmarender seem to have gone blue... I can't see what I've got wrong. Can someone have a squint and see if there's something wrong? (I've never edited a coastline before, so don't know how they work) Thanks -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old data being cached too long
I've just grabbed a mapnik tile at random, and these are the headers sent out with it: Date: Sat, 18 Oct 2008 07:20:05 GMT Server: Apache/2.2.4 (Ubuntu) Etag: cb5563ba81dda2fd9bf27cba5a41164f Content-Length: 7149 Cache-Control: max-age=374906 Expires: Wed, 22 Oct 2008 15:28:32 GMT Content-Type: image/png Therefore, an ISP's transparent proxy should fetch a new version (or the same one again) after 374906 seconds, or 4.33 days. Some ISP's ignore the cache times in their transparent proxies and therefore should be shouted at. Are any of the tiles you're viewing older than 4 days? [EMAIL PROTECTED] tiles are every day, as I recall, and therefore three render cycles could be within the timescale? a [EMAIL PROTECTED] headers set: Date: Sat, 18 Oct 2008 07:27:36 GMT Server: Apache Cache-Control: max-age=10800 Last-Modified: Fri, 17 Oct 2008 10:47:20 GMT Content-Length: 16457 Content-Type: image/png Which should expire after 3 hours. Notably, this doesn't have a Expires: header, which means (theoretically) it could get kept longer as various levels of proxy/cache grab it from each other... Maybe this would help? It should be that holding down control and pressing refresh in your browser should request a new version and not accept cached versions, but I don't know if this matters to javascript or ISP proxies... Tristan 2008/10/18 Matias D'Ambrosio [EMAIL PROTECTED] I thought there were some errors with OSM but today visiting a friend we used OSM and mapnik was looking just fine, no tiles were old, while at home I get a patchwork of new and old, and I have to hit reload a bunch of times to get the right one. It's not my cache, btw, I did check for that :-) (Besides, I use multiple browsers and they all looked exactly the same.) There is the small chance that OSM is doing something wrong that might cause this, but in all likelihood it's my ISP doing business as usual. I know they use a transparent proxy, which is quite opaque as this case shows, but not being a proxy-knowledgeable person, I don't know exactly what they broke in theirs. I see some tiles that are at least two render-cycles old (more than a week and a half), and reloading each tile manually is quite annoying, plus it's one, if not *the*, largest ISP in Argentina. Could anyone tell me the right keywords? What bits to flip? Tomorrow is saturday and I'll be doing some work with plenty of dead time for me to call their toll-free number and see if I can get someone who can talk beyond the scripted responses (I talked with one such person a few years ago), who knows, they might fix it if I provide them with the right info. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Voting: traffic_enforcement
This is a voting request for traffic_enforcement (as no-one seems to know about it?) http://wiki.openstreetmap.org/index.php/Proposed_features/Traffic_enforcement I'd appreciate if lots of people could go vote on this so we can have it approved - I for one would find it invaluable. Such an item is already available as paid-for POI sets for TomTom and other SatNavs, and on public maps like the AA street map and, most other paper roadmaps in the uk (but not ordnance survey). Thanks! -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Voting: traffic_enforcement
Hmm. noting the comments on votes about tag highway it seems that it would be a better scheme to use traffic_enforcement=speed instead of both highway=traffic_enforcement AND enforcement_type=speed Now - this isn't my proposal, I'm just rather keen and willing to try to help. What's the correct procedure now to change this sort of thing? Do we need to stop this proposal, construct a new one and RFC it before voting again (in a month's time!) Or could we, for example, clear the votes, modify the proposal and request votes again? Or, given this isn't my proposal, should I keep my nose out? :) It strikes me that good suggestions like this can't be handled by the vote system, and don't seem to get picked up at the RFC stage... so you end up knowing what the best solution is, yet approving something that isn't it. Tristan 2008/10/17 Frederik Ramm [EMAIL PROTECTED] Hi, On 17.10.2008, at 13:46, Tristan Scott wrote: I'd appreciate if lots of people could go vote on this so we can have it approved - I for one would find it invaluable. Then don't wait - just use it. If there is *anything* you find invaluable, don't wait for others to say they find it too (or not). Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Waypoints with directions (generic data_type structure suggestion)
The proposed system for traffic_enforcement has two premises: 1) The direction is pretty vague - it's defined as a 90 degree arc for traffic_enforcement 2) The node isn't necessarily on a way - therefore you can't use forward and backwards as suggested (mobile cams on bridges, for example, aren't on the way they're checking anyway) This problem also chimes (with me at least!) with the speed datatype problem. Perhaps a new structure for data_type ? We could define a list of data_types in the wiki such as: int (all numeric, no dots, commas or whitespace) float (numeric, with one optional dot) speed (defined as int and a string one of (,mph,kmh,knots) ) direction (defined as string one of (N,NE,E,SE,S,SW,W,NW) ) This would: 1) be easy to check both on entry (this doesn't match a datatype... are you sure you meant this? dialog in JOSM, for example) 2) be a good machine-readable source for not-in-map-features to verify tag values (requested on the speed discussion) 3) mean that renderers could be more easily coded to deal with the types specified (rather than having to work out what someone meant by 30 miles ph) 4) be easy sources for RegExp checking of entered/encountered/output tag values Tristan 2008/10/17 Mike Collinson [EMAIL PROTECTED] At 03:07 PM 17/10/2008, Xav wrote: Hi Some waypoints needs to be described with direction. Some examples : - viewpoint - bus stop - surveillance - traffic enforcement Is it possible to make it consistent ? Add a tag degrees=xxx where xxx is approximate bearing in degrees true north? Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Voting: traffic_enforcement
righto; votes cleared. proposal modified. new vote set in a week's time. I'm not keen on the enforcement direction being forwards and backwards. I can think of examples: * Common mobile station on a bridge - on a way which has no relation to the direction of enforcement * On a crossroads/traffic signals (red light camera) where two ways cross, in which case forwards and backwards are meaningless (two or more ways share the node) * Off a carriageway on a node covering one or more ways (where direction is important but not given by a way) ...so I'm going to leave that as-is Plus direction I've got in mind as a data_type (see maxspeed thread on the mailing list, and also my comments on waypoints with directions) so it would be good to be more generic. Tristan 2008/10/17 David Groom [EMAIL PROTECTED] - Original Message - From: Tristan Scott To: Frederik Ramm Cc: talk@openstreetmap.org Sent: Friday, October 17, 2008 4:32 PM Subject: Re: [OSM-talk] Voting: traffic_enforcement Hmm. noting the comments on votes about tag highway it seems that it would be a better scheme to use traffic_enforcement=speed instead of both highway=traffic_enforcement AND enforcement_type=speed Now - this isn't my proposal, I'm just rather keen and willing to try to help. What's the correct procedure now to change this sort of thing? Do we need to stop this proposal, construct a new one and RFC it before voting again (in a month's time!) Or could we, for example, clear the votes, modify the proposal and request votes again? Or, given this isn't my proposal, should I keep my nose out? :) It strikes me that good suggestions like this can't be handled by the vote system, and don't seem to get picked up at the RFC stage... so you end up knowing what the best solution is, yet approving something that isn't it. Tristan I'm all for clearing the votes, rewriting the proposal, and then voting on the new proposal in say a week. All except one of the votes was made today, presumably in response to your earlier posting, so it might be safe to assume that those who have already approved the tagging read this mailing list and will see the proposal is being changed. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Given that SI units are standard across OSM could be define a speed value in addition to Numeric String etc like so: (default to kmh as specified before (also means not adding millions of pointless kmh strings to the db) Factor means multiply by this to convert to SI - interpreters would either use value as-is or multiply by Factor for that suffix to get SI units. Suffix is the entire string after the numerical value, with whitespace trimmed - so spaced/not spaced suffix wouldn't matter - defining this rigidly would be ignored by most users, i suspect My proposed table: Unit - Factor - 1 kmh - 1 mph - 1.609 knots - 1.852 Not sure if any other units are in (common) use? Can someone check tagwatch? Tristan 2008/10/14 Matthias Julius [EMAIL PROTECTED] Tristan Scott [EMAIL PROTECTED] writes: If it were up to me (dicatorships are so much swifter to deal with things...) * maxspeed should be the only tag. Therefore you can't contradict yourself/others (or update one to 40mph, or not catching because it's not normal, maxspeed:mph is still 30 you end up with broken data) * mph is the only permittable suffix (or a SHORT fixed list added to map features), therefore parsing is simple. If Mph / MilesPerHour / mp/h / yard/minute / walk / et al is allowed then parsing becomes either impossibly (inf types of value) difficult, or becomes easy (if it's not all numeric, ignore it). The list doesn't need to be very short, but it needs to be defined somewhere. Then, any application that uses the data can be taught how to deal with it. Then Map Features needs to specify that maxspeed is a speed measurement and link to the table of speed units. Then Maplint can be extended to recognize tags that require a speed unit and it can warn if there is none. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
If this catches on not only do we have a well-defined and easily-processed value for speed to use in all manner of things, we also have a template for defining other data types (bridge height? maxweight?) which might (or might not) make the job of the data processor for an map consuming application (satnav etc) much easier. Tristan 2008/10/14 David Earl [EMAIL PROTECTED] On 14/10/2008 18:26, Tristan Scott wrote: Given that SI units are standard across OSM could be define a speed value in addition to Numeric String etc like so: (default to kmh as specified before (also means not adding millions of pointless kmh strings to the db) Factor means multiply by this to convert to SI - interpreters would either use value as-is or multiply by Factor for that suffix to get SI units. Suffix is the entire string after the numerical value, with whitespace trimmed - so spaced/not spaced suffix wouldn't matter - defining this rigidly would be ignored by most users, i suspect My proposed table: Unit - Factor - 1 kmh - 1 mph - 1.609 knots - 1.852 +1. I really don't see what all the fuss is about. It's not exactly novel to do it this way: CSS puts units as part of the value. It's what I've been doing all along, except some pedant comes along and changes it to some incomprehensible decimal number almost as soon as I add them to the map (which means I can carry on doing it that way even if others think differently, as they'll get converted automatically as far as i am concerned and I don't have to think about a magic number in km/h). David -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] vandalism on OSM
I now use itoworld to give me a RSS feed for sessions of updates in my area (or indeed any defined area) Tristan 2008/10/14 Stefan Monnier [EMAIL PROTECTED] Subtle vandalism will always be the hardest to spot. If it is imagined that it might become a problem, then perhaps uploading a change to anything which already existed could notify the last 1 or 2 people that amended that feature, as they are the most likely to know what is correct or be in a position to double check if they doubt what they did previously. This would be very useful indeed. Not just for vandalism. A good diff tool or better a diff API call would be helpful as well. With that you could periodically look over the changes in your area. I have better things to do than keep an eye on the various parts that I changed in the past. That's what computers are for. Which is why I think it'd be *much* better if any change automatically sends a heads-up email to the previous author(s). Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
I've been reading this discussion since it started...
So far I've seen that there's a problem with conflicting values. It seems
that not only is maxspeed=??mph widely used, it's also handily in exactly
the same place as maxspeed=48 (which is what map features told me to do
(..ish, it didn't specify d.p), therefore it's what I did)
I accept the argument that mapping mph values in kmh is a problem as people
use different levels of precision, and also any mapped value is inaccurate.
When I mapped my first maxspeed (ah, sweet innocence since lost) I found
that people seemed to be converting inaccurately (in that they'd trucated
values rather the rounding according to tagwatch) so I added the lookup
table as a canonical guide (30mph is 48kph if the same number of dp are
used).
If it were up to me (dicatorships are so much swifter to deal with
things...)
* maxspeed should be the only tag. Therefore you can't contradict
yourself/others (or update one to 40mph, or not catching because it's not
normal, maxspeed:mph is still 30 you end up with broken data)
* mph is the only permittable suffix (or a SHORT fixed list added to map
features), therefore parsing is simple. If Mph / MilesPerHour / mp/h /
yard/minute / walk / et al is allowed then parsing becomes either impossibly
(inf types of value) difficult, or becomes easy (if it's not all numeric,
ignore it).
I am happy to use 30mph not 48 (which conflicts with map features which
specify kmh and not units..) as it seems a widely-used value and hence
/ought/ to be interpreted by renderers (is it? are any of them?)
Use of the data?
What I had in mind was a satnav, with the user on the way driving along. He
doesn't care what the units are internally, just that the satnav goes bong
when he's over the limit. He might have the units displayed, but they'd be
displayed in whatever format he'd told the satnav to use anyway, and so
again the internal types are irrelevant - as long as they can be
standardised by the parser they're ok.
This use would best fit with kmh values (numbers are much easier to atoi()
than various concatenated value+unit strings) in my view. However. 30mph
to 30 requires some logic by the program.
##I thought that the program being:
waySpeedDisplay = round(atoi(way.maxspeed)*0.621371) #use 1 for kph display
##would be much simpler than the program being
if (sub_string(way.maxspeed,last3chars) == mph)
{
CONV_FACTOR=0.621371
}
else if (not_is_numeric(way.maxspeed))
{
echo you what? #handle other string suffixes too!
}
else
{
CONV_FACTOR = 1
}
waySpeedDisplay = round(atoi(way.maxspeed)*CONV_FACTOR); #divide by 0.621371
for km/h display
I may start mapping mph suffixes instead of kmh values as it seems in wide
use (therefore logically interpretors would handle it) and arguments for it
on this thread seem logical and well-founded to me.
Tristan
2008/10/13 Ed Loach [EMAIL PROTECTED]
Andy wrote:
It's much simpler to parse maxspeed=30mph than it is to work
out which
one is correct when there's multiple maxspeed:[kph|mph]=30
tags, I'd
say. I'd try to avoid having two potentially conflicting ways
of
tagging the same property.
Oh, and changing documentation on the wiki to promote the
least-prevalent method of tagging is bad form! The wiki should
(IMNotVeryHO) be there to document what's in the database, not
promote
particular tagging schemes over one another.
I agree, and I think the changes to the wiki should be at least
reversed, and possibly an additional note added to say many users
append mph to the value where the speed limit is signposted in mph
rather than converting to km/h (as is already noted on the following
page I discovered today, following a link from the maxspeed=none
voting page:
http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Maxspee
d
)
Ed
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
--
Tristan Scott BSc(Hons)
Yare Valley Technical Services
www.yvts.co.uk
07837 205829
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
I added the conversion table to maxspeed, as I do a lot of maxspeed tagging in my area. I read the maxspeed definition as needing a numeric value in km/h. While km/h doesn't mean a lot to me, I does to whatever app I use to draw speed limit signs (or, more likely, whatever app runs a satnav system and informs the user when they're over the stated maxspeed for the way they're on) The maxspeed needs to be computer-readable, so people tagging maxspeed=30 when the wiki states km/h is misleading, to my mind. People tagging as 30mph is fine, as that can be parsed to a consistent value anyway. I think it should be in the database as rounded numeric km/h for the following reasons: 1) 30 mph/30mph/30 all meaning 48 is difficult to parse (or at least, more coding) 2) tagging in floating point is more accurate, but rounding the result to 0 dp seems sensible (I also did that because I didn't know if floating-points were approved in the database) 3) The conversion table is an accurate table to 0dp - some people according to the tags-in-use pages seem to have converted the value inaccurately, so I thought it'd save people doing bad math... (30mph != 50km/h, though if we get converted by europe it might change to that) 4) the wiki says km/h, as as previous suggested it's sometimes (often) unclear which unit was meant by mapper, and which unit is in use where the tag in (international waters/boundaries/ways crossing borders/etc And I'd welcome a sed-like change to the database to fix (imho) the maxspeed=30mph tags (I'd like them consistent. I not too bothered if we store millions of mph strings instead of just using km/h, as long as I can easily parse the data) Oh, and I tend to only tag ways with non-national speed limits on - I assume there's a country-wide default maxspeed per road type (though again the border problem raises it's head) Tristan 2008/10/8 Ed Loach [EMAIL PROTECTED] Mark wrote: Maybe grin this is calling out for a 'bot approach, to take maxspeed:mph add a numeric maxspeed, to check out maxspeed=30's mark them in some way (restricted to UK, obviously), and to check for entries of both=30 fix them? snip +1 on the namespace; I'm not generally keen on it, but here it makes sense. I'd argue that it doesn't make sense, in that if you allow both maxspeed:mph and maxspeed as valid tags, a way may end up tagged with both showing contradictory speed information. It makes more sense to have maxspeed=numberoptional units; assume km/h if none specified to avoid the chance of that happening. It does make sense for other situations, such as if opposite directions have different limits (e.g. maxspeed:opposite=numberoptional units), or if different vehicle types have different limits (e.g. maxspeed:psv=numberoptional units) as these clearly can't lead to contradictory information (assuming that if a vehicle type is specified it overrides any other maxspeed tags). Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] traffic_calming not rendered?
I'm been poking round the area of Enfield Road, Norwich, UK and some of the roads have speedbumps - I have changed the unclassified tags for traffic_calming tags on the highway. Now they're not rendered at all! So my question is that... am I doing anything wrong? Or is the renderer really ignoring a highway tag on a renderable highway? name=Enfield Road highway=traffic_calming traffic_calming=bump Also, someone's changed one back to residential, leaving the traffic_calming=bump value. The road is shown in mapnik and osmarender as a residential road - no traffic_calming rendering visible. http://wiki.openstreetmap.org/index.php/Key:traffic_calming -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - waterways/ditch
the Waterway=Drain tag has this description: A Drain is an artificial waterway used for carrying storm water or industrial discharge. To me, that seems unrelated to the ditches I have in mind: they don't carry storm water - normally the water table won't move much in a storm (at least in the UK) and the ditches stay were they are. They contain natural rainwater or saltwater from the marshes. Secondly, they don't really drain so much as just sit there - the fields around stay wet, the water doesn't really move. They're used as fences as much as somewhere to connect field drains to. here's a pic that seems to illustrate what i have in mind: http://web.ncf.ca/bf250/images/odditch.jpg It strikes me that tagging as drain loses the information that drains are usually empty unless draining something (like a storm) and also tend to be channels for water movement rather than just sort of long thin ponds, though I suppose we must lose information somewhere to avoid tag congestion. Maybe modifying and clarifying the scope of the drain tag would do? Thoughts? Tristan 2008/9/1 Andy Robinson (blackadder-lists) [EMAIL PROTECTED]: Tristan Scott wrote: Sent: 01 September 2008 3:37 PM To: talk@openstreetmap.org Subject: [OSM-talk] [tagging] Feature Proposal - RFC - waterways/ditch This is a request for comments (my first, so let me know if i've done it wrong!) on my waterway/ditch. http://wiki.openstreetmap.org/index.php/Proposed_features/Ditch mainly as there's a large area of marshes around where I live, and the canal waterway tag is completely inappropriate for the still overgrown drainage ditches (too wide to jump, too overgrown and narrow to navigate, and not even remotely canal-like) I can get organised with a picture of the ditch if that's necessary. Note that ditchs are occasionally slubbed out, but every ditch i know of is more than 50 years old - so it's not as if they're seasonal. oh, and they're on Ordnance Survey maps as thin blue lines, if that's relevant. Map Features has always had a waterway=drain tag which was always intended for drains and ditches. I've been using that when I come across one. Cheers Andy -- Tristan Scott BSc(Hons) Yare Valley Technical Services 01603 858441 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - waterways/ditch
Just found a better image to illustrate a ditch: http://www.woodrow.org/teachers/esi/2001/CostaRica/palo_verde1/human-altered/images/ditch2.jpg Tristan 2008/9/1 Tristan Scott [EMAIL PROTECTED]: the Waterway=Drain tag has this description: A Drain is an artificial waterway used for carrying storm water or industrial discharge. To me, that seems unrelated to the ditches I have in mind: they don't carry storm water - normally the water table won't move much in a storm (at least in the UK) and the ditches stay were they are. They contain natural rainwater or saltwater from the marshes. Secondly, they don't really drain so much as just sit there - the fields around stay wet, the water doesn't really move. They're used as fences as much as somewhere to connect field drains to. here's a pic that seems to illustrate what i have in mind: http://web.ncf.ca/bf250/images/odditch.jpg It strikes me that tagging as drain loses the information that drains are usually empty unless draining something (like a storm) and also tend to be channels for water movement rather than just sort of long thin ponds, though I suppose we must lose information somewhere to avoid tag congestion. Maybe modifying and clarifying the scope of the drain tag would do? Thoughts? Tristan 2008/9/1 Andy Robinson (blackadder-lists) [EMAIL PROTECTED]: Tristan Scott wrote: Sent: 01 September 2008 3:37 PM To: talk@openstreetmap.org Subject: [OSM-talk] [tagging] Feature Proposal - RFC - waterways/ditch This is a request for comments (my first, so let me know if i've done it wrong!) on my waterway/ditch. http://wiki.openstreetmap.org/index.php/Proposed_features/Ditch mainly as there's a large area of marshes around where I live, and the canal waterway tag is completely inappropriate for the still overgrown drainage ditches (too wide to jump, too overgrown and narrow to navigate, and not even remotely canal-like) I can get organised with a picture of the ditch if that's necessary. Note that ditchs are occasionally slubbed out, but every ditch i know of is more than 50 years old - so it's not as if they're seasonal. oh, and they're on Ordnance Survey maps as thin blue lines, if that's relevant. Map Features has always had a waterway=drain tag which was always intended for drains and ditches. I've been using that when I come across one. Cheers Andy -- Tristan Scott BSc(Hons) Yare Valley Technical Services 01603 858441 07837 205829 -- Tristan Scott BSc(Hons) Yare Valley Technical Services 01603 858441 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - waterways/ditch
surely width=0.254 given width is defined as being in metres? I've been doing UK speed limits in km/h hoping they'll be marked in mph when the map is drawn (or when i render). Tristan 2008/9/1 spaetz [EMAIL PROTECTED]: On Mon, Sep 01, 2008 at 05:07:32PM +, Chris Hill wrote: I think that a ditch is something I could just about jump over (maybe in my younger days anyway), whereas a drain is wider and possibly navigable. Then use width=10inch or whatever :-O ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services 01603 858441 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
