from:"marcus.wolschon"


Well,

sounds nice. Where is it?

Marcus

On Mon, 20 Apr 2009 23:55:59 +0200, Michael Willigens
mich...@willigens.de wrote:
 Well,
 
 Concurrency: yes, it can use the calling thread OR it can instantiate  
 new thread that
 will return the result when available to an callback interface. So  
 anything is thread
 save here.
 
 Memory: Havent tested yet, because i think that parsing small XML  
 files is also possible
 on J2ME. Could be improved by implementing a Sax parser in J2ME. I  
 have thought about
 that but i think its kinda overpowered.
 
 Query Handling: On J2ME it will use the HTTPConnection class to get  
 an InputStream for
 the XML parser. On J2SE it will use default URL.openInputStream().
 
 API itself:
 Some static reachable methods like:
 NameFinder.searchAsync(String query, int maxResults, NameFinderCallback
c)
 NameFinder.search(String query, int maxResults)
 will return an array of NameFinderResult Object which basically carry  
 any data we have on
 NameFinder: type, category, name, info, description, nested results...
 
 Michael

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [Routing] webservice to collect traffic messages

On Tue, 21 Apr 2009 09:17:36 +0100, Tom Evans tom_evan...@yahoo.co.uk
wrote:
 marcus.wolsc...@googlemail.com wrote:
 Why would anyone be interested in when the event started?
 It's there, it will be there when you get there so it's
 to be used in the metric.
 
 Most traffic congestion doesn't operate to an accurate timetable? 
 Typically, you have observations of the congestion (at a known 
 time), and an estimated (i.e. made up) duration.

Correct and if a new estimate becomes known or the cancellation
of the event is broadcast it gets updated.

 For the few events which are predictable, you'd want to take 
 advantage of that and broadcast the prediction. But without implying 
 the event has already started.  Unless I'm missing something, you 
 can't do that with just expiration date.  Just a thought.

So you mean expected events?
I did not think about these before. Do you know any sources
where we may actually get such data?

This is becoming more complicated then I expected.

What about:

# eventid (generated)
# source-system (wenn known constants such as TMC, UserInput,
FloatingCar...)
# reported/updated by (list of accountIDs)
# event-type (few, well known constants)
# event-description (human readable)
# valid-until
# valid-from
# primary location 
 * lat, lon
 * if known: ref/name
 * either nodeID+wayID (point) or relationID(area)
# direction (compass-degrees)
# list secondary locations
# list of additional name-value -pairs (+wiki describng the ones used)

You can then query all current messages by:
* a bounding-box
* + version-number of the protocol used
* + list of understood keys for the additional data (or * for all).
* + optional flag to not include the secondary locations
Messages can be updated given their id.
Expired messages get removed.
You have to register a user-account but need not give
personal information. (So sources of bogus messages can
be tracked.)
The client-application is responsible for choosing what
messages from what sources to trust.

Examples of area-locations are meteorological conditions.
The event-type shall be few and represent the expected
action to be taken rather then the exact nature of the event.

examples for additional name-value pairs would be:
* length of a traffic jam in meters
* original TMC-message+CID/TABCD in hexadecimal



Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [Routing] webservice to collect traffic messages

On Tue, 21 Apr 2009 10:03:37 +0100, Tom Evans tom_evan...@yahoo.co.uk
wrote:
 marcus.wolsc...@googlemail.com wrote:
 On Tue, 21 Apr 2009 09:17:36 +0100, Tom Evans tom_evan...@yahoo.co.uk

 Correct and if a new estimate becomes known or the cancellation
 of the event is broadcast it gets updated.
 
 Yes, I was just implying it was a shame to throw away the one piece 
 of known good information and send the guessed bit instead.

I added a from timestamp now.

 Rush hour is a bit of a broad one, but there are definitely 
 particular hotspots that become much worse than the rest then.  I've 
 also seen occasional warning of queueing for a big event, which 
 should presumably be known in advance.  Also some motorway roadworks 
 have a scheduled start time.  I don't think it's the common case by 
 any means, but it would be a shame to encode the scheme such that 
 they could never be described.

Construction-works is a good point. Once it is up and running
it would be cool to look for electronic publications of such
and feed them into the system. :)

As you mentioned rush hour, I'm thinking of adding either a
required field or a name-value -pair for probability.

 This is becoming more complicated then I expected.
 
 For that reason alone I like the name-value pairs you put in.  My 
 instinct is to try and push everything that isn't essential and a 
 fixed byte count into that, but I can't think where I'm getting that 
 idea from...

Yes.
I did not want to loose such information as the original TMC event-code
and there can be many optional parameters that may be of use.
(If nothing else, then for experimentation ;) )

I guess I'll implement this message-format for the existing
TrafficMessageStore -class in Traveling Salesman (it currently only
stores TMC-messages localy) and if that works out in the local case
write the web-service.
Then a web-UI for listing all currently known and manually entering
events and see how well others can make use of this too. :)

http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=TrafficMessage


___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] implemented API for J2SE and J2ME (NameFinder Client API)

On Tue, 21 Apr 2009 12:23:04 +0200, Michael Willigens
mich...@willigens.de wrote:
 Hey,
 
 i have thought about that last night,
 Its sounds a bit odd but it would be possible to use an LDAP server  
 for GeoNaming lookups. We could create a canonical, hirachical scheme  
 and fill in any named Objects. Correctly implemented LDAP is several  
 times faster than MySQL in naming lookups and supports also wildcard  
 queries. We could even split up the request by using a well known has  
 funstion among severla LDAP servers.
 An Example scheme could depend on places and large polygon border  
 structures like:
 Earth -  Continent - Country - State - Region - City - ...
 We could fill on Bogus placeholders for canonicals that are not  
 defined. (i.e. Countries without any States like Liechtenstein)
 
 what dou you think about that ?

I dou ;) think that placeholders would not be required
if using ObjectClass Planet, Continent, Country, State,...
Thus:

p=Earth,c=Lichtenstein,city=Au,district=Haslach,Street=Haslachstrasse,housenr=2
(no State here, other cities may have no district)

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] implemented API for J2SE and J2ME (NameFinder Client API)

On Tue, 21 Apr 2009 12:52:25 +0200, Michael Willigens
mich...@willigens.de wrote:
 yep, your right for the query part. but i think we need placeholder in  
 the server datastructure anyway to make it work. anyway, i have made  
 good experiences with LDAP using huge datasets. Thing is: is there  
 anything we need that LDAP does not give us?
 
 Michael

You think of writing your own LDAP-server instead of using slapd from
OpenLDAP with a custom schema?

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] webservice to collect traffic messages - wiki page



I made a wiki-page to formalize the data-format and event-codes:

http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=TrafficMessage

sourceforge-users can use https and ask for edit-rights.
I am not sure about the layout of the protocol but I am thinking about
something that is easy to do with HTTP in parallel to soap.

(This is the wiki where I document my implenentation. I did not choose
 the OSM-wiki as this is not a part of the OSM but just some service
 that can be used together with OSM or independent of it.)


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] implemented API for J2SE and J2ME (NameFinder Client API)

On Tue, 21 Apr 2009 14:09:30 +0200, Frederik Ramm frede...@remote.org
wrote:
 Hi,
 
 Thing is: is there
 anything we need that LDAP does not give us?
 
 Let me ask the other way round: What are the cool things that LDAP 
 *does* give us and where it saves us time compared to do something 
 ourselves?
 
 I believe that the major complexity in the name finder is that real 
 language user queries have to be matched to what is in the data base. 
 This means something like

I disagree with the have to.
A new implementation can have a form
with inputs for country, city, ..., housenumber and an optional
select amenityNearby


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[osmosis-dev] How to use EntityBuffer


Hello,

I am trying to use the EntityBuffer -class but seem to be doing something
wrong here.

I did:

XMReader task = new ...
EntityBuffer  buffer = new EntityBuffer(BUFFERCAPACITY);

task.setSink(buffer);
buffer.setSink(sink);

buffer.run();
task.run();


It seems that this hangs indefinately waiting for entities to
come in from the buffer.
Do I need to call some special method or use a special
manager-class to make the buffer start it's Executor or Thread?

Marcus

___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

[OSM-dev] webservice to collect traffic messages


Hello,

I'd like to experiment with Google AppEngine for a bit and
set up a hosted service to collect traffic messages
(traffic jams, road obstructions, constructions sites, slow
moving traffic,...)

What could be a good data-format for such information, so that
it is usefull to more then just my own navigator?
I'm thinking about:
* required: (enum) event-type
* required: (string) event-description
* required: (long) OSM WayID of primary location
* required: (long) OSM NodeID of primary location
* required: (datatime) expiration date of the event
* optional: (long[]) additional affected nodeIDs
* optional: (long[]) additional affected wayIDs
* optional: (time) expected delay
* optional: (string[]) additionalData

Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-)
applications
or shall I add required lat + lon + ref/name -attributes?

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] webservice to collect traffic messages

