[Openstreetmap] Re: Naming segments using applet
Andy_J_Robinson at blueyonder.co.uk
Sat Dec 17 00:09:58 GMT 2005
I hope this isn't a rant.
It's easy to think that we might all be rather naive in our approach to OSM.
After all, the majority of us who are actively working on some aspect of the
project are probably not connected professionally with anything majorly GIS.
However, if I look at the OGC website all I see is ISO standards,
multinational committees and sub committees, and the need to fit with an
agreed and ratified set of rules. All looks rather bloated and mostly goes
over the top of my head. Consequently I'm not sure that such an approach is
what OSM is really about.
I like the very fact that OSM appears simple. Of course it can't do a great
deal yet and may be it never will have all the bells and whistles. Surely
that's not the point though. The OSM community will with time, I am
confident, find out what is important and achieve a level of functionality
that always remains useful, and probably cutting edge. Right now we might
only be trying to solve the problem of finding the shortest distance between
each pub, whether it be by road, rail, canal, path or unmapped alley :) In
the future may be we will want to find our way home from the pub via the
chippy using the number 47 bus that leaves at 11:56pm. I'm sure that
milestone will be reached at some point too.
The point for me is that it doesn't have to be complex, but rather it needs
to be adaptable. This is where I see our current stumbling block to be.
Keeping the framework loose enough to allow any type of referencing but a
simple set of "rules" so that it's all easily understandable to your average
loose sight of the fact that OSM is a project which enables the creation of
street maps by users (I'll happily extend that to mean footpath, cycle,
canal etc maps). OSM is not being "created" by a database management team as
would presumably be typically the case with a GIS system. There is no chunk
of money to throw at a professional team to create the perfect back end for
OSM's needs, so for now it grows slowly, with a degree of user frustration,
but only because the hard core coders only have a limited amount of time to
develop what the users want, fix the bugs, and answer the wanderings of the
mailing lists :)
So next a plea to reinforce the one made by Tom. For those out there lurking
on the list who have some real knowledge of how some of the OGC and other
GIS community schema work in practice, please give us some examples or point
us to a specific location(s) where we can see how, in simple terms, we might
for example distinguish between a canal and a road and associate that the
canal is 3 feet deep, the road 7.1m wide and that the canal passes under the
road but the road is closed today for resurfacing. To me it seems simple
that a linear segment might have such "labels" that allow these types of
metadata to be referenced to the sections concerned and therefore later
retrieved for use in a multitude of ways by the user. Or am I missing
something here. That stumbling block I referred to earlier is only so
because there does not appear to be (to me at least) a "usual" manner by
which this type of adaptable referencing is normally interfaced in a geo
spatial context and hence it has not been a logical next step in the
functionality provided to OSM users.
Incidentally, I like the wiki idea of tagging a page with a set of key
words. Apply the same idea to each element in OSM. If all attributes, labels
and other thingamabobs are considered as keyword tags then it's easy to see
how a user might build up a custom map based on, for example, "pub" "chippy"
I'll go to bed now.
Kendall Sears wrote:
>I would recommend moving to the OGC (Open GIS Consortium) schemas as
>these are usable by many GIS packages already. Not to insult the great
>work that's been done, but can one really say that it _works_ now? It
>is usable for sure. But there's no way that I'm going to put the
>several million points contained in my datasets into the OSM set with
>the current facilities; it just takes too much effort and time. And the
>entry accuracy is just not available, I'm collecting sub-meter accurate
>differentially corrected GPS points only to have the entry applet make
>me manually click to create a node that is way outside of the collected
>accuracy range. If I could use my current tool set then your collection
>would be flush with lots of data from North America containing much more
>information than just the location of the pavement.
>Since you say time is the issue, consider this: using either MySQL's
>GIS set or PostGIS (both OGC compatible) one can import data directly
>from shapefiles, CSV, and many other formats. Let's also not forget
>using JDBC from GIS packages. From there the data can be served from
>any of about a dozen WMS/WFS servers available as open-source. These
>are tested and (for the most part) production quality _now_. How's that
>for time savings :-)
>> > I've been a professional GIS technology consultant for over 8 years and
>> > have run into MANY instances exactly like this. The resulting work to
>> > fix the problems was more than a little outrageous.
>> Can you point us in the direction of some of the MANY instances you're
>> thinking of? And what were the lessons learned? "Use PostGIS" isn't a
>:-) Considering that the majority of my clients use ESRI or Oracle
>Payware that isn't one of the lessons.
>Let me get something clear. I don't really have a "dog in this fight"
>as I'm really just looking to help out where I can. I really like the
>idea of open data availability, which in the US and Canada really isn't
>a problem. NA has a few "somewhat" (within 20M) accurate public-domain
>vector sets available for anyone to grab. However, an accurate world
>wide surface level data set has an appeal.
>With that being said: As long as a data set contains only a single type
>of feature the format/schema really doesn't matter. Look at the
>"standard" ESRI shapefile as an example. However, once one starts
>varying the types of data it rarely stops. First it's railroads, then
>bicycle paths, then rivers, then canals, then streams. Then someone
>says, "we need to have depth measurements on the rivers/canals to keep
>boats from shoring". All of a sudden what seemed to be just a simple
>"line-feature" data set becomes a true spatial set. Take a look at the
>"bus-stop" discussion here recently.
>What invariably occurs is that "extensions" keep being made to the
>"simple" database. Call them "tags" or "labels" or whatever, it's still
>the same old mess. Eventually the data are too unwieldy to be handled
>in a "simple" data set and too inconsistent to easily be converted to a
>"standards" data set. This almost always leads to extraction of a small
>subset of the data and re-entry of the rest, if funds are available, or
>abandonment of the data if not.
>The lesson learned is to over-engineer your schema; if it is easily
>done, and to rely on the work of others; if available. A schema is
>available from the OGC and is manifest in either MySQL or PostGIS on the
>free side. Once you've got that you can capitalize upon the many OGC
>compatible GIS packages available anywhere for data entry and
>maintenance, either Open-Source or commercial. You might even want to
>look as the UMN Mapserver project for WMS serving, or the GeoTools
>project for their server. Once one can remove the software
>development/maintenance headaches one can focus on the truly important
>part: the data.
>> Are you sure they were making wiki-style street maps? We're not trying
>> map the universe at 1:1 scale here, just map a few streets. If canals
>> stuff drop out of that for nearly-free, then all the better for waterway
>> enthusiasts, but I disagree that accomodating a few other 'street-like'
>> representations puts us on a slippery slope where the only solution is an
>> 'industry standard' GIS database. I think you misunderstand the scope
>> focus of the project if you think the database situation is that bad.
>There's nothing special about 'wiki'-ing with GIS data. The maps are
>visualized at the client end. The database controls the changes. Been
>doing that for a very long time.
>As far as misunderstanding the scope: I've watched these type of
>projects evolve since the early 1980's. The scope _always_ starts
>small. So far, from reading ALL of the archives, this project has
>followed the same old script EXACTLY to the letter. This is what
>prompted me to comment. So far, the only thing that has surprised me
>about this particular project is the reticence to accept data and
>assistance by the members of the community.
>Thanks for your time.
>Kendall Sears <krsears at starband.net>
More information about the talk