[OSM-talk] Broken Ways, WMS Server Status

Christopher Schmidt crschmidt at crschmidt.net
Fri Apr 28 13:11:01 BST 2006


On Fri, Apr 28, 2006 at 01:37:18PM +0200, Immanuel Scholz wrote:
> 
> > From the Planet.osm dump, ways with id 1969, 1970 both seem to be
> > broken: they have hundreds of segments, but they all have id 616316.
> > These ways were both 'created by josm' -- is this a problem with josm?
> 
> It was a problem in some older version when importing GPX directly as OSM
> data. It is fixed now and the newer versions of the way should have been
> already updated in the server.

Cool. Thanks!

> 
> > Is there any way to prevent this from happening in the future?
> 
> Its "prevented" in terms of the problem with JOSM is fixed now. I don't
> see a reason to prevent this in the server, since something like this is
> usually silly and nobody will enter it anyway (except for a reason).

My main concern is that it ruins the usability of OSM's data -- one
assumption that I was going to make was that ways are made up of unique
segments, but that's obviously not the case.

This isn't to neccesarily say that the database should prevent ways from
having the same segment multiple times, since I'm sure there's costs to
that. I suppose since I can fix it for myself, I'll just let it be for
now.


> For example you *can* create a wikipedia page, containing 10000 times the
> character $. ;-)

In which case it would be immediately obvious: The problem with this is
that it *isn't* obvious to most people using the applications, since
multiple segments being selected in a way isn't something that you can
graphically represent in an intuitive manner.

> 
> > (I'm sure someone will tell me that I can edit them myself, but since I
> > can't get any editors working on my machine anymore, I don't really want
> > to hear it :p)
> 
> Well, you could use:
> 
> cat planet.osm | uniq > planet-fixed.osm

Ah, good point! Hadn't thought of that. Will definitely give that a run.
Thanks!

> 
> > The solution to this is to develop some kind of scale dependant
> > rendering, but previously I had loaded only segments and nodes. Scale
> > dependant rendering requires something more -- first, loading the tags,
> > and hopefully I'll also be able to use the 'ways'.
> 
> I hope for something like: map?bbox=...&search=class:major

Don't hold your breath ;) My goal is to make a usable basemap for
applications which want to display large quantities of data. My
specific use case is for the Open Guides family of web sites -- to allow
them to plot their entire geocoded database on a map. This is not meant
to be a fully featured solution for everything, although if anyone knows
enough mapsever to give me improvements to the mapfile, I'll gladly use
them ;)

-- 
Christopher Schmidt
Web Developer




More information about the talk mailing list