On Mon, 20 Apr 2009 07:56:13 -0400, Greg Troxel g...@ir.bbn.com wrote:
 marcus.wolsc...@googlemail.com writes:
 
 I'd like to experiment with Google AppEngine for a bit and
 set up a hosted service to collect traffic messages
 (traffic jams, road obstructions, constructions sites, slow
 moving traffic,...)
 
 I'm not sure how you're intending to use this, but I'm guessing peer
...

Actually it's just going to be a proof of concept.
If the format as well as my atempt to get input from
the other developers of the other navigators work out
I am thinking about having some fun with car2car.
For that traffic messages in a general format would be
a good starting point and then there are lots of fun things
you can do with map-updates and communication while driving
in a convoy.

At the moment I get lots of traffic messages from TMC but
I don't want to hardcode a specific source of such information.
Keep it open for others with good ideas.

 Have you looked at the format specs for TMC:
 
   http://en.wikipedia.org/wiki/Traffic_Message_Channel
 
 It's not the least bit clear that it's the right thing, but probably
 worth glancing at.

Well, I am programming on the TMC LocationCodeList-import for
Germany (Roads work, Segments are difficult, Points get scary),
did the TMC-implementation in Traveling Salesman and have the
ISO-documents on it next to me. 
..too late, I already glanced. ;)

 What could be a good data-format for such information, so that
 it is usefull to more then just my own navigator?
 I'm thinking about:
 * required: (enum) event-type
 * required: (string) event-description
 * required: (long) OSM WayID of primary location
 * required: (long) OSM NodeID of primary location
 
 Not sure what you mean by long, but protocols should only use
 fixed-width types, so perhaps uint32_t, or perhaps uint64_t to avoid
 having to change the protocol when there are more than 4G nodes.  Or
 perhaps this is xml so it's just a number.

long=signed 64bit integer. The datatype osmosis uses for IDs
and thus the one I inherited for all my code.

 * required: (datatime) expiration date of the event
 
 I don't follow this - I would expect a time of report, and perhaps an
 expected time remaining.

time of report + expected duration = expiration time.

 * optional: (long[]) additional affected nodeIDs
 * optional: (long[]) additional affected wayIDs
 
 * optional: (time) expected delay
 
 Presumably this is the number of seconds that travel would take minus
 the number it would take under normal time?

I was thinking about milliseconds as that is the natural
unit of time but yes. In TMC I sometimes get this in minutes,
sometimes I get a length of a traffic jam and can aproximate
this.

 * optional: (string[]) additionalData
 
 for humans?

For future extensions. Never design a protocoll without either
a version number or fields reserved for extending it.

 Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-)
 applications
 or shall I add required lat + lon + ref/name -attributes?
 
 With OSM ids, one can only generate and use data if one has OSM data
 locally, and then only if it's the same version - what if there was an
 edit to add/remove ways that didn't really change the map massively
 semantically, but changed way ids?

I find it very hard to map things line road-name+lat+lon
to a way efficiently and correctly. That's why I am asking for better
options.

 This data could be useful to display without the detailed database.
 
 It would be nice to have this data be useful over long time scales,
 looking at the frequency of (reported) trouble.  So using way ids as the
 primary key seems like it could be trouble.
 
 I would expect that routing applications have to figure out from
 position where one is anyway, so reporting by lat/lon makes sense.
 Except in very messy areas with lots of stacked ramps.

Take a simple dual-carriageway or the usual case that a traffic jam is
reported to start at a motorway-crossing. There are lots of ways.

 So perhaps lat/lon, and an optional way id for disambiguation, but which
 can be ignored if it doesn't make sense.

Lat+Lon+direction of moving traffic could be more stable if the nodes
get moved around.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] [Routing] webservice to collect traffic messages

On Mon, 20 Apr 2009 18:46:38 +0200, Doru Julian Bugariu j.buga...@wad.org
wrote:
 marcus.wolsc...@googlemail.com schrieb:
 
 I'm thinking about:
 
 + Use a cool name: OTM OpenTrafficMessages
 + Version of protocol
 
 * required: (enum) event-type
 * required: (string) event-description
 
 Isn't that redundant to event-type?

No. An event-type can only encode a very short list of
events like traffic jam|roadblock|slow|other but
the description can be human readable and contain that
it is a traffic jam due to lost cargo.

 * required: (long) OSM WayID of primary location
 * required: (long) OSM NodeID of primary location
 
 Why not use dedicated tags and IDs for it? They even may be attached
 automatically to existing ways by a bot.

Because then only location with these tags can have a traffic
message. That would work for TMC-messages but not for others.

 * required: (datatime) expiration date of the event
 
 Why not starting time and duration?

Why would anyone be interested in when the event started?
It's there, it will be there when you get there so it's
to be used in the metric.

 * optional: (long[]) additional affected nodeIDs
 * optional: (long[]) additional affected wayIDs
 
 Good idea.
 
 * optional: (time) expected delay
 
 Delay if going through specified event?

Yes, I like to make it as easy as possible to use
the service. It it gets too complicated (like every developer
having to figure out a way to calculate how fast you can move
in a given traffic jam) noonw will implement clients.

 * optional: (string[]) additionalData
 
 Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-)
 applications
 or shall I add required lat + lon + ref/name -attributes?
 
 Node IDs and Way IDs may change through time. Lon + Lat + Ref/Name may
 be hard to code and error-prone.

NodeIDs and WayIDs are stable enough for any even that lasts only a few
hours anyway but for long lasting events and for clients that did not
preserve the entity-IDs or are simply not using the OSM as a map
I'll add lat+lon+direction of at least the primary location. That should
also eleminate the issue Floris and you pointed out with entity-IDs
changing.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Routino - a router for OpenStreetMap data

2009-04-17 Thread marcus.wolschon

On Thu, 16 Apr 2009 17:52:52 +0100, a...@gedanken.demon.co.uk (Andrew M.
Bishop) wrote:
 More information about the software and source code (Affero GPLv3
 license) can be downloaded from here:
 
 http://www.gedanken.org.uk/software/routino/
 
 
 An online demonstration of the router for the UK is available as well:
 
 http://www.gedanken.org.uk/mapping/router/router.html

I took the liberty of creating a stub-page
http://wiki.openstreetmap.org/wiki/Routino
in the wiki and add it to the list of online-routers
http://wiki.openstreetmap.org/wiki/Routing/OnlineRouters

Please feelf free to complete the page.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[osmosis-dev] NumberFormatException Null when reading Changefile

2009-04-16 Thread marcus.wolschon


Hello,

I tried to load an .osc.gz from the planet-mirrors
using the XMLChangeReader but noticed that of cause
these are still v0.5 .

Is there some kind of migrate-task for ChangeFiles
like there is for .osm -files?


Marcus

___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

[OSM-dev] api 0.6 changefiles

2009-04-16 Thread marcus.wolschon



Hello.

Does anyone have a valid, small .osc.gz -file in api 0.6 format
that I could use for testing?
I'd like to verify that my loading of changefiles works but
I can't get test-data in api0.6 -format anywhere and can't find
a migrate-task in Osmosis.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] api 0.6 changefiles

2009-04-16 Thread marcus.wolschon

On Thu, 16 Apr 2009 10:32:22 +0200, Frederik Ramm frede...@remote.org
wrote:
 Hi,
 
 marcus.wolsc...@googlemail.com wrote:
 Does anyone have a valid, small .osc.gz -file in api 0.6 format
 that I could use for testing?
 I'd like to verify that my loading of changefiles works but
 I can't get test-data in api0.6 -format anywhere and can't find
 a migrate-task in Osmosis.
 
 --migrate-change not what you're looking for?

Strange, next time I should not rely on autocompletion.

Ok, loading 0.6 and 0.5 changefiles in Traveling Salesman
works now including autodetection.


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Traveling Salesman - v1.0.0-RC1

2009-04-15 Thread marcus.wolschon

Traveling Salesman - v1.0.0-RC1
==

Traveling Salesman is a navigation application for use on nettops and
laptops for
the OpenStreetMap. It's focus is on clean, well documented code and
modularity
via plugins.

Download it:
https://sourceforge.net/project/platformdownload.php?group_id=203597
Start it via Java Webstart: 
http://travelingsales.sourceforge.net/ts-stable.jnlp
Changelog:  
http://travelingsales.sourceforge.net/bugs/changelog_page.php
Announcement in the forum:  
http://apps.sourceforge.net/phpbb/travelingsales/viewtopic.php?f=3t=63

V1.0.0-RC1 was released for bug-fixing up to the release of v1.0.0 planned
next weekend.
Development will continue on the trunk while this release started the
v1.0.0-branch.
The stable release has TMC-support and 2 routing-engines that are only used
as examples
removed and shall contain only stable code.
We also have 2 webstart-versions now:
 http://travelingsales.sourceforge.net/ts-stable.jnlp  and
 http://travelingsales.sourceforge.net/ts.jnlp

