[OSM-talk] Some question about OSM

[Ben Gimpert]

(We should really start a FAQ, folks.)

Hi Niko,

You ask some good questions, but I must ask -- why not help develop one
of the OSM off-line editor projects already out there?  Though Imi
currently keeps tight control over repository access, JOSM is an
increasingly mature project that could use more eyes.  Or maybe add your
routing and editing features to the online editing applet?

On Fri, 30 Jun 06 @10:51am, Nicola Ranaldo wrote:
> I'm writing a qt4-based OSM client in order to render maps and doing route 
> planning with speech instructions (festival). It has some basic editing 
> capabilities too.  Depending on my free time, when the code will be cleaned 
> and optimized, i'll release it under gpl.

Given the lovely activist and volunteer disposition of the OSM
community, I highly doubt you'll get help on damn near anything unless
you GPL or PD *first* and ask questions later.

That being said, I'll play along a bit:

> While approaching i collected some technical questions for you:
> 
> *) wiki says a segment could belong to several ways, is there a specific 
> reason for that?

To theoretically decrease the amount of stored data, since one could
re-use a given segment across a number of ways.  This is particularly
relevent in this situation:  One "logical" way represents a train track,
another way represents a footpath, and another a road.  All three ways
might use the same segments, since their overlap in real life, but
obviously they differ in their metadata (tags).  Sharing their segments
requires less space in the server's database, etc.

> *) osmplanet data seems to contains some dirty informations, tests, orphaned 
> objects and so on... is it normal?

Absolutely normal.  This is a wiki map of the world, so our data will
always reflect people's experimentation and whims and mistakes.
Diversity (a.k.a. "shitty data") is the spice of life.

> *) wath's the best approach to do street and place names rendering? 

The "best approach" is probably to join forces with Etienne and improve
the SVG rendering, and then work to incorporate this same rendering
system into JOSM.

> disposition of text will be evaluated by software in real-time?

Yeah, probably.

> will be some > key/value helping rendering software ? (for example, a
> tag could say render this town names at x,y, or <important> do not
> render it when scale > z and so on)

Again *theoretically*, we want to limit the amount of data that is
specific to a particular type of rendering system.  Consider the ideal
of HTML in the early days ("content specification") vs. now-a-days (CSS
as page layout).  I would hope we lean toward the former philosophy as
long as possible -- with renderers interpreting *geographic* OSM data
and metadata intelligently, rather than expecting the data to have
explicit rendering instructions.

> *) my route planning code actually works on every raw segment/node, is
> this right?

That depends.  Is it fast enough looking at everything?  If so, that's
cool.  If not, well then:

> should it run only on "junction" nodes? should the software use the
> first option and take help from the second when available? this
> questions due to lack of junctions tagging in data , i think
> routeplanning helpers should be strong formalized, in order to modify
> editors and avoid huge maps reediting
> 
> *) do you think distibuting (with zone delegation ala DNS) database
> may be an idea (with rest api modifications) ?

Distributing the OSM database has been an idea tossed about with some
frequency on this mailing list.  It's probably a good idea in principle,
but requires a lot of real admin and development work to make it happen.
Do you have expertise here, and are you volunteering?

> *) a stupid question, some segments have k="highway" v="primary", and
> others k="class" v="primary"... is it normal?

Yes, it's normal.  (See my "it's a wiki" response above.)  Any client of
OSM data probably wants to accept both "class" (old school) and
"highway" (new school) segment or way classification.

Best of luck on whatever you decide.

		Ben