[Openstreetmap] Re: Naming segments using applet

Kendall Sears krsears at starband.net
Mon Dec 19 17:48:45 GMT 2005


On Sun, 2005-12-18 at 02:13 +0000, SteveC wrote:
> * @ 16/12/05 04:18:20 PM krsears at starband.net wrote:
> > Hey folks,
> >   This is going to get out-of-hand with the current db schema real
> > quick.  The current schema is highly road/street paradigm dependant.  
> 
> I won't repeat the comments already made which I agree with generally
> other than a few points. Firstly, people telling me to use GIS OGC
> standards are 10 a penny. People willing to touch it with a barge pole
> and actually work on it are absent.

That so many advocate the same solution should be an indication of its
possible validity.

Going by the amount of resistance I've encountered I can see why most
professionals wouldn't proceed very far.  Many people who do this stuff
for a living have lots of time to contribute but little time to
persuade.  Those of us who work within the "spatial arena" have already
been through the arguments in order to create the OGC specs in the first
place and most now have little stomach to go through it all again for
those who "aren't in the know."  I'd be willing to bet that a good
portion of those that made the suggestion just decided to move on to do
something else that didn't require so much persuasion.

>From what I've read of the current schema on the ftp area it wouldn't
take too much to convert the current dataset into an OGC compliant
schema from the data standpoint.  I say that without knowing exactly the
inter-data dependencies required in the current schema. 

> As people keep telling me, I'm a pragmatist. And being pragmatic, nobody
> wants to work on these things. That might be a great loss, and if you
> have a way to fix it, let's work on that.

Working on something is different than lobbying to get the necessary
infrastructure accepted.  Not many people are going to take the time to
convert the data if they're not assured that the work will be accepted.


> > Already, there are instances with streetmaps where I can see problems.
> > For instance, in the US and Canada (I am not sure about across the pond)
> > there are many roadways that "change" monikers or function as part of 2
> > or more routes.  These may diverge into multiple separate paths,
> > converge from others, or even "jump" to another road.  There is no
> > facility for this in the current db.  Also, interstate highway systems
> > don't seem to be a strong point either as their associated
> > entryways/exits, viaways, overpasses, and the like aren't symbolized.
> 
> The database can handle all that as soon as we get streets working.

My point.  Street vectors are nothing more than a vector layer.
Attached to that layer are the necessary attributes stored in a table.
Connection to the DB by a GIS package (JUMP, QGiS, ArcView, ArcGIS,
Imagine, ...) would immeidately show the streets and the attributes.
Display via a WMS or WFS would similarly work.  What's left to get
working?

> 
> > 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
> 
> There are many. The problem is, most of them are hard to use and
> maintain for a variety of reasons.

The schemas are not hard to maintain or use as long as one uses the
implementations already provided for in MySQL or PostGIS.  Using the
schemas does not necessarily imply implementing the entire spec.

> 
> > 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.
> 
> That is not true. By using simple primatives we're able to track changes
> very easily. You seem to be advocating storing arbitrary geometry,
> versioned, and thrown around WFS-T. There are computational and storage
> requirements let alone UI and bandwidth issues to consider there. And
> then you have to find someone to work on it. For free.

Many GIS professionals gravitate to these types of projects if they feel
that they can truly participate.  Look at the number of them that work
on the OSS GIS editors.  To a GIS guy, the DATA is the high (that and
smacking at ESRI :-)

I advocating storing the correct data type in the correct way.  Streets
are a vector layer, Points of Interest are a Point Layer,  GPS tracks
are a vector layer, canals are a vector layer, and on and on.

Searching for a street name should only have to search through street
data.  If a user wants to see canals, why show them bus-stops?

There are indeed storage and computational issues, but those should be
lower using a GIS data-storage.  Bandwidth is the same.  Images are
generated and transmitted.  It is the same.

UI?  Let the user decide the UI.  If I want to use QGiS let me, allow
the use of ArcExplorer (free download from ESRI) if desired, or continue
with the current tile based browser approach and add layer checkboxes.

> I can't find it but somewhere I think you suggested using mapserver. We
> do. It's unthreaded, slow, hard to extend... and I can't wait to replace
> it.

I threw mapserver out there as one example of many.  While I agree it
can be slow, the hard to extend part doesn't make any sense with the
newer versions.  With that being said there are many WMS and WFS servers
available now.  GeoTools has a decent WMS that's java based.

> I'm not trying to be negative. In a way, I agree with you but it's not
> something I have time for or that I've found anyone wants to work on.

Not having time I can understand as I personally have little extra time.
Hence the reason I need to make the most of what time I do have.
However, you'll find more volunteers if you use software that has a
following already instead of trying to recreate yet-another from
scratch.

> have fun,
> 
> SteveC steve at asklater.com http://www.asklater.com/steve/

Kendall
-- 
Kendall Sears <krsears at starband.net>





More information about the talk mailing list