- 126: [Route-Finding] IRouteMetric ignored by routers
- 125: [Driving Directions] Way symbol is named as node
- 124: [Driving Directions] RoutingSteps should be combined for driving
instructions
- 123: [User-Interface] wrong ETA
- 122: [Other/Unknown] JGPSProvider crashed when the configured serial
port vanishes.
- 121: [Databases] allow downloading not only bounding-boxes
- 120: [User-Interface] jumping to bounding-box after import wreaks
havok if nothing was importedn.
- 119: [User-Interface] download current area not working
- 118: [Databases] Add FileWriter to FileReader in LibOSM
- 117: [Address-Search] Cities may be place=city or
voundary=administrative with admin_level=7
- 109: [Route-Finding] Fehlermeldung bei Routeberechnung
- 115: [User-Interface] panel to show current Traffic-messages
(Marcuswolschon)
- 103: [User-Interface] emty error message Error while painting map
(Marcuswolschon)
- 108: [Other/Unknown] OpenJDK crashed when TS tries to install
JavaComm for Sun-JDK (Marcuswolschon)
- 107: [Renderers] OSRPaintVisitor does not fall back to
SmoothTilePainter
- 106: [User-Interface] subdirectories of geofebrik not showingin
download-menu (Marcuswolschon)
- 105: [User-Interface] limit length of shown stack-trace in popup
(Marcuswolschon)
- 104: [User-Interface] select default-text in address-search on
getFocus (Marcuswolschon)

changes in the SVN-version for v1.1:
- 091: [traffic-messages(not driving instructions)] parse TMC-messages
by GNC-receivers embedded in NMEA (Marcuswolschon)
- 016: [traffic-messages(not driving instructions)] Add TMC-decoder
(Marcuswolschon)
- 114: [traffic-messages(not driving instructions)] store and update
TMC-messages (Marcuswolschon)


___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] spatial index - B-Tree over z-order curves vs R-Tree over GIST

2009-04-09 Thread marcus.wolschon

On Thu, 9 Apr 2009 02:12:08 +0300, pablo platt pablo.pl...@gmail.com
wrote:
 Hi,
 
 I posted this question in the forum but I think that the list is more
 active.
 
 PostGIS uses R-Tree index over GIST.
 I'm trying to understand if it is possible to use couchDB for storing and
 indexing the osm data.
 couchdb is a schema less db for storing documents. Each document store
data
 encoded as JSON.
 It uses B-Tree index so the only way I know to enable spatial index is to
 use space-filling-curves (z-order, morton codes)
 to translate a lat,lng to a number and then index all the numbers using a
 B-Tree.

From what I found out you usually do not use a Z-curve or Hilbert-Curve
on a 1-dimensional index but you use it while constructing a
never-to-be-changed
2D-tree.
However I could not find any multi-dimensional trees that can do a
rebalancing
in O(1) like an AVL-tree can.

So while this may be a good index for data-sets that never change it
quickly
becomes highly unbalanced in datasets that are changed frequently.

I guess an R-Tree (also called 2D (R)ange-tree) was just easiest with the
existing indexing datastructures they had and it provides adequate
performance.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] SoC Project: Preprocessor to add altitude information to OSM data

2009-04-09 Thread marcus.wolschon

On Wed, 08 Apr 2009 21:24:32 +0200, Hermann Kraus h...@scribus.info
wrote:
 What do you think about this idea: Instead of
 attaching tags to a way I could find all nodes which are shared by more
 than one way and then for each part of a way between two intersection
 create a relation like this:
 type=metainfo
 alt_difference=10.6
 alt_total=27.3
 distance=1032
 with the way and the two intersection nodes as members.
 The distance is easily computed while doing the other processing. So the 

 routing application could skip this step.

Any here are my 2euro-cent

Sounds like a way to go.
With the relations it would be possible to publish only these new relations
(so anybody can merge them with the corresponding planet-extract
 while also merging other data.) as no existing entities are modified.

I suggest changing the name to make it clear
what point alt_total refers to and if distance is the 2d or 3d distance
in meters.

Also note that not all nodes with a degree 2 are intersections of 2 roads.
It may be something else intersecting (e.g. a node with the sign of a city
may be shared by a road and a polygon surrounding the city or it may be
2 power-lines intersecting).

 If I am right then rather then your proposal will need closer
 integration with the routing programme - I think the router will  
 pre-process
 the OSM file to calculate distance between junctions - we will want it
to
 include altitudes at the same time.
 
 I explicitly tried to avoid a strong integration with the routers,
because
 we have more than one and I expect even more in the future. Creating a
 library might be an option, if you think my idea is not really good the
 other way.

I would be willing to add support for your 3d-distance to the metrics
for ShortestWay and StaticFastestWay and for the 3d-distance and and
alt_difference
to my incomplete metric that involves real physics (car accelerating,
maximum speeds in sharp curves, ...). However for applications like this
later metric alt_difference may be misleading as there may be 2 inclines
and 1 decline between the 2 intersections.


 However I still would prefer the preprocessor option since this allows to
 
 publish planet dumps which have the altitude information. When the  
 processing is done by the router one has to publish data for each router 

 seperatly or the user has to download the SRTM data. I want to make this 

 application as userfriendly as possible and what could be more  
 userfriendly than having a world file (or excerpt of it) which already  
 includes the altitude data.

I agree. a preprocessed dump is good for everyone.


 I think your proposal to add a relation is an interesting one - it is
 essentially doing the same thing as the routing program will need to do 

 for
 distances - you can imagine doing the same to calculate distance between
 junctions too, which is what the routing programs will do.   I am still
a
 little unsure how much benefit is gained by your proposed way of doing  
 it,
 rather than directly incorporating it into a routing program - the  
 routing
 program(s) will need to be modified to read your new relations anyway  
 won't
 they?

They need support to read the OpenStreetMap anyway and that dump would be
in
that format. I guess every other format would make it even more difficult
and directly building it into a program would bind it tightly to the
internal
data-structures that one application uses. (They differ widely.)


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] good way to do an automated import

2009-04-08 Thread marcus.wolschon

Hello,

I started writing the tool to do import
of TMC-LocationCodeLists into OSM (will be used for Germany at
first but there are lots of other countries with TMC-data so
I try to make it generic and user-friendly).

One very fundamental question has come up
what is the best or prefered way to have the tool output it's changes?

* It can download the current state of the changed entities and
  write an osmChange (full support of the changeset-comment+generator)
  http://wiki.openstreetmap.org/wiki/OsmChange
* It can download the current state of the changed entities and
  write a josm-file (could be easy to review)
  http://wiki.openstreetmap.org/wiki/JOSM_file_format
* It can upload it's changes directly to the API (no review)

I would like to be able to run it, then review the changes it
wants to make in an editor and only apply them if a large enough
sample looks fine.

I also need to deal with users changing entities between the time
I download them and I upload my changes.
Should I make this one large changeset or one changeset per type
(roads, segments, points) or one changeset per imported entity
(e.g. a motorway, some segments and a number of points)?

I will have my tool store localy what elements have already been
imported and would like it to store the IDs assigned to them
by the API0.6 and the changeset-id (in case I need to rollback
something later). How could I do that?


Marcus



___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] First TMC-support in Traveling Salesman

2009-04-07 Thread marcus.wolschon


Yes, we have it.
Traveling Salesman (http://travelingsales.sourceforge.net), the
navigation-program for OpenStreetMap
has first working support for electronic traffic-messages.

The SVN-version of Traveling Salesman can now parse TMC-messages in
Royaltek and GNC/GNC2-format
received from RDS-capable GPS-receivers, store them and show the user a
list of all traffic obstructions
currently in effect.

This will not be a part of Version 1.0 as much remains to be done.
Full TMC-support It is planned to a part of release 1.1 later this year.
This depends on the
[url=http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany]TMC-import
into the OpenStreetMap[/url].
All current tests are done with some locations being added to the map by
hand and these locations
are the only one to currently work. It will take at least a few weeks to
get all german locations into the OSM.
Other countries may follow later.

Currently TMC-messages are now shown in the map itself and are not yet used
to affect routing.
Parsing needs to extract much more information then just a text-message to
do that.

...but we are on our way. :)

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Limiting Polygon?

On Mon, 6 Apr 2009 08:01:25 +0200 (MEST), Gary G: g...@gary68.de wrote:
 Hi,
 is there anyone aware of an algorithm that produces a limiting polygon
 around a heap of nodes - let's say around an osm file cut from a planet
 file?


Do you mean the convex hull of these nodes?
If guess with the name convex hull you will
find lots of algorithms.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] JOSM: Several tags with same key

