Actually this is probably a perfect example of the sort of stuff that SHOULD
be
available as secondary layers? Like the contour information on freemap would
be
nice as a selectable layer.
Incidentally it is already available as a vector layer (GeoJSON or own-format
XML) as it happens, e.g.
Just to add: this is OS LandForm PANORAMA contour data so any use needs to be
credited to them.
Nick
-Nick Whitelegg/FT/Solent wrote: -
To: talk@openstreetmap.org
From: Nick Whitelegg/FT/Solent
Date: 25/01/2012 01:29PM
Subject: Re: [OSM-talk] proprietary keys and values, machine
Frederik Ramm frederik at remote.org writes:
Hi,
On 01/24/2012 04:27 PM, Jukka Rahkonen wrote:
We will see much more proprietary keys in the future because people are
importing huge amounts of spatial data from external sources.
Maybe we should simply stop them from doing that?
2012/1/25 Jukka Rahkonen jukka.rahko...@latuviitta.fi:
alternative. Right now I remember only two common examples about combining OSM
data and some other data outside the main OSM database for rendering. First is
about height contours and another one is about using OSM coastline shapefiles.
Looking at the fantastic taginfo reports [1] I noticed some tags that
link presumably proprietary databases to OSM from inside the OSM-db:
e.g. this one: http://taginfo.openstreetmap.org/keys/%25kml%3Aguid#values
with values like:
{a2ec06ed-792a-4495-9218-8b2a394c4163}
I wonder if this kind of
On 24/01/2012 11:22, Martin Koppenhoefer wrote:
I wonder if this kind of tagging should be tolerated. In the wiki I
found no documentation regarding this tag, and therefore this data
seems unusable for most mappers.
Perhaps not, but systematically removing it won't improve anything
(since most
2012/1/24 Jonathan Bennett openstreet...@jonno.cix.co.uk:
On 24/01/2012 11:22, Martin Koppenhoefer wrote:
I wonder if this kind of tagging should be tolerated. In the wiki I
found no documentation regarding this tag, and therefore this data
seems unusable for most mappers.
Perhaps not, but
Hi,
On 01/24/12 14:35, Martin Koppenhoefer wrote:
How would you improve / modify (say split) an object where you don't
understand part of the tags applied to it?
I agree but would like to point out that this problem applies to
properly documented tags as well - there are quite a few
On Tue, Jan 24, 2012 at 11:22 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
the concept seems to be documented here:
http://wiki.openstreetmap.org/wiki/Proposed_Features/UUID
I don't see any mention of what should happen to UUIDs attached to
ways, when ways are split or merged. Should
On Tue, Jan 24, 2012 at 12:42 PM, Jonathan Bennett
openstreet...@jonno.cix.co.uk wrote:
We have (or at least, should have) a simple principle in OSM: Ignore what you
don't understand.
I could add another one : delete what is beyond understanding.
Because your principle is against another one :
2012/1/24 Pieren pier...@gmail.com
I could add another one : delete what is beyond understanding.
Because your principle is against another one : verifiability.
Because your principle - if it is tolerated - might end up with
elements tagged with dozen references to external applications and
Pieren pieren3 at gmail.com writes:
On Tue, Jan 24, 2012 at 12:42 PM, Jonathan Bennett
openstreetmap at jonno.cix.co.uk wrote:
We have (or at least, should have) a simple principle in OSM: Ignore what
you don't understand.
I could add another one : delete what is beyond understanding.
Hi,
On 01/24/2012 04:27 PM, Jukka Rahkonen wrote:
We will see much more proprietary keys in the future because people are
importing huge amounts of spatial data from external sources.
Maybe we should simply stop them from doing that?
Much of that
data is hard or impossible to update by OSM
On Tue, Jan 24, 2012 at 03:59:51PM +0100, Janko Mihelić wrote:
2012/1/24 Pieren pier...@gmail.com
I could add another one : delete what is beyond understanding.
Because your principle is against another one : verifiability.
Because your principle - if it is tolerated - might end up with
On Tue, Jan 24, 2012 at 03:27:00PM +, Jukka Rahkonen wrote:
We will see much more proprietary keys in the future because people are
importing huge amounts of spatial data from external sources. Much of that
data is hard or impossible to update by OSM contributors but new updates
will be
On Tue, Jan 24, 2012 at 3:38 PM, Jochen Topf joc...@remote.org wrote:
Importing is difficult enough to do properly and I think updating that data is
even more difficult to do.
I think it would make more sense for some kinds of data (particularly,
the more volatile ones) to have map servers
On Tue, Jan 24, 2012 at 9:38 AM, Jochen Topf joc...@remote.org wrote:
On Tue, Jan 24, 2012 at 03:27:00PM +, Jukka Rahkonen wrote:
We will see much more proprietary keys in the future because people are
importing huge amounts of spatial data from external sources. Much of that
data is hard
17 matches
Mail list logo
