I've noticed some people have tagged bridges with height=*, rather than tagging
the road way under the bridge as maxheight=* and I'm kind of unsure which is
better.
By using height you don't have to break the way under the bridge up, on the
other hand maxheight is specific to the road under th
--- On Mon, 27/7/09, Liz wrote:
> maxheight expresses a height limit for using the way to
> which the tag is
> added. If no unit is included, the value is assumed to be
> in metres.
>
> You get to break up the way and mark it as maxheight
I'm just trying to make other people's entries thing
And the bridge in question is a rail bridge with over head wires, the height
bit is clearance under the bridge.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
--- On Mon, 27/7/09, Martin Koppenhoefer wrote:
> but be careful not to break things up. Maxheight could be
> valid for
> the way on the bridge itself as well.
Yup, the height is someone's attempt to do maxheight, not mapping the clearance
or height of the bridge...
In this case height=2.9m :
--- On Mon, 27/7/09, Paul Houle wrote:
> OSM could replace, perhaps even
> surpass, the street maps in a
> product like City Navigator, but I'm thinking about
> the business
> listings. It seems to me that a free product could be
> provided on a
> basis similar to the Yellow Pages:
--- On Mon, 27/7/09, Iván Sánchez Ortega wrote:
> Well, I expect that information to be covered by different
> licensing terms in
> different countries. After all, OSM has a lot of experience
> bashing
> government agencies to get copyright-free map data.
In Australia in Telstra won a lawsuit
I think everyone is thinking of this in one of 2 ways, it's either an attribute
of the bridge, or a restriction of the way under the bridge.
The maxheight tag looks like it was aimed as a restriction tag, the way below
the bridge is restricted if you are above or close to X metres you will need
--- On Tue, 28/7/09, Roy Wallace wrote:
> Agreed. And it's clear that both ways of thinking are
> probably valid.
As of time of writing maxheight is the only valid one and I don't think we need
or should have 2 tags to indicate the same thing in 2 different ways.
> Can you please explain ex
--- On Tue, 28/7/09, Roy Wallace wrote:
> Ah, perhaps our difference in opinion stems from our
> different
> perspectives - your emphasis on "when I travel" vs my
> emphasis on,
> perhaps, "when I look at a map", or "when I conceptualise
> the world".
That was the basis of the 2 sets of logic,
--- On Tue, 28/7/09, Roy Wallace wrote:
> I would at least suggest that - if maxheight is applied to
> a node, as
> you suggest - the node should be *shared* by the bridge
> (way) and the
> way passing under. This makes it clearer that maxheight is
The problem with this is that 2 ways sharing
--- On Tue, 28/7/09, Roy Wallace wrote:
> Um...the way would also be "close proximity to the bridge",
> because it
> passes under it... I don't see how finding a "node near a
> bridge" is a
> particularly elegant solution. And by random I mean the
> particular
> node you choose would be arbitrar
--- On Tue, 28/7/09, Roy Wallace wrote:
> I'm starting to like this idea. But the problem with this
> is how to
> define "that section of way", so as not to introduce a
> maintenance
You really don't want to pull on that thread, the same can be said for bridges
or virtually any other reason a
--- On Tue, 28/7/09, marcus.wolsc...@googlemail.com
wrote:
> 2)
> Not only bridges have maxheight but also parking-lots,
> tunnels, ...
and trees even if they aren't explicitly signed.
http://www.mirror.co.uk/news/top-stories/2008/05/20/shocked-witnesses-describe-horror-bus-smash-115875-20423
--- On Tue, 28/7/09, Maarten Deen wrote:
> But there is no way to determine if a particular GPS track
> is outdated. Sure,
> you can look at the map and say "I don't see a physical
> road for this track",
> but how would you identify GPS points of a track that is
> invalid? Especialy
> for the a
--- On Tue, 28/7/09, Liz wrote:
> please , don't drop data
> for many areas we are lucky to have one trace and it may be
> a year or more
> before another mapper goes back there
>
> consider having access to older data in separate sets if
> there is concern
> about using old gps tracks, just
--- On Tue, 28/7/09, Simone Cortesi wrote:
> GPS are becoming more precise. older tracks are, on a
> general basis,
You can't make assumptions of the quality of the data based simply on how
recently it was added, someone might be using an old piece of GPS kit they were
given as a hand me down
--- On Tue, 28/7/09, Roy Wallace wrote:
> For maxspeed (your example), the restriction should be
> applied to the
Exactly, you may have to break a way up to apply maxspeed tags to several
different parts of what was originally a single way. Exactly the same as a
bridge, it is part of longer
--- On Tue, 28/7/09, Simone Cortesi wrote:
> I'm talking in the long run. Not something to be done in
> the coming
> moths. Still we are just 5 years old. And not many roads
> did change
> shape in this short period of time.
Some areas have lots of road duplication construction within 5 years o
--- On Tue, 28/7/09, Maarten Deen wrote:
> That is not indicative. A road could remain unchanged for
> the last 100 years
> or could have been demolished last year. What would be the
> expiration time of
> a track? And would you be prepared to lose correct GPS data
> to do this?
Also as Liz put,
--- On Tue, 28/7/09, André Riedel wrote:
> > What about those information offices that exist on
> estates where they try and sell you a block of land and/or a
> house, sometimes a demo house is used as an office, but I've
> seen little shacks put up as well.
>
> Because of information=* is a ch
--- On Tue, 28/7/09, René Affourtit wrote:
> Maybe it's an idea to allow users to specify an area where
> traces are outdated?
>
> So when a junction is reconstructed a local user can place
> a bounding
> box over that junction and all GPS points in that box are
> marked as
> outdated (or delet
--- On Tue, 28/7/09, André Riedel wrote:
> Radio with actual trafic information often found at the
> beginning of a tunnel
> radio:traffic = 92.4 MHz
Some tunnels broadcast across the entire FM radio range if there is accidents
and instructions to motorists. Not sure about AM, possibly that
--- On Tue, 28/7/09, Ævar Arnfjörð Bjarmason wrote:
> * The data is versioned, and anyone can edit it
> I have a lot of GPX tracks that could be improved, e.g. by
> deleting
I'd say deleting sections, but not editing... Only very erroneous information
should be "touched up" by deleting inform
Is there a real need for is_in tags or have admin boundaries replaced the need?
It seems there is a lot of redundancy going on for example node id = 17652780
aeroway = aerodrome
closest_town = Newcastle, New South Wales
ele = 9
iata = NTL
icao = YWLM
is_in = Australia, NSW, New South Wales
name
--- On Tue, 28/7/09, Shaun McDonald wrote:
> Admin boundaries are the new way of doing this. The is_in
> tag was the early way of trying to show a hierarchy of admin
> areas.
Ok, so is_in is redundant.
There was talk on the dev list about removing a bunch of tiger tags from nodes.
Should oth
Perhaps the more appropriate question would be what are appropriate tag keys
that could be used in combination with the tag place=*?
So far all I can come up with is name and possibly source. I'm primarily only
looking at aussie data so I may have over looked things.
is_in seems to have alread
--- On Tue, 28/7/09, David Earl wrote:
> It is still *very* helpful to have is_in present though. It
> is much easier to present this information in a search than
> to do polygon tests which requires a whole new algorithm
> (desirable though that is), and of course, boundaries are
> nowhere nea
--- On Tue, 28/7/09, David Earl wrote:
> But until we do, the existing mechanism does no harm, and
Apart from massively bloating the database due to massive amounts of redundant
and/or useless information that doesn't gain us anything.
> as I said, you don't always know the boundary while you
--- On Tue, 28/7/09, andrzej zaborowski wrote:
> What if boundary is not defined but the hierarchy is
> defined, such as
> with post codes? Should people invent boundary
> polygons based on just
> what nodes/ways belong to the area? I hope not.
Why spend just as much time tagging every node,
--- On Tue, 28/7/09, Shaun McDonald wrote:
> Only use the is_in tag on the place nodes rather than every
> node.
Why?
The reasoning I've been given so far is for routing, but to find such
information routing software would have to look at all nodes near by until it
found the node tagged wi
--- On Tue, 28/7/09, Donald Allwright wrote:
> (I'm not volunteering to write the checker, but I would
> certainly be willing to spend time looking at any errors
> thus detected).
This came up because I've started writing a checker to find certain tag
combinations and one thing I kept seeing o
--- On Tue, 28/7/09, andrzej zaborowski wrote:
> Both for the time spent tagging and space used in database,
> perhaps
> there might be some saving from using polygons but it
> depends on the
> exact scenario. Either way, don't add the tags you
I doubt I can agree that using polygons would use
--- On Tue, 28/7/09, David Earl wrote:
> We can give ourselves a helping hand here if we keep
> is_in.
That's assuming the information contained in it is useful to begin with, as I
keep stating the information I've seen is inconsistent so that's not helping
any one.
__
--- On Tue, 28/7/09, MarkS wrote:
> We need to be careful about removing tags because it could
> cause
> renderers to fail (or at least not work as expected). For
> example, I
> think the is_in tag is added after the place name in mkgmap
> when
> creating the "city" POIs.
That's fine for exis
--- On Tue, 28/7/09, Andy Allan wrote:
> Let's stop the is_in debate - yes, they are useful to data
> consumers,
> no, they shouldn't be in OSM itself, and no, nobody has yet
> stepped up
> to sort it out.
U I am stepping up to sort it out, at least for some parts of the
world, I was
--- On Tue, 28/7/09, andrzej zaborowski wrote:
> Data being wrong is a moot point, it doesn't speak for
> either is_in
> tags or boundary polygons and neither help make data more
> correct
> really.
data being stored consistently is the point.
___
--- On Tue, 28/7/09, MarkS wrote:
> I'm not against getting rid of is_in, I just think we need
> to manage the
> change over a fair period of time to give the renderers a
> chance to
> catch up.
It's irrelevant if place nodes don't already have is_in and instead of adding
is_in tags we sho
--- On Tue, 28/7/09, David Earl wrote:
> If there's errors in them, I don't see the difference
> between those and any other errors in the map.
Maybe someone was trying to do something about error, and maybe it just
happened to turn into this debate?
_
--- On Tue, 28/7/09, David Earl wrote:
> I don't see why you think people entering boundary data
> will be more consistent than in entering anything else - we
> have huge inconsistencies all over the place. Our method of
> tagging encourages it.
Because in "theory" there will be less boundari
--- On Tue, 28/7/09, andrzej zaborowski wrote:
> One of the two ways to indicate belonging to an area should
> not be in
> OSM, agreed. Why's this the is_in tags, is the final
> rationale the
> space saving?
By using boundaries you can effectively tag every node, way and relation with
is_in.
--- On Tue, 28/7/09, andrzej zaborowski wrote:
> No no, I wasn't talking about ways crossing a postcode area
> boundary.
> Just two ways crossing one another belonging entirely to
> different
> divisions each and where do you invent the boundary
> then. Possibly
> this is not found in Australia
--- On Wed, 29/7/09, Martin Koppenhoefer wrote:
> Well, I would tag them completely differently. It is a
> different kind
> of object, it is not a Motel where you just pay according
> to a
> different fee system / business modell.
There is a tag for brothel in the system already
--- On Wed, 29/7/09, Pieren wrote:
> the other examples are very questionable :
> "traffic_sign=maxspeed:30"
That does look questionable if for no other reason that maxspeed should be used
consistently so routing doesn't have to look for 50 different tags or parse all
tags looking for those wi
--- On Wed, 29/7/09, Roy Wallace wrote:
> To me, that looks like somebody is marking *the sign*, as
> opposed to
> marking *the maxspeed restriction*. Seems fine to me -
> because the
> sign does physically exist on the ground - but the
> restriction should
> also be mapped, using maxspeed=30.
--- On Wed, 29/7/09, Aun Johnsen (via Webmail) wrote:
> I have made a proposal for a tag
> marking physical clearance over roads, this because it is
> not the same as legal restrictions on height, and in many
> countries have a different sign warning the driver that he
> might not be able to p
--- On Thu, 30/7/09, Florian Lohoff wrote:
> Probably a maxspeed:forward=50 + maxspeed:reverse=100
> or something - How does this combine with wet and probably
> even
> vehicle based limits ... maxspeed:forward:motorcycle=50
I've been setting maxspeed to the lowest value and then setting
maxs
--- On Thu, 30/7/09, Aun Johnsen (via Webmail) wrote:
> much more. Since many countries have two different signs
> for max legal
> height and max physical height, and its usages can be very
> different, why
> not allow this in tags?
So why not just use maxheight=* and maxheight:legal=* ?
> By
--- On Thu, 30/7/09, Martin Koppenhoefer wrote:
> > Maybe the big tricycle is needed to lift the cameras
> up above the traffic?
>
> I guess they are recording in higher resolutions. The
> problem with
I don't know what res street view in general is but you can't read most signs.
Some of th
--- On Thu, 30/7/09, Aun Johnsen (via Webmail) wrote:
> > You also mentioned sailboats under bridges, are you
> planning to update
> the
> > clearance 24 hours a day, 7 days a week as the tide
> goes in and out?
> You are clearly not familiar with the term "free sailing
> height" which
> refer
--- On Thu, 30/7/09, Liz wrote:
> "at a given time."
> (we have reduced maxspeed in front of schools depending on
> time, day and
> whether it is term time)
There are other roads that have variable limit speed signs and they can change
at any time.
There is also changes in speed limits dur
--- On Thu, 30/7/09, Lennard wrote:
> And in my own jurisdiction: to be able to set maxspeed=none
> for bicycles
> when there is no explicit maxspeed sign. :D
bikes have the same speed limits here as every other thing on wheels, and even
horses for that matter, and you can get tickets like a
--- On Thu, 30/7/09, Martin Koppenhoefer wrote:
> actually even though the definition in the wiki might not
> specify it
> unambigously and explicitly the current use of maxheight
These things should be explicitly stated, otherwise people interpret it
differently :)
> (as discussed
> intens
--- On Thu, 30/7/09, Aun Johnsen (via Webmail) wrote:
> will continue on my proposal. Without any clearification on
> the existing
> tag, than it will be more confusing than adding new tags. I
> have atleast
> stated in the definition of the tag how it is to be used.
No, 2 completely differen
--- On Thu, 30/7/09, Lennard wrote:
> In that case, your 100/100/40 example is easily collapsed
> into maxspeed=100.
>
> Let's see ... Hey, that's the current tagging scheme,
> already! Why did we
> need a change? :-)
Current GPSr's are only capable of knowing within 10m, most lanes are 2-3m, s
--- On Thu, 30/7/09, Aun Johnsen (via Webmail) wrote:
> If this is your suggestion to solve this, than I suggest
> you do something
> about it and get that information on the maxheight
> documentation. I am not
> sure how you intend this to be done. When you have a
> process going, point
> me th
--- On Thu, 30/7/09, si...@mungewell.org wrote:
> >> What's wrong with it? Where's the exact line
> dividing looking with
> >> naked eye and filming?
> >
> > I think that the difference here is that they make the
> images available
> > for others to view. There can be a great difference
> bet
--- On Thu, 30/7/09, Tobias Knerr wrote:
> It's basically there to decide whether to use colons as in
> your example
> or switch to something like
> maxspeed[wet][forward][motorcycle]. Why?
> Well, because those time conditions tend to have colons in
You split based on the equal sign and it d
> You split based on the equal sign and it doesn't matter
> that the time condition or key uses colons.
Actually you don't have to, key values and key tags are stored independently of
each other, writing it with an equal sign is simply a way of describing it and
has nothing to do with how thin
--- On Thu, 30/7/09, Martin Koppenhoefer wrote:
> - residential roads (just in residential areas, no
> connecting
> function, you will not take this if you don't live in the
> area)
> - unclassified roads (not clear, there are voices that they
> don't
> exist in urban areas, I personally use t
--- On Thu, 30/7/09, Roy Wallace wrote:
> different". This, I would argue, is a reason to allow for
> the
How much does the physical height exceed the legal height in most cases?
> possibility to differentiate between maxheight:physical
> and
> maxheight:legal.
If maxheight already implies t
--- On Thu, 30/7/09, OJ W wrote:
> I put a wrapper around the rather
> excellent
> http://wiki.openstreetmap.org/wiki/OSM_Server_Side_Script
> which can
> tell you which town/county/state/country something is in:
I haven't looked at the script but it doesn't cope well with US locations at
al
--- On Thu, 30/7/09, Roy Wallace wrote:
> This is difficult to answer. For a way passing under a
> bridge, I would
> argue the limitation is (semantically) a physical one and
> not a legal
> one.
I assume it would be legal in many countries and would use it as such to
recover money to fix br
--- On Thu, 30/7/09, Aun Johnsen (via Webmail) wrote:
> For countries that have different signs for legal maxheight
> and physical
> maxheight, you can have a section of road preventing tall
> vehicles from
> passing, but they can still legally enter the road (and get
> stuck?!?). In
So wouldn'
--- On Thu, 30/7/09, Aun Johnsen (via Webmail) wrote:
> insurance companie how to deal with it. They both should
> give the same
> advise to the driver (find a different road if you are too
> tall).
Exactly, so you only need to place the lower value to discourage stupidity...
> And many more,
--- On Thu, 30/7/09, Martin Koppenhoefer wrote:
> it's a different meaning in urban areas as in rural areas.
> Many of
> what you tag as primary and secondary in rural areas
> (especially low
> density ones) has 2 (1+1) lanes, while in a
> metropolitan area will
> very often be at least 2+2.
--- On Thu, 30/7/09, Martin Koppenhoefer wrote:
> From: Martin Koppenhoefer
> Subject: Re: [OSM-talk] [tagging] Feature Proposal - RFC - Clearance
> To: "Cartinus"
> Cc: talk@openstreetmap.org
> Date: Thursday, 30 July, 2009, 10:42 PM
> 2009/7/31 Cartinus :
>
> > When using maxheight / maxh
--- On Fri, 31/7/09, Lester Caine wrote:
> But the point I was trying to make was more that of 'We get
> stopped and told
> we have to ask permission' while Goggle stick two fingers
> up and just carry on
> regardless. It is about time there was a level playing
> field, and just because
> one
--- On Fri, 31/7/09, Lester Caine wrote:
> more inclusive than is necessary. So from my perspective
> they ARE
> intentionally going out of their way to invade privacy by
> showing views that
> are simply not normally visible? If we want to see what is
> over a wall we can
> now go to googl
--- On Fri, 31/7/09, OJ W wrote:
> add a mode tag to see what the [[OSM
> Server Side Script]] is returning
> for each one:
>
> http://dev.openstreetmap.org/~ojw/WhatCountry/?lat=-33.87&lon=151.21&mode=raw
>
> in this case, the only state information seems to be in the
> "Is_In"
> tag on the
--- On Fri, 31/7/09, Maarten Deen wrote:
> Two boundary relations is also the way to map the
> Australian example.
I actually merged boundaries because there was 2 slightly wrong ones and I made
one correct one from them both.
Using a relation for the state boundary information seems like a
--- On Fri, 31/7/09, Aun Johnsen (via Webmail) wrote:
> No, you can only ASSUME that the current maxheight only use
> the legal form.
> Have you counted usages in countries where the physical
> maxheight are
> signed? Do you even know which countries such signs are
> available? Without
> any stat
--- On Fri, 31/7/09, Tobias Knerr wrote:
> It has been suggested to add them to the value instead, but
> you will
> always need to deal with substrings of either key or value
> string.
Since other values already incorporate time as a value this would make the
proposal more consistent.
--- On Fri, 31/7/09, Greg Troxel wrote:
> were that important it probably would be bigger. If
> you are about
> #lanes, there's a lanes tag for that.
Does any renders currently use the number of lanes to vary the outputted
images, or should this be something submitted as a wish list, that n
--- On Fri, 31/7/09, Martin Koppenhoefer wrote:
> Please check your 42 occurrences, whether they are physical
> or legal
> and this issue would be resolved.
Some of us are in Australia and there will only be one sign posted in Australia
which is the legal height, but the person you are respon
--- On Fri, 31/7/09, Martin Koppenhoefer wrote:
> Well, I just see it as a hierarchical line:
> residential
> unclassified
> tert
> sec
> prim
> trunk
> motorway
>
> it's simple as that, and I don't see any problem.
Maybe to you, but I don't see it that way based on reading the english langu
--- On Fri, 31/7/09, Martin Koppenhoefer wrote:
> I don't know where you are mapping and which streets you
> are mapping
Sorry, I was thinking of the Australian guidelines...
http://wiki.openstreetmap.org/wiki/Australian_Roads_Tagging
> Well, I'm in Italy but occasionally also mapping in
> Ge
I'm currently trying to do up a flier to promote a mini-map event, and I
wondering if I would be able to use a couple of images from SteveC's key note
talk?
Specifically the 20 live 20 minutes from somewhere example given.
Those images were really striking in showing the benefits that can be g
--- On Fri, 31/7/09, Matthias Versen wrote:
> We usually Tag only the "highest" (1=highest) admin_level
> on a border in
> Germany because an admin_level=2 (country) border is always
> the same
> border for the lower admin_levels.
> The different admin_levels have of course always their own
--- On Fri, 31/7/09, Martin Koppenhoefer wrote:
> areas, that's why your aussie-way might produce slightly
> worse routing
> results (don't know, just an idea).
The navit routing engine prefers residential to tertiary in some cases... So
not all poor routing is because we use unclassified for
--- On Fri, 31/7/09, Matthias Versen wrote:
> > I also checked the Australian state borders and they
> are marked as admin_level=4;10 which may interfere with
> things if the script was only looking for a single number,
> however the boundary is used for local and state.
>
> We usually Tag on
--- On Sat, 1/8/09, Martin Koppenhoefer wrote:
> Which are those cases? Maybe the tertiary was not
> connected? Did you
> check the map data in the area? Usually bad routing results
> come from
> bad map data ;-)
Yup, the map data was correct, navit just did weird things and unclassified
roads
--- On Sat, 1/8/09, Martin Koppenhoefer wrote:
> OK, but actually this is a navit bug then, because I hope
> we all agree
> that a tertiary road should be prefered to a residential
> road in
Yes it was a bug and I filed a bug about it in their bug tracker.
> routing. Still I encourage you to c
--- On Sat, 1/8/09, Liz wrote:
> A long standing convention on a printed Australian map is
> that a road which is
> unsealed is drawn with a broken line of the same colour and
> width as the road
> would have if it was sealed.
That is to do with rendering, not how the data is stored, and ther
--- On Sun, 2/8/09, Liz wrote:
> I expect some equally picky person to tell me that "this is
> not the JOSM talk
It's the talk-au list ;)
> list" but before annoying everyone on that list, I thought
> that which is the
> preferred tag should be decided.
JOSM has numerous tags that aren't
--- On Sun, 2/8/09, Blaž Lorger wrote:
> I also propose extending instructions for road
> classification to use width tag
I agree with everything else you wrote except width since I really don't want
to get a tape measure out and measure widths of roads, using lanes=* to
estimate widths wou
--- On Sun, 2/8/09, Blaž Lorger wrote:
> Unfortunately lanes only specifies number of lanes. In
> general every road that
> is not one way has at least 2 lanes, even if it is narrow,
> say 3.5 meters.
Even one way roads can have multiple lanes. Like dual carriage ways :)
> Some good practices
--- On Sun, 2/8/09, Pieren wrote:
> I prefere to add "narrow=yes" combined with residential or
> unclassified (or any other) highways. It should be
> interpreted as
> "between 75% to 50% narrower than the default width of this
> highway
> type".
+1
__
--- On Sun, 2/8/09, OJ W wrote:
> You have to make some assumptions about screen size though
> - 50.5,-0.2
> @z11 on a mobile phone might be 'central london', while the
> same query
> on Al Gore's array of monitors might be 'europe'
Can't you get screen resolution and then calculate the zoom
--- On Sun, 2/8/09, Blaž Lorger wrote:
> Specifying actual or at least estimated width is only way
> to ensure that data
> is universally usable. I guess heavy truck driver would not
> be amused when
> navigation system would direct him in 3m wide residential
> street, while car
> driver woul
--- On Sun, 2/8/09, Blaž Lorger wrote:
> Main point here is to identify narrow roads. This is where
> road width matters
> the most. It is obvious that narrow roads will have 2
> lanes. Unfortunately,
> those lanes will be narrow (2m or less). So number of lanes
> will in no way
> indicate r
--- On Sun, 2/8/09, Ulf Lamping wrote:
> Because it *IS IN USE* otherwise.
It takes very little time to do such a mass change on nodes.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
--- On Sun, 2/8/09, Michael Kugelmann wrote:
> The article also says:
> > It has three-quarters of the mass (0.75-kg) and
> volume of a CubeSat
>
> => quite small and the capacity will not be suficcient
> for appropriate
> lens/camera. And I'm shure it is not 3 axis stabilisation
> => no
--- On Sun, 2/8/09, Aun Johnsen (via Webmail) wrote:
> But it can also result in an "OpenLunaMap" :D
You'd also get a star map too ;)
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
--- On Mon, 3/8/09, SLXViper wrote:
> quadcopters/hexacopters/octocopters/microcopters equipped
> with a camera
> are much better than a satellite. Easier and cheaper to
> use, and most
> important: satellites give only rather poor quality images,
> often with
> lots of clouds... Digital orthoph
--- On Mon, 3/8/09, Aun Johnsen (via Webmail) wrote:
> OSM Zeppelin finally moored up at Empire State Building?
What would the good of that be, it should be out mapping!
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap
--- On Mon, 3/8/09, hanoj wrote:
> maybe http://www.airshipclub.com/
They seem to get about a bit, anyone contacted them about having a high-res
photo/video pointing downwards?
___
talk mailing list
talk@openstreetmap.org
http://lists.ope
--- On Mon, 3/8/09, Martin Koppenhoefer wrote:
> actually none of them I would consider a residential road.
> They could
> be everything from primary (not probable) to track,
> dependant on the
> surrounding and actual use (what they link).
> usually we would think about something like this when
--- On Tue, 4/8/09, Nic Roets wrote:
> If care is taken with the selection of places / names, such
> a map may become quite useful for geocoding. We want only
> "the" Paris. We want abbreviations like NY, as
> long as they do not lead to confusion. Sources of
> information include geonames and
--- On Tue, 4/8/09, Richard Mann wrote:
> The potential problem for renderers is that
> there's a lot less space to render things in urban
> areas, so they benefit if lower-order roads are
> distinguishable between urban areas (so they can be narrowed
> or suppressed), and rural areas (so they
--- On Tue, 4/8/09, Roy Wallace wrote:
> If a shop is a member of a larger group of shops belonging
> to a single
> chain, the "suburb" or "branch name" should be added in a
> separate tag
> (not sure what).
addr:city ?
___
talk mailing li
101 - 200 of 1078 matches
Mail list logo