On Sat, 4 Apr 2009 20:09:40 +0100, Matt Amos zerebub...@gmail.com wrote:
 On Sat, Apr 4, 2009 at 7:40 PM, Marcus Wolschon mar...@wolschon.biz
 wrote:
 On Sat, Apr 4, 2009 at 8:14 PM, Matt Amos zerebub...@gmail.com wrote:
 maybe what we need is an amenities tag specifically for multiple
 co-located amenities?

 I strongly disagree.
 That is even harder to parse then the ;.
 
 please explain.

Because it means you have 2 tags instead of one
and the amenities-tag would need a separator like ; anyway.

My use-case is the search for all instances of a given amenity.

 Stefan:
 I really do like the amenity:bar=yes -aproach.
 The current namespace of amenity is preserved,
 an automatic adding of the new name to every place
 with the old one is possible (to have a transition-period)
 and it does solve the problem.
 
 bots are strongly discouraged - if you want people to start using your
 tagging suggestion please ask them.

Guess why I suggested a voting, announcement on talk and some
volunteering moderators? If a voting ends in favor for it, then
the mappers have shown to want it, if not they have opted for
the consequences (amenities sometimes not identified as such or
incorrectly and slower bug-fixing/feature-adding in every piece of
software using them as the developers have even more work to do.).

 i think its better to describe the tags which are actually in use,
 rather than proscribe the tags which are allowed.

 There is a problem with what people are tagging and there
 needs to be a change to this tag to solve it.
 
 no, people are tagging as they see fit. the problem is that, in some
 very rare situations, it is difficult to parse. this is not a problem
 that needs an invasive solution.

That is for the people themself to decide.

 
 This calls for a proposal on the Key:amenity -page with
 a voting announced on talk.
 As the issue affects so many there will be a few people
 needed to play moderator on the Talk-page. Else this may
 end like the license-discussion on the talk-list. (Hearing
 the same thing repeatet over and over again without getting
 anywhere until the threads died.)
 
 unfortunately, as i'm sure we're all aware, trying to change an
 established convention is like trying to push water uphill ;-)

Simple thing, ask the water to cooperate by freezing and if it refuses
stop other actions until you have build some buckets.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] relation-browser broken


http://osm.schunterscouts.de/relation-browser.php?type=relationid=31495

(as linked to by
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bundesstra%C3%9Fen)

gives:

hide tags  | show tags
Warning: fopen(http://api.openstreetmap.org/api/0.5/relation/31495/full)
[function.fopen]: failed to open stream: HTTP request failed! HTTP/1.0 410
Gone in /var/www/web17/html/subdomains/osm/relation-browser.php on line 317
could not open XML input

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] TMC: need comments on import-algorithm



Hello,

on
http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#automatic_import

I sketched out an algorithm for doing the import of the TMC road-network
into OpenStreetMap.

Can some of you please have a look at it?
Especially the cases when relations for streets are not present in
OSM. (I want to reuse the existing type=route -relations of motorways
Bundestrassen and Landstrassen if they are present)

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Export TMC-Event-Table from PDF to CSV

2009-04-03 Thread marcus.wolschon


Hello,

I'm trying to add TMC-support to Traveling Salesman
(http://travelingsales.sourceforge.net).

For that I need the TMC event-table (ISO 14819-2) in
some machine-readable format.
The problem is: I only have the table as a pdf
(https://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel#event-table)
and it contains many empty columns.
With 1590 lines it would be quite a task to convert
that into something computer-readable using regexp
only.

Does anyone have the TMC-events in a machine-readable format?

Does anyone know a tool to copy tables from PDF?
(146 pages, copypaste combines empty columns into just one
 space-character, breaks lines and leaves no separators)


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] GSOC 2009 - Android navigation application

2009-04-02 Thread marcus.wolschon

On Wed, 1 Apr 2009 21:33:44 +0300, Iulian Banaga iulian.ban...@gmail.com
wrote:
As I said my format is based on the Navit's one, and I can say that these
are 80% similar. How did I choose this format? The fact that this app
will
run on mobile devices that are limited in terms of memory and CPU I tried
the existing routing applications on my desktop and I was looking for the
fastest renderer and in the same time one renderer that looks good. At
that
moment Navit seemed the fastest so I spent some time to understand the
ideas
that Navit is using to render.

Okay. Just wanted to check if you did evaluate what was there.
Where did you need to change Navits format? If it was unsatisfactory,
did you send them your patches to have only one format compatible
for both? (Trying to at least slow down growth of the format-jungle here
if I can't unify them.)

I'm looking forward to seeing your code. Especially renderer and the
classes
to read and write your file-format. :)

First of all I was thinking about getting support for routing restriction
in
my app, and Nic (Roets) have done a great job with Gosmore about these.
From
TravelingSalesman I might use the idea of creating a routing interface
that
will be implemented by different algorithms. Both these ideas will
probably
be taken into consideration in the second part of GSOC timeline (starting
July) as I would like to concentrate on getting basic routing
functionality
until the mid-term evaluation.

Sounds reasonable.
You may find the sourcecode of the new
TurnRestrictedMultiTargetDijkstraRouter here:
http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/trunk/osmnavigation/src/org/openstreetmap/travelingsalesman/routing/routers/TurnRestrictedMultiTargetDijkstraRouter.java?view=markup
better commented and as it's java too you could just take it and adapt it
to
your internal data-model. It is an implementaion of Nics aproach to
turn-restrictions.

I just updated the comments and will check it in tonight.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] JOSM and API 0.6

2009-04-02 Thread marcus.wolschon

On Wed, 1 Apr 2009 19:10:37 +0100, Shaun McDonald
sh...@shaunmcdonald.me.uk wrote:
 So if someone downloads and starts using JOSM today, will it
 automatically switch over next month when the API changes, or will
 users need to fiddle their config?

 
 No.
 
 They currently need to fiddle with the config. I believe that on the  
 first day of the API being down JOSM will be updated to by default use  
 0.6, at which point no more fiddling will be needed. I believe that  
 Merkaartor is the same, though the fiddling is a lot simpler.
 
 I'm happy to be corrected if I'm wrong.

Just don't forgat that users have lots of v0.5 -maps still lying on
their hard-disk at and after that date. So the default should also
set alternatice accepted versions.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] GSOC 2009 - Android navigation application

2009-04-01 Thread marcus.wolschon


Hello Iulian!


On Wed, 1 Apr 2009 07:50:19 -0400, Iulian Banaga iulian.ban...@gmail.com
wrote:
 At that time I thought that one of the best solutions to do all of these
 tasks is Navit.

Wasn't Android Java-only or is there support for applications in C?

 I studied the application in more detail and I choose o
 use the same model for data. I had to write my own converter from OSM
 format
 to my own binary format.

What was your motivation to use your own binary format?

Did you look at OsmBin?
What was the shortcommint in Navit's format?

 Right now I am starting on the routing part and I am ready to 
incorporate
 some ideas from Navit. Besides that I believe I will have to use some
ideas
 presented in Gosmore and TravelerSalesman.

Can you elaborate on this some more?
What ideas do you want to combine?

 It will be very nice if I will be accepted for GSOC 2009, as this
 application will definitely get finished in time as I will sustain my
 bachelor thesis in late June. I am waiting for any ideas on the routing
 engine as this is the part that will be most wanted by the end users and
 also the part that will probably require the most time to be able to get
 results in a reasonable time on a mobile device.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] mapnik-image export-tab broken

2009-04-01 Thread marcus.wolschon


On openstreetmap.org the
export-option Mapnik Image
currently  only produces empty images!

osmarender image
produces an HTTP-error code.


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Tool to convert TMC LCL into OSM -ways and nodes

2009-03-31 Thread marcus.wolschon



I just wanted to let you know that in the process
of implementing TMC-support for Traveling Salesman
(http://travelingsales.sourceforge.net)
I just wrote a tool to
* take a TMC LocationCodeList and
* output an OSM-file with all the points as nodes
  and all the segments as ways.
I'm planning to extend it later to output the names
Roads of the LCL too.

These ways are of cause NOT TO BE IMPORTED into OSM.
I am loading them and OSM in 2 separate layers in JOSM
to find out how an algorithm would need to look that
* given OSM and an LCL
automatically finds a mapping of what TMC-LocationCode
refers to what ways/nodes in OSM.
This will be needed to give routing- and navigation -
application in OSM the ability to work with TMC-messages
containing current road-obstructions, traffic jams and
similar messages and change their metrics acordingly.

Did anyone already experiment with TMC in the context
of OSM?

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] country boundary polygons

2009-03-31 Thread marcus.wolschon

Hello Andy.

Have you looked at how I did this in:
http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/trunk/osmnavigation/src/org/openstreetmap/travelingsalesman/navigation/traffic/

it is documented here:
http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=TrafficRuleManager

For each country this test involves first to check with the bounding-box of
the country. If we are not within the bounding-box, we cannot be inside
that country.

