When adding roads, you don't always know what classification of road it
is (e.g. primary, secondary, tertiary, unclassified, etc). Quite a lot
of people seem to add these sorts of roads as highway=unclassified, with
the idea that these can be fixed in the future when the status of the
road
On Thu, 8 May 2008, Robin Paulson wrote:
alternatively, are there any world wide maps out there with contours
and osm data, that update regularly?
The cycle map and the piste map both have contours for selected areas.
I'm generally doing monthly updates to the piste map data. As far as I
On Thu, 8 May 2008, Robin Paulson wrote:
maybe i'll do it myself; some transparent png laid over the top of the
osm tiles can't be so difficult
Have a look at: http://wiki.openstreetmap.org/index.php/Contours
This tells you how contour rendering has been implemented on the piste map
and cycle
On Wed, 7 May 2008, Martijn van Oosterhout wrote:
Heh. While in london someone tried to explain to me what was so
special about all these crossing types. They have names for crossings
that here in NL would normal. A crossing with a separate light for
bikes, that's like every crossing in NL.
On Tue, 6 May 2008, Andy Allan wrote:
[2] Another brilliant example of how people make themselves feel
useful by doing the trivially easy bit, c.f. tracing from Yahoo with
no intention of naming the roads.
I'm just going to voice an opinion (feel free to ignore it :) - putting
roads on the
I've come across a problem with one of my methods of collecting tracks -
I'm hoping someone might have some input:
I've got a computer in my car which connects to my (old style) eTrex
Venture GPS via a serial cable. The computer runs gpsd to talk to the
GPS. It also runs Kismet which does
On Wed, 30 Apr 2008, Frederik Ramm wrote:
Of course this is very simplistic and I believe you will come up with
much better measures of progress. Let's hear your numbers ;-)
Interesting numbers. I suspect objects per capita would be more
meaningful than compressed bytes though (but more
Chris Hill wrote:
Leaving the namespace issue aside, how would one collect the information
about
climbing routes? The routes I climbed didn't have signs or the like to
gather
from the site. All of the climbing guides I have that describe the routes,
including their name, grade,
elvin ibbotson wrote:
Chris Hill is worried about copyright issues with climbing routes and
this is like lots of concerns I have seen expressed such as taking
street names from actual street signs rather than from copyrighted
material. If it's the name of the street, it's the name of the
On Wed, 23 Apr 2008, Andy Allan wrote:
You are taking what you believe to be true, and applying it to
everyone else.
The same can be said for both sides of this discussion.
If you think there is no clear winner, then shoudn't the established
conventions should take precendence?
There are
On Thu, 24 Apr 2008, Christopher Schmidt wrote:
I can't claim to have the right answer, but I will state that it is not
common in geographic software to have namespaced attributes: in general,
when this is the case, it is a namespace based only on the object type
which has a specific schema.
On Thu, 24 Apr 2008, Christopher Schmidt wrote:
It almost sounds like the proposal is to use namespaces in place of a
'type' property on the object... which I personally think would be a
better way to go than to namespace every tag...
The idea is to make the context of the tag much more
On Thu, 24 Apr 2008, Dave Stubbs wrote:
And if the occupancy is on a fish pond then it likely does
How do you know it's a fish pond? There is no tag that unambiguously
identifies the type of object it is. Instead there is a whole load of
tags to identify the object, and you have to have a
On Thu, 24 Apr 2008, Dave Stubbs wrote:
It would probably have a tag like man_made=fishpond. I don't know
there's a tagging schema for that.
How did you know that the man_made tag defined the context?
Seriously, I've had enough of this.
That's fine, but I'm afraid you haven't convinced me
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote:
For a climbing route it's normally the distance of assent that is of
interest is it not and I guess for most traditional climbing routes this is
known? Much easier to state the length of the route than the top and bottom
elevations?
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote:
The point has been made by others that the namespace here is unnecessary. We
know what length= means here so the climbing namespace is superfluous
because what you are tagging is a climbing route.
I'm aware the issue is contentious, but
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote:
I'll guess we will agree to disagree then. If it works for you ane the other
climbers amongst the contributors then of course you can do what works for
you :-)
I don't think any other climbers have voiced an interest in tagging routes
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote:
Because it was difficult for the layman freeform tagger contributor to
decide what the root class should be, for instance is it class=waterway or
class=river.
I think I'd be inclined to try and make things a bit hiararchical - e.g.
On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote:
As I think AndyA pointed out you are not normally looking at a tag out of
context, e.g. on its own without any of the other tags applying to the same
feature.
The problem is that the context isn't clear since there is no designated
On Wed, 23 Apr 2008, Cartinus wrote:
A machine wouldn't know without a set of rules or a hierarchy.
Isn't part of the point of OSM to produce a data set that _is_ machine
readable? I consider lack of machine readability to be a real problem.
plus it is filled with lots of background
On Wed, 23 Apr 2008, Andy Allan wrote:
You are clearly unwilling to consider the downsides of your
namespacing proposals, beyond pure technical matters
I am trying to think about all aspects of the proposals. However, so far
the only argument against them seems to be that namespaced tag
On Mon, 21 Apr 2008, OJ W wrote:
Perhaps the ele=x
m tag would be useful here - so that if someone actually tries creating a 3D
map of a crag they'll have data to work with...
I'm trying to avoid requiring the ele tag because elevation data is hard
to get (accurately). However, if someone
On Mon, 21 Apr 2008, Tom Hughes wrote:
With the mapnik bitmaps formats, if you assume the bitmap to be
a 96 DPI image then the scale should be what you asked for I think.
It might be worth mentioning this on the export page itself.
In any case, excellent work. I'm going to have to start
On Mon, 21 Apr 2008, Frederik Ramm wrote:
Tiles are 256x256 pixel. If you want decent usability you must
display three columns and three rows and then always pan by +/-1
otherwise the user gets confused. You could try to simply display one
tile but I doubt this will work well.
I think
On Mon, 21 Apr 2008, Francois De Ryckel wrote:
AS I was working on Dhaka (Bangaldesh) I deleted by mistake some nodes
that belong to some coastline drawing Consequences: the whole Dhaka
is now under water! (I know is pretty common but it isn't now the rainy
season ... 2 more months!)
Tom Hughes wrote:
Because the name tag is always the name of an object, regardless of
what that object is (the amenity=pub tells you what sort of object it
is in this case). It is clear to everybody that a name tag is going
to tell you the name of something without having to know anything
On Thu, 17 Apr 2008, Chris Hill wrote:
I simply don't see namespaces as necessary. In this case I'd draw the
building and label it as a supermarket, then add a node for the post office.
This seems a very messy solution to me.
The building is a supermarket, the post office is only part of
On Fri, 18 Apr 2008, Robin Paulson wrote:
structure=pole
highway=bus_stop
amenity=post_box
Ok, but you still have a potential conflict here. Hypothetically, you
could have a timetable tag which applies to both a bus stop (tells you
when busses arrive) and a post box (when is the post
On Fri, 18 Apr 2008, Andy Allan wrote:
Ah, I see the problem. You are taking a tag away from it's context,
and then complaining that the tag has no context on its own. Only part
of your argument is based around conflicts, but the rest seems to be
context.
Yes, it's a bit of both - I think
There isn't much guidance on how the sport=climbing tag should be used
when dealing with outdoor features. What exactly should be tagged with
sport=climbing? Possibilities include:
* The crag (probably a node, or maybe a way following a cliff, or an
area)
* The start locations of
On Thu, 17 Apr 2008, Nick wrote:
It's worth noting that in terms of climbing grades there are plenty of
different systems worldwide to allow for:
Yes, I was considering having a tag for each. e.g.:
climbing:grade:british:adjectival=VS
climbing:grade:british:technical=5b
On Thu, 17 Apr 2008, Andy Allan wrote:
And full of frigging namespaces.
Yes - I consider this a Good Thing.
Please, please don't let the stupid Piste namespacing infect your
brain and make you wander round with a namespace-hammer looking for
new tagging-nails.
I'm afraid I consider the
On Thu, 17 Apr 2008, Chris Hill wrote:
The only person likely to tag climbing routes is someone who
understands climbing routes ;-)
What about someone just trying to interpret the data stored in OSM's
database? It should be obvious what the data is, without having to start
looking stuff up
On Thu, 17 Apr 2008, Ben Laenen wrote:
There's currently no way to properly tag those kind of restrictions,
unless I've missed something...
Maybe what is needed to satisfy everyone is *optional* namespaces - if you
don't specify a namespace then it is assumed to apply to all of the
I'm attempting to trace some of the Gower coastline from the (very fuzzy)
Yahoo images. But I'm not sure how to tag beaches made up of flat rock.
For example, the type of thing shown by this Google aerial view:
On Mon, 14 Apr 2008, Stefan Baebler wrote:
natural=scree perhaps?
Scree refers to steep slopes covered with loose stones - this is
(very uneven) horizontal solid rock.
- Steve
xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/
Servatis a periculum, servatis
On Mon, 14 Apr 2008, Matt Williams wrote:
From the proposal at
http://wiki.openstreetmap.org/index.php/Proposed_features/Water_cover it
seems that natural=beach, surface=rocky (or surface=rock?) and optional
water=tidal tag if you feel like it :)
Excellent - that seems to be a good answer,
On Mon, 14 Apr 2008, Chris Hill wrote:
High and low water marks vary every day, the height of the tides vary a
lot..
Correct - anyone who records high and low watermarks on maps/charts will
be using the highest and lowest astronomical tides, not the high/low tide
of an arbitrary day.
Most
That's rather unexpected:
http://geo.topf.org/comparison/index.html?mt0=googlemapmt1=mapniklon=-122.084187lat=37.42216z=17
:)
- Steve
xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/
Servatis a periculum, servatis a maleficum - Whisper, Evanescence
On Thu, 10 Apr 2008, maning sambale wrote:
Well, they do censor their images,
http://en.wikipedia.org/wiki/List_of_places_blurred_out_on_Google_Maps
Why not, in their streetmaps?
Dunno.. I just didn't expect them to censor their own offices from their
own map :-/
- Steve
xmpp:[EMAIL
The only thing I can see in the wiki for tagging crags is sport=climbing -
has anyone been tagging any crags with more information? If so, what tags
are you using?
- Steve
xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/
Servatis a periculum, servatis a
On Tue, 8 Apr 2008, Niclas Andersson wrote:
I've always used a node in the way to represent a bus stop. This works
fine when there's a stop on each side of the road. Otherwise I've made
use of the bus_direction=(N|S|E|W) tag (from
http://wiki.openstreetmap.org/index.php/Buses ) on the node to
On Tue, 8 Apr 2008, Cartinus wrote:
Up till now I used the node in the road method. But lately I have been
thinking about how routing applications would use osm data. I doubt bus
companies will be using osm to route their busses. But when routing for
pedestrians, you will want to be able to
On Wed, 9 Apr 2008, Steve Hill wrote:
I think this is the one I was thinking of: http://www.transportdirect.info
No, sorry, it was probably http://www.traveline.org.uk/
- Steve
xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/
Servatis a periculum, servatis
On Tue, 8 Apr 2008, Lester Caine wrote:
How DO we currently identify all roads in the UK, so
that we don't end up with some of the simply silly links that the likes of
Autoroute returns when asking for a location.
We need a consistent UNIQUE index method that will allow all 'ref=M11'
How are people tagging bus stops? I have been setting tagging nodes that
are members of the way, which means they are part of the road they are on.
Is this the right way to do it? It seems right since it unambiguously
shows which road the stop is on, but it doesn't allow any indication as to
On Tue, 8 Apr 2008, Robert (Jamie) Munro wrote:
You don't think that searching for M11 should produce one result for a
road that covers the whole country, and searching for high street should
produce hundreds of separate results?
But a motorway which is not a continuous road (i.e. has gaps in
On Tue, 8 Apr 2008, graham wrote:
I have mapped quite a few bus stops where the bus stop is on a pedestrian
island and I want to show not only 'side of road' but also a fairly exact
physical position. I'd be reluctant to give that up to plonk all my bus stops
in the middle of the road...
On Tue, 8 Apr 2008, Andrew McCarthy wrote:
(2) A relation for that road's notional route, that contains the
relation above *plus* the (usually obvious) connecting bits that give
you a single, long distance route from A to B.
Which bits you use to connect the disjointed sections are a rather
Maplint seems to be throwing up not-in-map_features warnings about stuff
that is on the Map Features page. For example:
http://www.openstreetmap.org/?lat=51.68309lon=-3.91837zoom=15layers=0BTT
There are warnings for the direction=clockwise tags on mini roundabouts,
power=tower nodes and
On Tue, 8 Apr 2008, Andrew McCarthy wrote:
In that case, would the use of highway relations be restricted to such
cases where there is one *official* route, with differing refs?
Official by whose authority? I am not aware of the UK highways agency
publishing official routes for these gaps
On Tue, 8 Apr 2008, Andrew McCarthy wrote:
It's specified in the Statutory Instrument issued by the Government.
I've no idea if we're unique on this, but it's a big planet :)
Sounds like ref=M7;N7 is the correct thing to do in this case then. As
for what the renderers should do, that's
On Sun, 6 Apr 2008, Richard Fairhurst wrote:
In the UK, road numbers are unique (apart from about three cases
where local councils have cocked up, e.g. the B4027)
This isn't entirely true - take, for example, the A31, which goes from
Guildford to Winchester and then vanishes as it joins the
On Mon, 7 Apr 2008, Frederik Ramm wrote:
Which will omit anything tagged ref=B4027;B4028 or some such. Ok you
said there shouldn't be any of those in the UK anyway so I guess
you're fine...
Then the API needs to be improved - we shouldn't be adding unnecessary
data to work around
On Mon, 7 Apr 2008, David Earl wrote:
And to take the A11/A14 example again, if the A11 in effect disappears
where it is coincident with the A14, the A11 is discontinuous.
I'm not sure why we need to treat the whole discontinuous A11 as a single
road.
In this example, as far as I can tell we
On Mon, 7 Apr 2008, Frederik Ramm wrote:
If it's done consistently, one can still create relations automatically later
if desired.
But this is kind of the point - if you are able to automatically create
the relations (and presumably automatically fix them if someone makes the
way tags
On Mon, 7 Apr 2008, Frederik Ramm wrote:
I assume it will usually be easier to check a machine-readable relation than
to compare tags.
Possibly. There may be cause for having machine generated relations which
are kept up to date by the server when data is committed so the people
editing
On Mon, 7 Apr 2008, Stephen Gower wrote:
Suppose I wanted to walk the whole of the A34 while I was 34 as a
charity gig?
Ok, either:
1. You have lots of ways tagged with ref=A34
2. You have lots of relations tagged with ref=A34, one for each
discontinuous section of the road (which may be
On Mon, 7 Apr 2008, Robert (Jamie) Munro wrote:
It might not be the A11 from the point of view of who is in charge of
maintaining it, but it is the A11 from the point of view of someone
following the route of the A11 to get somewhere. Therefore it should be
in a relationship as part of the
On Mon, 7 Apr 2008, Robert (Jamie) Munro wrote:
It's not subjective, it is officially signed - the signs say A14
(A11). This happens all over the place in the UK A roads network.
Don't road numbers in brackets generally mean leads to rather than part
of?
I can't see how you can argue that
On Fri, 4 Apr 2008, Frederik Ramm wrote:
Great to see that the work is being put to other uses! (Meanwhile I had
to order a second print run of the German flyer as the first 5,000
copies are already gone!)
Has anyone handed these out to random members of the public yet? I'm
interested in
On Thu, 3 Apr 2008, David Janda wrote:
It appears to me that the name_old tag is meant for one name. But what
to do if there are several? I am against the idea of name_old1 name_old2
and so on as these names I am refering to are in many cases so old that
the order is not known.
The
On Wed, 2 Apr 2008, OJ W wrote:
Tagging notes/discussion is at:
http://wiki.openstreetmap.org/index.php/Talk:Tag:man_made%3Dlighthouse
If anyone has comments on the tags etc, then please do join the discussion
I've put together a bare-bones proposal for tagging buoys:
On Thu, 3 Apr 2008, Steven te Brinke wrote:
Besides that, IMO starboard and port are not a good way to specify the type
of a buoy. That is because in the Netherlands buoys are placed in the
downstream direction, with green at the port side. However, at sea they are
placed towards land,
On Wed, 2 Apr 2008, Iván Sánchez Ortega wrote:
I think some variation on the access tag make more sense, if only
'access=dry_season'.
Good idea.
Afterall the road/route is always there (ie. not
intermittent), it is just not passable with normal vechiles.
The *water* on the road *is*
On Wed, 2 Apr 2008, Iván Sánchez Ortega wrote:
water=tidal and water=seasonal, then??
Sounds good to me, possibly with an optional qualifier tag such as:
water:tidal:height=4(flooded by tides 4m above datum)
water:seasonal:dates=09/01-03/31(flooded September 1 - March 31)
-
On Sun, 30 Mar 2008, Cartinus wrote:
Almost nobody would accept it if we suddenly had to use railway:name=,
highway:name=, etc. on all ways just because there are some places where
people want to tag the street and the the tramway on the same way object.
What you'd need is a solution that
On Fri, 28 Mar 2008, Frederik Ramm wrote:
and you can also limit the
length of these GPS connection lines (draw.rawgps.max-line-length=x,
in metres), for those cases where you get crazy zig-zagging.
I had noticed a while ago that JOSM appeared to handle GPX files
incorrectly (and
On Fri, 28 Mar 2008, Frederik Ramm wrote:
I'll investigate that. However with data retrieved from the server, you don't
even get the trkseg structure, you just get a ton of individual points and
have no chance of finding out whether they belong to the same segment or not!
Ouch - I hadn't
On Fri, 28 Mar 2008, Frederik Ramm wrote:
* It is now possible to have arrows on the lines connecting GPS
points (draw.rawgps.direction=true),
I'm seeing a couple of slightly odd things with the GPS direction arrows:
(screenshot) http://www.nexusuk.org/~steve/josm-gpsarrows.png
They
On Fri, 28 Mar 2008, Frederik Ramm wrote:
Are you saying every single arrow points the wrong way? Because that would be
an easy fix to make ;-)
Yes, seems to be the case :)
This happens when lines of length 0 are drawn. I suspect that those tracks
that suffer from the east arrows have
On Fri, 28 Mar 2008, Steve Hill wrote:
Are you saying every single arrow points the wrong way? Because that would be
an easy fix to make ;-)
Yes, seems to be the case :)
To complicate things more, the direction arrows on data imported from a
local GPX file are the right way around, so
On Thu, 20 Mar 2008, elvin ibbotson wrote:
Treating contours as shape files seems to me to be heavy on storage,
downloads and processing. I have made a proposal in the wiki at
http://wiki.openstreetmap.org/index.php/Relief_maps#a_proposal to use relief
shading as a background to mapnik
Just a quick follow-up with some numbers for disk space usage for those
interested. I had a go at importing 10 metre contour lines for the whole
of Eurasia into PostGIS - latitudes of 0 - 46 degrees North required about
110 gig of disk space for the Postgres table and amounted to around 105
On Tue, 18 Mar 2008, Martijn van Oosterhout wrote:
I looked at the code the other day and it seemed rather inefficient.
Fixing it will be a PITA though...
Would be very nice though, I'm think of looking into it when I have time...
I was pondering rewriting it from scratch with the aim to
Contours layer presented by openpistemap is simply great. Does it
exist a server publishing only this layer?
I'm not sure how that would work - you really need the contours data set
to be the bottom layer, with the normal layers on top of that (is it
possible to ask OpenLayers to render the
On Mon, 17 Mar 2008, Dave Stubbs wrote:
There's also the amount of time it would take to render the tiles. It
takes over 15 hours to render the contours used on the cycle map, and
all things considered that covers a very small % of the planet surface
at any kind of decent zoom level. It's a
Dave Stubbs wrote:
it's faster to just let it use swap,
I I/O load hits my server pretty hard. Trying to do anything else while
that's happening is quite painful. :-/
Doing it without the heavy I/O load is preferable, even if it takes a
couple of days - it can just trundle away in the
101 - 178 of 178 matches
Mail list logo
