[Talk-us] parcel data in OSM

[Frederik Ramm]

Hi,

On 30.12.2012 04:23, Michael Patrick wrote:
> The point being, is that every locale is going to have features (and
> combinations of features) to give contest to some user's activity or
> use. And for that individual or community of users, if that feature(s)
> can't be added or isn't present, the map is 'broken'.

OSM is a giant geodata editor, NOT a giant one-stop map making toolkit.

Geodata that must be surveyed, edited, corrected by many eyeballs is 
usually well suited for OSM. So if these low and high water lines of 
which you speak benefit from the knowledge of locals (or frequent users 
of those waterways/areas), if they can be, and are, surveyed by 
amateurs, then I guess it would be a good idea to include them in OSM.

If, on the other hand, these low and high water lines are 
defined/recorded elsewhere (probably even in a legally binding form if 
they are relevant to some statue), and the only reason you want them in 
OSM is because you don't have the means, knowledge, or patience to 
actually retrieve that data from elsewhere and have it drawn into your 
map, then you advocate abusing OSM as a third party data distribution 
vehicle.

OSM is for crowdsourced data; that is OSM's strength - that hundreds of 
thousands of people can actually improve, edit, fix the data, and that 
is something you can't achieve by downloading a shape file from your 
county's GIS department.

OSM's strength is definitely not collecting all the third-party geodata 
in the world that someone might find useful and load that into a common 
database so that people who want to make maps have easy access to such 
data. OSM is not designed for that. If you wanted to design a system 
that does something like this, you would build something other than OSM, 
something where the strength is storing (and finding) vast amounts of 
third-party geodata without the capability to edit, and therefore 
without much of the bells and whistles (or ballast!) that OSM with its 
mapper/survey centric architecture has. For example, you'd simply upload 
a shape file with a million house geometries to the storage server, 
instead of painstakingly converting it to "ways" and "nodes" and slicing 
it into changesets of no more than 50k objects and adding source tags to 
everything etc - you'd just say "here's this shapefile, this is what the 
columns mean, this is the extent" and then everyone who wants those 
houses on their map can simply switch that layer on.

OSM is not that system, and therefore it is not surprising that people 
who want such a system are often told to look elsewhere.

> If it's hiking / snow shoeing,
> while 10 ft contours would be overkill, the 500ft, 1000ft, 1500ft,
> 2000ft, etc. are critical because weather warnings are broadcast
> according to those levels.

I'm not sure if we're maybe talking different things. I'm all for 
cartographic freedom and experiments, and of course anyone can and 
should make any map they want, and have access to all the data they 
could possibly want. All I'm saying is that OSM is *one* ingredient in a 
map maker's toolbox, and of course he'll have other sources to get his 
height contours from and use them. It's just that "it would be nice to 
have height contours on a map" is no reason for including height 
contours in the OSM database.

> Adapting the some parts of the map content local conditions would seem
> to meet this philosophy, but I have been detecting a refrain that if it
> doesn't fit some current  'x-y-z' tradition / theme, go do it 'elsewhere'.

There's nothing against someone creating a map that shows height 
contours in one area, high and low water lines in another area, parcel 
boundaries in a third, and mugging hotspots in a fourth. In fact I would 
be thrilled to see such a map with regional variations.

However, these are challenges of map making (rendering). We're certainly 
not going to import height contours in some areas just because a map 
maker can't figure out how to make height contours appear in that area only!

To give you another example - we've often talked about feature density 
and rendering rules. Pubs are shown only on zoom level 16 and above, 
because if you were to show them on 14 or 15, the typical city centre 
would be nothing but pubs. However, in a rural area where only one of 
four villages even has a pub, it would be very helpful to have that 
shown at zoom level 14! This is a cartographic challenge, not a data 
challenge; we're not going to delete the smaller inner-city pubs in our 
database, and we're not going to add a "render_at_z14=true" tag to the 
sole village pub either. It is the map maker's job to get that right.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"