Next we test if the node or way is tagged with is_in:country or is_in
and contains either the country-name (case insensitite) or the uppercase
ISO3166 -code of the country.

Next we load the prepared border-polygon of the country and cache it.
Loading the polygon take a lot of time but checks with it are fast.

I'll add a fourth step to be taken if the distance to the simple polygon
is below it's simplification-threshold and use the OSM-ways that make up
the
border in that section then.

It never compares against the full OSM border of the country.

Marcus

On Tue, 31 Mar 2009 13:48:27 +0100, Andy Deakin andy.dea...@pcmend.net
wrote:
Hi,

No major breakthrough here, but if anyone is interested in a quick and
dirty 'what country is lat,lon in' I have created a simple method.

Lookups have been taking about 0.2 seconds, and it involves a binary
lookup file (25MB) at 1/20th of a degree resolution. Boundaries need
further processing for an exact result. If you were only interested in a
smaller area (e.g. Europe) then it could be made much smaller.

Details available here:
http://www.handyandy.org.uk/blog/2009/03/31/what-country-are-you-in/

Andy

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] JOSM and APi 0.6

2009-03-30 Thread marcus.wolschon


I just wrote a program to convert the Points and Segments of
a TMC LocationCodeList as an OSM-file for easy analysis.
(I'm trying to find the OSM-ways for TMC-messages without
 embedding the TMC-LocationCode in OSM as an attribute.)
However as all my codebase is already API 0.6 there is one problem:

http://wiki.openstreetmap.org/wiki/0.6#Changes_in_related_software
lists JOSM as ready for 0.6 but josm-latest.jar complains about
a version-numner 0.6 instead of 0.5 in the file (written by Osmosis)
and refuses to load it.

Is there an 0.6-capable JOSM out there somewhere?

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] JOSM and API 0.6

2009-03-30 Thread marcus.wolschon



Okay, after searching the sourcecode I found it.

By default the config-setting osm-server.additional-versions is not
set at all, thus it only accepts 0.5.
You have to manually set osm-server.additional-versions to 0.6
to accept both. That is only possible with a text-editor or
in advanced-settings (the Einstein-Icon).

Marcus

On Tue, 31 Mar 2009 07:37:29 +0200, marcus.wolsc...@googlemail.com wrote:
 I just wrote a program to convert the Points and Segments of
 a TMC LocationCodeList as an OSM-file for easy analysis.
 (I'm trying to find the OSM-ways for TMC-messages without
  embedding the TMC-LocationCode in OSM as an attribute.)
 However as all my codebase is already API 0.6 there is one problem:
 
 http://wiki.openstreetmap.org/wiki/0.6#Changes_in_related_software
 lists JOSM as ready for 0.6 but josm-latest.jar complains about
 a version-numner 0.6 instead of 0.5 in the file (written by Osmosis)
 and refuses to load it.
 
 Is there an 0.6-capable JOSM out there somewhere?
 
 Marcus
 

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Simplified street-network - solved

2009-03-19 Thread marcus.wolschon


I found a solution to merging the parallel lanes of dual-carriageways
before doing polyline-simplification.

You can find the code in:

http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/libosm/src/org/openstreetmap/osm/data/LODDataSet.java?view=markup
Method: mergeWays(final Way part, final WayBuilder existing)
Line:   716 

and 

http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/libosm/src/org/openstreetmap/osm/data/WayHelper.java?view=markup
Method: ListNode isParallel(final ListNode aFirstWay, final ListNode
aSecondWay)
Line:   569 

the simplified maps look much better and can be painted much faster
then before.

Next step will be a faster polyline-simplification without trigonometric
functions.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] planet.openstreetmap.org breakage

2009-03-19 Thread marcus.wolschon

On Thu, 19 Mar 2009 20:23:23 +1100, Brett Henderson br...@bretth.com
wrote:
 Stefan de Konink wrote:
 On Thu, 19 Mar 2009, Shaun McDonald wrote:
 Please; why don't we just ignore all previous planets and create a
 new planet and start to produce daily (full) history? Where we dump our
 old history excluding Teleatlas data first.

 Nobody cares for aging planets from a perspective of usefulness, the use
 case for older planet is the recovery of history, thus provide history
 instead of older planets.
   
 Osmosis will provide the capability to do this from 0.6 onwards.  If 
 disk space isn't an issue on the planet server I'll set it up as soon as 
 I get time after 0.6 goes live.  It has the ability to go back in time 
 and produce full history diffs for any time interval in the same way it 
 currently has the ability to produce delta diffs for any time interval.  
 Again, if disk space isn't an issue I can create them for the life of
OSM.


When do you plan on going live with 0.6 ?
Last time I checked it read osmosis 0.30.2 .

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [osmosis-dev] Continuous Integration

2009-03-19 Thread marcus.wolschon

On Thu, 19 Mar 2009 22:28:51 +1100, Brett Henderson br...@bretth.com
wrote:
 Hi All,
 
 To help with the situation where not everybody has the time or 
 inclination to setup mysql and postgres databases for running test 
 cases, I've setup the Hudson Continuous Integration server on my home 
 server.
 
 http://www.bretth.com/hudson/
 
 It polls SVN at 55 minutes past the hour and kicks off a new build with 
 full unit tests if changes have been made.  Anonymous users can trigger 
 builds using the Osmosis Play button but (hopefully) can't change 
 anything else.
 
 Let me know if you have any suggestions or see any issues.  The 
 artefacts it produces are not yet being published.  Not sure when I'll 
 get around to that.


Cool.
We should document this in the wiki.
I'm not sure how yet.
Maybe a subpage Development where this, the SVN,
the osmosis-dev -list, checkstyle-rules and and
the plugin-howto are mentioned?

PS:
I found out that the plugin-class is optional and stripped
down the howto.

Marcus

___
osmosis-dev mailing list
osmosis-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

[OSM-dev] Simplified street-network

2009-03-18 Thread marcus.wolschon


Hello everyone,

did anyone else ever work on simplifying the polylines for
low zoom -rendering or similar purposes?
Any algorithms, websites or books that may help me?

While importing a map into Traveling Salesman I am currently
generating 3 additional filtered maps.
1. These maps contain only the most important highway-types (trivial)
2a. Any 2 Ways sharing a common node but having the same name or ref
are joined (works fine, helps with step 3)
2b. Any 2 ways that are parallel all the time, very close together
and have the same name or ref are joined (this does NOT work yet)
2c. Ignore 2a and 2b if there is a relation with type=street or
type=combined_way
and combine its elements with rule 2a and 2b instead of looking at the
name/ref.
3. The resulting polylines are simplified with 2 rules:
3a. Any node who's removal causes a course-error of less then X is removed
(this eleminates unimportant nodes in long curves and straight lines)
3b. Any node that is less then Y in distance from the last node is removed.

These steps are executed in an online-algorithm (and need to be executed
that
way) = one new way-entity at a time. So at all times I have the full and
simplified
map as it looked after the last step and 1 new way-entity.

My problem lies with adding the new rule 2b here.
Having this would make the map render much faster (less ways to render)
and even look nicer (because these 2 usually overlap in rendering).

I can already determine if 2 ways A and B are parallel for all the length
of one
of them and sort the nodes of B into the other way A.
However usual motorways are made up of segments and I'm having quite a hard
time comming up with a rule to still make rule 2b work for the next segment
that attached to B as the end/start -node of B may not be an inner node in
A
and no longer the first or last node.

Requirements:
* The user may import a map of any size with already having a map of any
size.
* Any means way more data then there will ever be main-memory.
Thus I cannot first collect all ways, grouped them by street and then
simplify.
* map-import must be fast. This is something the user is supposed to do
every
  now and then. For small imported maps he is supposed to do this before or
  while driving (get the latest map-updates for the part of the world
between
  start and target = never route using a map that is half a year old).
* the map is stored in osmbin-format. There is no way I can force an
end-user to
  install a postgis or mysql-gis on his nettop/laptop/carpc/smartphone just
to
  have a navigator while the commercial ones work on off-the-shelf
cellphones.
* no native code (sorry, can't use your super-cool graph-library
cross-platform)


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Simplified street-network

2009-03-18 Thread marcus.wolschon

On Wed, 18 Mar 2009 11:30:18 +, Andy Deakin andy.dea...@pcmend.net
wrote:
Hello everyone,

did anyone else ever work on simplifying the polylines for
low zoom -rendering or similar purposes?
Any algorithms, websites or books that may help me?

There's been a small amount of work on this in mapnik-rendering
circles, but mainly using postgis' simplify(linestring, integer)
function. I don't have info from anyone who's looked into it further
from an algorithm point of view.

Check out the google maps encoded polylines or vertex reduction
algorithms.
I (and many others) have written algorithms to say which levels a
polyline point should be visible at on google maps.

e.g. (not mine!)

http://facstaff.unca.edu/mcmcclur/GoogleMaps/EncodePolyline/algorithm.html

