[Openstreetmap] Re: Naming segments using applet

SteveC steve at asklater.com
Tue Dec 20 04:41:18 GMT 2005


* @ 19/12/05 05:48:45 PM krsears at starband.net wrote:
> 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.

There is a free dev server, all the code is available. Does anyone want
to work on OGC standards? I'm not stopping anyone.

> 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?

So can you put forward a db schema that will track the changes, keep the
logic of having _connected_ nodes, do tags and versioning without using
lots of space?

Can you then compare the speed of queries on it, the amount of data used
and bandwidth against current deployed or planned ideas?

If anyone wants to work on proving java-based wfs/wms services will be
fast and reliable, please do.

> 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?

... I'm not sure what your point is.

> 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.

My tests a while ago showed using geom_to_text or whatever and back
again for nodes and lines was significantly slower than just using
double columns for lat/lon.

> 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.

So you want us to support WFS-T?

Can we reduce this to protocols you'd like and things to support them?
WMS is easy, it can hardly even be called a spec and we'll support it.

WFS-T presumable means geoserver?

> 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

Try compiling the ruby extensions. In any case it's simply too slow.

> newer versions.  With that being said there are many WMS and WFS servers
> available now.  GeoTools has a decent WMS that's java based.

My experience, and anyone I know who has done it, is that supporting
java server side is a nightmare.

> > 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.

Can you point to software with a following that does what OSM does?

If it was as easy as running geoserver or something I think it would
have been done a long time ago.

have fun,

SteveC steve at asklater.com http://www.asklater.com/steve/




More information about the talk mailing list