Thanks.
I compared it to my implementation at
http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/libosm/src/org/openstreetmap/osm/data/WayHelper.java?view=markup
line 360-403 and it seems to be doing the same thing.
Except that they store more then the final level of detail.

I may add additional attributes to the simplified ways to have multiple
simplification-levels in a single map. (Have each node of a way contain the
number of next nodes to skip in a given zoom-level.
Like key=LODDataSet:skip( + wayid + )( + lod-level + ) value=3).
This way a single low-detail map may contain multiple levels of detail.
And renders that support it can make use of that without breaking renderers
that do not.

I like that idea. :)

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Traveling Salesman is looking for a logo/icon



The current logo-proposals for Traveling Salesman at
http://apps.sourceforge.net/phpbb/travelingsales/viewtopic.php?f=7t=37
make use of a part of the OSM-logo.
Who can be asked for a definite answer about if we
as a Navigator for OSM-maps can do so (copyright any stuff).

Marcus



On Mon, 16 Mar 2009 10:22:16 +0100, marcus.wolsc...@googlemail.com wrote:
 Hello everyone,
 
 with API 0.6 also Version 1.0 of Traveling Salesman is comming
 up. (http://travelingsales.sourceforge.net)
 It is a navigation-program for OpenStreetMap started in 2007
 that is especially modular and well documented to apeal to
 developers wanting to experiment with advanced features no
 commercial navigator can offer.
 
 As it's version 1.0 draws near there is still one thing missing
 ...an icon or logo.
 
 If you have any suggestion as to the possible content of such
 an icon or maybe even some skill at drawing/pixeling some draft
 please feel invited to join the discussion in the forum below.
 
 Forum-Thread:
 http://apps.sourceforge.net/phpbb/travelingsales/viewtopic.php?f=7t=37
 
 Regards,
 Marcus
 

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] detecting street made up of multiple lanes


Hello,

I am currently presented with a quite puzzling problem.
For low zoom levels Traveling Salesman (or more exact, the LODDataSet)
merges streets that are broken up into multiple ways
into as few ways as possible and then simplifies these polylines.

Now there are road-constellations (first detected in Helsinki, Finnland
Bug-ticket: http://travelingsales.sourceforge.net/bugs/view.php?id=52)
where roads start as 2 parallel ways with oneway=true, then merge into
a single way and then split up into 2 parallel ways with oneway=true again.
One example would be name=Pakilantue near the crossing with name=Kehä
I.
Another example would be pretty much any german motorway.

I would like to detect such ways and merge the 2 parallel ways into a
single one.
My question:
Given only the 2 parallel ways and their nodes, how could I detect these
to be 2 lanes of the same street?

I know/I can assume:
* they have the same namd and/or ref
* both are oneway=true

I can not assume:
* that both ways meet at a common point like in Helsinki


Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] detecting street made up of multiple lanes


I may have found an algorithm myself:

Input: way A, way B with the same name/ref
Output: true if all of A(or B) is parallel to B(or A)

foreach Node a in A do:
  if distance(a, B)  X then
return false;
  endif
done

foreach Node b in B do:
  if distance(b, A)  X then
return false;
  endif
done

return true

Note that I don't care about oneway=true as this is for
rendering low zoom levels (LOD1=a whole city, LOD2=a whole state, LOD3=a
whole country/continent)

Marcus


On Tue, 17 Mar 2009 12:55:00 +0100, marcus.wolsc...@googlemail.com wrote:
 Hello,
 
 I am currently presented with a quite puzzling problem.
 For low zoom levels Traveling Salesman (or more exact, the LODDataSet)
 merges streets that are broken up into multiple ways
 into as few ways as possible and then simplifies these polylines.
 
 Now there are road-constellations (first detected in Helsinki, Finnland
 Bug-ticket: http://travelingsales.sourceforge.net/bugs/view.php?id=52)
 where roads start as 2 parallel ways with oneway=true, then merge into
 a single way and then split up into 2 parallel ways with oneway=true
again.
 One example would be name=Pakilantue near the crossing with name=Kehä
 I.
 Another example would be pretty much any german motorway.
 
 I would like to detect such ways and merge the 2 parallel ways into a
 single one.
 My question:
 Given only the 2 parallel ways and their nodes, how could I detect these
 to be 2 lanes of the same street?
 
 I know/I can assume:
 * they have the same namd and/or ref
 * both are oneway=true
 
 I can not assume:
 * that both ways meet at a common point like in Helsinki
 
 
 Marcus
 

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] extracting house-number from string

On Tue, 17 Mar 2009 14:22:44 +0100, Udo Giacomozzi udo@nova-sys.net
wrote:
 SB I didn't see how the algo would prefer 1234 over 1st because both are
 numbers...
 
 Well, you could give the last number precedence.
 
 Or do you have an example where the house number is at the beginning and
 the
 string ends with another number?
 
 Either way, in a situation where you have two possibilities (either
1234
 is the house number or 1ST) it shouldn't be a problem to try both
 addresses (ie. lookup in database). Seems rather simple to me.

That's actually a good idea. Thanks

 By the way, is the input field for the city a different one, or can
 the user put country + city + street + house number all in one string?

In my case its zip+city and street+house.

Marcus
 

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Traveling Salesman is looking for a logo/icon

2009-03-16 Thread marcus.wolschon



Hello everyone,

with API 0.6 also Version 1.0 of Traveling Salesman is comming
up. (http://travelingsales.sourceforge.net)
It is a navigation-program for OpenStreetMap started in 2007
that is especially modular and well documented to apeal to
developers wanting to experiment with advanced features no
commercial navigator can offer.

As it's version 1.0 draws near there is still one thing missing
...an icon or logo.

If you have any suggestion as to the possible content of such
an icon or maybe even some skill at drawing/pixeling some draft
please feel invited to join the discussion in the forum below.

Forum-Thread:
http://apps.sourceforge.net/phpbb/travelingsales/viewtopic.php?f=7t=37

Regards,
Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [osmosis-dev] Licence ...

2009-03-09 Thread marcus.wolschon



I don't care as long as I can still use it in my GPL3-software.

Marcus

___
osmosis-dev mailing list
osmosis-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

Re: [osmosis-dev] Writeable Dataset Support

2009-03-09 Thread marcus.wolschon

On Mon, 09 Mar 2009 21:25:59 +1100, Brett Henderson br...@bretth.com
wrote:
 I've finished writeable dataset support.
 
 The DatasetReader class has been renamed to DatasetContext and now 
 contains methods to get a NodeManager, WayManager and RelationManager.  
 The existing getNode, etc methods have been deprecated.  The pgsql and 
 customdb implementations have been updated  although customdb simply 
 throws exceptions if write methods are called.

Thanks!
I'll have a look as soon as possible and see what I need to do to
provide you with an OsmbinWritableDataset. :)

Marcus

___
osmosis-dev mailing list
osmosis-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

Re: [OSM-dev] Improve the Driving Instructions ... - more flexible grammar

2009-03-05 Thread marcus.wolschon

On Thu, 05 Mar 2009 10:06:43 +0200, Eddy Petrișor
eddy.petri...@gmail.com wrote:
 Pascal Neis a scris:
 Hi,
 to improve the driving instructions on openrouteservice.org I put
 all my languages/translations with a template in the Wiki.
 See http://wiki.openstreetmap.org/wiki/OpenRouteService/Instructions
 
 atm there are the following translations:
 # de_DE - German
 # de_DE_dialects - German dialects
 # en_EN - English
 # nl_NL - Dutch
 # fr_FR - French
 # es_ES - Spanish
 # it_IT - Italien
 # se_SE - Swedish
 
 Feel free to modify or to create new proposals for any language you 
 liked ...
 
 Your proposal assumes that every language of the earth follows the same
 topic and word order as the English language which is incorrect.
 
 Your attempt is doomed to fail if you'll try to constraint the world
 into your wolrd view.

Hello Eddy,

the aproach on
http://wiki.openstreetmap.org/wiki/Sample_driving_instructions
with MessageFormats (phrases with markers where to insert
text-constants) seems to work fine and is what gettext and
the i18n-aproach in Java are using.

We have run into issues with the posibility of languages having
multiple plural forms and adopted the solution gettext() is using.
One simple expression to return the index of the plural form to use
based on the number.

In the case of finish
http://wiki.openstreetmap.org/wiki/Talk:Sample_driving_instructions/fi_FI
we encountered the issue that
a) spoken and written instructions may differ
 (ignored for now)
b) numbers/counts may differ based on what they refer to.
 (worked around for this one case but may come up again)

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Improve the Driving Instructions ... - more flexible grammar

2009-03-05 Thread marcus.wolschon

On Thu, 05 Mar 2009 12:35:08 +0100, Marc Schütz schue...@gmx.net
wrote:
 Hello Eddy,
 
 the aproach on
 http://wiki.openstreetmap.org/wiki/Sample_driving_instructions
 with MessageFormats (phrases with markers where to insert
 text-constants) seems to work fine and is what gettext and
 the i18n-aproach in Java are using.
 
 We have run into issues with the posibility of languages having
 multiple plural forms and adopted the solution gettext() is using.
 One simple expression to return the index of the plural form to use
 based on the number.
 
 In the case of finish

http://wiki.openstreetmap.org/wiki/Talk:Sample_driving_instructions/fi_FI
 we encountered the issue that
 a) spoken and written instructions may differ
  (ignored for now)
 b) numbers/counts may differ based on what they refer to.
  (worked around for this one case but may come up again)
 
 Then there are those languages that have grammatical gender. The English
 Turn right into xxx street/way for example, would be Biege rechts ab
in
 die xxx-Straße/in den xxx-Weg in German, where the article den or
die
 depends on the name of the street. This is currently worked around by
 leaving the article out completely.
 
 Other languages have the habit of inflecting not only normal nouns but
also
 names.
 
 Isn't there software out there that can handle these things? Maybe we
 should have a look at MediaWiki. They seem to take grammar into account.

I am not aware of any way to detect the gender of an arbitrary street/city
-name
in a given language. Are you?
Mediawiki simply uses text-constants saved as pages in the
mediawiki:-namespace.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] HTTP OSM Server - index

2009-03-04 Thread marcus.wolschon

On Wed, 4 Mar 2009 20:08:40 + (UTC), Dick d...@mrns.nl wrote:
 marcus.wolschon at googlemail.com writes:
 What data-structure are you using for the index?
 Are you aware that such indice already exist if usingthe
 OsmBin data-format created via osmosis instead of the xml?
 http://wiki.openstreetmap.org/wiki/OSMbin%28file_format%29
 
 Thanks, I'll take a look at OSMbin as well!
 
 I'm using the following C structures:
 
 struct nodetile {
int id;
short int lat;
short int lon;
 };

So...is your index a list, tree, heap or hashtable, ... of
nodetile/waytile/... -structures?
How is your index stored on disk?
How are the required nodetile-structs loaded
into memory?

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] HTTP OSM Server - index

2009-03-03 Thread marcus.wolschon

On Tue, 03 Mar 2009 19:49:00 +0100, Dick Marinus d...@mrns.nl wrote:

 Currently I'm writing the index generator in C by using libbz2 and
 libexpat. As it takes a while to parse an 5GB bz2 file I'm trying to be
 able to resume the process half way. I'm thinking of using libcurl to do
 the HTTP work for me.

What data-structure are you using for the index?
Are you aware that such indice already exist if usingthe
OsmBin data-format created via osmosis instead of the xml?
http://wiki.openstreetmap.org/wiki/OSMbin%28file_format%29

Regards,
Marcus 

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] auto-generating landuse=residential polygon around highway=residential -streets

2009-02-27 Thread marcus.wolschon

On Fri, 27 Feb 2009 11:18:49 +0100, Roland Olbricht
roland.olbri...@gmx.de wrote:

 What is the particular situation, i.e. what accuracy is necessary? A good

 starting point might be a scanline approach as for the 12-nm-brim, which
is
 a 
 matter of minutes for the entire planet but not very precise:

In LOD1 I don't care for +-10m, in LOD2 +-500m and in LOD2 +-10Km .

The scanline-aproach works fine if you have a complete map and
apply this preprocessing.

However I doing all such operations on the fly.
e.g. the user already has a local map in LOD0-3 and chooses
download-countryX.
First all nodes are handed to LODDataSet.addNode().
Then all ways are handed to LODDataSet.addWay().
Then all relations are handed to LODDataSet.addRelation().

Usually the map already present is much larger then the newly
imported part. Think of having half a continent on disk and
on the road downloading a small strip between start and target(s)
via a mobile phone before starting the route-calculation to update
the part of the map you will most likely be driving on 5 minutes later.

I therefor require the algorithm to work with incremental updates.
I do have fast, indexed access to:
* the residential road currently being added
* all nodes of the road
* all relations the road is a part of
* all relations and ways and relations of the nodes

Thus I can do something incremental like:
* check if an older version of the way added exists and if it is
  related to a surrounding landuse=residential.
1 = if so, enolarge the polygon if we cross it's boundary now and exit
* recursively get all connected residential roads
= if we encounter one related to a surrounding landuse=residential.
2 = if so, enlarge the polygon if we cross it's boundary now and exit
= if we encounter multiple related to different surrounding
landuse=residentials.
3 = merge the polygons onto one and join the 2 relations
* no existing poylgon was found
4 = create a new polygon and a relation with all residential roads
contained and the surrounding polygon

Notes:
* Case 4 should only happen with 1 residential road as the others have
undergone the same algorithm.
* I case 1,2,3 we usually do not visit all ways or nodes except the 1 or 2
polygons and the newly added roads
* This will never shrink a polygon, however I think the impact by this
limitation is neglectable.


Marcus


___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] collecting translations of driving-instructions

2009-02-25 Thread marcus.wolschon



Hello,

I started the page:
http://wiki.openstreetmap.org/wiki/Sample_driving_instructions

to collect translations of driving-instructions for all the
routing and navigation -programs in OpenStreetMap to use.
It is clear that not every project has developers speaking
every language, so we may as well collect a pool of translations.

I tried to give the pages an easy to parse structure,
so that a simple script can extract the translations and
build the .properties, .po or whatever files the individual
program uses.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] collecting translations of driving-instructions

2009-02-25 Thread marcus.wolschon

On Wed, 25 Feb 2009 14:16:52 +0100, Stefan Breunig
ste...@mathphys.fsk.uni-heidelberg.de wrote:
 I wanted to post this on the discussion page, but Wiki seems down.

It seems the wiki went back up in time.
At least I can see your text on 
http://wiki.openstreetmap.org/wiki/Sample_driving_instructions

I made some suggestions for added phrases based on your feedback.
Let's continue this in the wiki then...

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

[OSM-dev] SVN-access

2009-02-23 Thread marcus.wolschon


Hello,

who do I have to ask to get SVN-write-access to check in
patches to Osmosis instead of having to mail them around?

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Ponderings about an improved tagging scheme

2009-02-20 Thread marcus.wolschon

On Fri, 20 Feb 2009 09:24:55 +, G H S tiosan...@hotmail.com wrote:
 Well, I'm not sure that the kind of objects found on a map can't be
 categorized by a sufficiently flexible system.

Like
* objects belonging to multiple types?
* different ways of categorizing the same information?

  Given the name
 OpenStreetMap, I'd think there's a finite collection of object types that
 make sense here.

Given the imagination of people it was proven beyond any doubt
that the collection is infinite.

 Plus, the current system seems to be aiming for more organization than
just
 a free-form collection of tags.  Otherwise, wouldn't we just have an
 attribute called tags, followed by a delimited series of values?

Strange, I was under the impression that our system was quite chaotic
and worked under the 2 rules:
1. just do it or be ignored
2. don't break what others have build or they will get very angry

 
 If we have [attribute]=[value],

if?

 I'd expect to see a defined collection of attributes somewhere.

Dream on. If we had a defined collection, we would not have
tag-keys being user-defined strings.

  As it stands, we seem to have [value]=[some other
 value].  What constrains the left term, as opposed to the right term?

nothing, thanks for noticing.

 How about an orderly collection of attributes (which would cover most of
 what's going on now with things like highway= or natural=) WITH the
 option of a free-form tags attribute for object types and attributes
that
 fall through the cracks?

What about you start working on such an order so that it encompasses
everything
people have already done or are currently doing and we see each other again
in
say... 15 years?

 Given that a major goal of this project is to create a repository of data
 that are machine-readable and -filterable, wouldn't consistency in
tagging
 help quite a bit?

Yes and we achieve consistency by consense.
People do like other people have already done.
Everything else has failed due to being ignored by an army of mappers.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Can not run Osmosis

2009-02-19 Thread marcus.wolschon


Hello Xia,

what version of osmosis have you been using?
Did you compile it yourself or download any
release-version?

BTW: There is an osmosis-dev mailing-list that may
be better a better match for your question.

Marcus

On Thu, 19 Feb 2009 17:46:29 +0800, Xia Zhang boyamy...@gmail.com wrote:
 Hi All,
 
 I just tried to combine two osm into one osm the Osmosis via:
 java -jar osmosis.jar --rx 1.osm --sort --rx 2.osm --sort  --m --wx
 final.osm
 
 However, always below errors.
 
 ===
 2009-2-19 17:39:38 org.openstreetmap.osmosis.core.Osmosis run
 信息: Osmosis Version 0.30.2
 2009-2-19 17:39:38 org.openstreetmap.osmosis.core.Osmosis main
 严重: Execution aborted.
 java.lang.NoClassDefFoundError: org/java/plugin/PluginLifecycleException
 at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:73)
 at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30)
 Caused by: java.lang.ClassNotFoundException:
 org.java.plugin.PluginLifecycleExce
 ption
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClassInternal(Unknown Source)
 ... 2 more
 
 
 Any advise on this? Thanks
 Allan
 

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [osmosis-dev] preprocessing for turn-restrictions usins an osmosis-plugin

2009-02-19 Thread marcus.wolschon

On Thu, 19 Feb 2009 19:32:18 +1100, Brett Henderson br...@bretth.com
wrote:
I'd suggest that we extends the existing Dataset support to expose write
methods. The other option is that we leave the existing one as it is
and provide a new one that extends the current one to provide write
access (allowing some implementations to support read-only access only)
but it's probably just creating extra work for not much benefit. If an
implementation doesn't support updates it can throw a meaningful error
message saying write access isn't supported.

Both ways are fine with me. However for the second one I suggest
a method isWriteSupported().

Existing tasks such as --read-pgsql which don't actually read but just
expose a read-only database handle (the Dataset) to downstream tasks
would need to be renamed. Perhaps --get-pgsql-dataset?

As --read-pgsql does not provide an entity-stream I guess it was
misnamed from the start. What about --access-pgsql ?

The existing Dataset interface exposes the method DatasetReader
createReader(); and the DatasetReader provides a bunch of methods for
reading from the db. This might have to be re-factored somewhat. The
DatasetReader interface might be more appropriately called
DatasetConnection. The Dataset.createReader method might be more
appropriately called createConnection. Alternative name could be
DatasetContext and createContext which is more generic than using the
word Connection which implies an external database but I'm not too
fussy.

Yes, a rename sounds usefull. It was ...quite confusing when I saw
that for the first time and had to decide what Interface I needed
to actually implement to provide random access from a new data-format.

Maybe:
DatasetReader = Dataset or RandomAccessData or Map
Dataset = DatasetFactory or RandomAccessFactory or MapFactory
DatasetSink = DatasetClient or RandomAccessClient or MapAccessClient
as the task need not be a sink for data
comming from the Dataset but be a source for data going into it or
both.
with the tasks named:
--get-XYZ-dataset or --access-XYZ or --XYZ-map

As for the interface-change, I am currently using this:
http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/libosm/src/org/openstreetmap/osm/data/IDataSet.java?view=markup
For OsmBin it has added methods
getRelationsForWay(), getRelationsForNode(), getRelationsForRelation()
instead of just getWaysForNode() .
There is no getAllNodes() or getAllWays(), instead it uses
getNodes(Bounds.World),
however many backends do not scale in that method. (I did not implement for
streaming large areas from the database once they are imported.)

If your new interface is not completely different I can provide you
with tested implementations of random access to
* in-memory data (good for temporary data and unit-tests)
* osm-xml-files (could prove very usefull)
* osm-xml-files split by tile-number with hsqldb for an id-tile index
* osmbin with 3 additional lower-detail maps that are generated and updated
on the fly
(native format for Traveling Salesman)
as well as less tested code for
* hsqldb
* mysql
where you may borrow code to implement the update-functionality
for your existing mysql and postgis -datasets.

Your task could then implement both the DatasetSink and Sink interfaces
allowing it to receive an incoming entity stream, and a handle to a
database. The command line would look something like:
osmosis --read-xml myfile.osm --get-pgsql-dataset
dbAuthFile=authFile.txt --induce-ways-for-turn-restrictions.

What do you think?

Sounds very good.
Is there anything I can help with?

Marcus

___
osmosis-dev mailing list
osmosis-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

Re: [osmosis-dev] Can not run Osmosis

2009-02-19 Thread marcus.wolschon

On Thu, 19 Feb 2009 18:09:08 +0800, Xia Zhang boyamy...@gmail.com wrote:
 Hi All,
 
 I just tried to combine two osm into one osm the Osmosis via:
 java -jar osmosis.jar --rx 1.osm --sort --rx 2.osm --sort  --m --wx
 final.osm

I just noticed the classpath.

Brett: What's your policy on the jar?
fat-jar with all dependencies and database-drivers or small jar?
In the former case you forgot to add the content of jpf.jar to osmosis.jar
in that release.

Xia:
I guess the following will work:

java -classpath osmosis.jar:jpf.jar:commons-logging-1.0.4.jar
org.openstreetmap.osmosis.core.Osmosis
--rx 1.osm --sort --rx 2.osm --sort  --m --wx final.osm


Marcus

___
osmosis-dev mailing list
osmosis-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev

Re: [OSM-dev] Osmosis: Filter way/node without key x - recommendation

2009-02-13 Thread marcus.wolschon

On Fri, 13 Feb 2009 12:57:02 +0100, Rolf Bode-Meyer rob...@gmail.com
wrote:
 2009/2/13 Dave Stubbs osm.l...@randomjunk.co.uk:
 
 It was built against v0.29 of Osmosis which is the version I'm still
 using -- it should work with that.

 I hadn't realised the plugin interface had changed. I'll have to take
 a look some time.
 
 I can't tell if an interface changed but I'm using version 0.30 from
 2009-01-12 which is http://gweb.bretth.com/osmosis-latest.zip right
 now. So I thought that would be sensible.
 In the meantime I also tried the oldest on Bretts site (0.29.5) but to no
 avail.

I recomment we use the plugin-version -attribute to the requires-element
to state what version of osmosis we require when writing plugins and that
the version-attribute of the plugin-element in corePlugin.xml is kept
up to date with the released version-number of osmosis-releases.
This is the mechanism ment to deal with such issues.

Brett: for you this means to look at corePlugin.xml when making a new
stable
release

Dave and me: we should explicitely specify what version of osmosis our
plugins
are for.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Osmosis: Filter way/node without key x

2009-02-12 Thread marcus.wolschon

On Thu, 12 Feb 2009 21:34:21 +0100, Rolf Bode-Meyer rob...@gmail.com
wrote:
 That indeed looks promissing.
 Unfortunatelly one seems to have be a programmer to use osmosis. Every
 problem is presented as a Java exception. Some of them contain at
 least a faint idea of what could be wrong. But something like this
 leaves me clueless:
 
 java.lang.AbstractMethodError
   at
  
com.bretth.osmosis.core.pipeline.common.TaskManagerFactory.createTaskManager(TaskManagerFactory.java:72)

This looks like the plugin was compiled against a different version of
osmosis.
My guess would be, that it was build against the latest development-version
and you are using
the last stable release of osmosis. Something like this.
It's something Randomjunk the developer of the plugin has to fix.
I have not seen any contact-info on his wiki-user-page so I hope he reads
this
mailing-list.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Please help

On Wed, 11 Feb 2009 11:35:25 +0700, Support Team supp...@suartrack.co.cc
wrote:
 Hello guys,
 
 My name is Andreas, I from Indonesia. I just want to know about how i use
 Open Street Map in to my application, like a google maps ?

What kind of application are you developing?
A web-site?
A standalong-application?

In what language?

What do you want to do with or show in the map?

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Rantings about API 0.6

On Wed, 11 Feb 2009 12:11:38 +0100, Raphaël Jacquot sxp...@sxpert.org
wrote:
 Frederik Ramm wrote:
 Hi,
 
 Iván Sánchez Ortega wrote:
 I just finished coding a bulk importer which interfaces directly to the
 MySQL
 DB instead of interfacing to the API.
 
 Well then I say let's just politely ask TomH to open up the MySQL TCP 
 port for public access and create user accounts for us all, and off we 
 go with factor 13 speed. I'm sure everyone will be pleased ;-)
 
 Jokes aside, does your bulk importer also implement populating the 
 history tables, making sure that every node referenced by a way (and 
 every node/way/relation referenced by a relation) actually exists, and 
 all these totally useless integrity constraints?
 
 all this should be mostly handled by the db server with appropriate 
 foreign key constraints, not by the application code

I have to agree.
With a database that is supposed to contain all of the planet
this sounds like the job of a foreign key, not application-level-checks.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] road data in zoom levels

On Wed, 11 Feb 2009 12:39:07 +0100, Patrik Sjöberg patrik.sjob...@bth.se
wrote:
 Hi!
 
 What would be the best way to get data for ways at a specific zoom  
 level? I would like all roads visible on zoom 5 for instance, possibly  
 with lower resolution (fewer nodes per way). I'm guessing something  
 like http://www.informationfreeway.org/api/0.5/way[highway=*] but the  
 API's only seem suitable for quite small boxes.

I will make the way-simplification of the LODDataSet in the
Traveling Salesman -navigator into an osmosis-plugin soon.
http://apps.sourceforge.net/mediawiki/travelingsales/

We use it to combine split ways (like long motorways or coartlines)
and then simplify them to contain fewer nodes.
The resulting ways are stored for rendering low zoom-levels
(a city, state, country or continent) in realtime while the
user is driving.

Marcus

___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Rantings about API 0.6