[OSM-talk] JOSM feature requests
Andrew Loughhead
andrew at incanberra.com.au
Sat Aug 5 02:37:48 BST 2006
Thanks for your thoughtful reply Joerg.
Joerg Ostertag (OSM Munich/Germany) wrote:
> On Thursday 03 August 2006 14:29, Andrew Loughhead wrote:
>
>> I hope I am not missing a feature that already exists in JOSM. What
>> I would really like to see is the ability to select, say by drawing
>> a polygon, a sequence of trackpoints from a local gpx file, and a
>> button to turn that set into a segment.
>>
>
> I personally think that directly converting tracks into osm-segments
> without filtering is a really bad idea.
I think we are in violent agreement here :-). I was trying to say that
making effective filtering easily available will let users be more
consistent, and there are the other data quality benefits too. I was
just suggesting a way of allowing selective use and filtering of tracks,
and you have described an another way which exists right now.
I have tried osm-filter.pl. I can't get osm.txt right now, so I can't
use --filter-all, as it fails on finding the osm.txt file. But if I
manually use --split-tracks --filter_duplicate_tracepoints
--draw_filter_areas, it runs. It cleans out some garbage from lost
signal and initial lock very nicely. It doesn't seem to be removing
nodes along straight tracks though. I have read through the script and
it looks like you are using 0.001 degrees to approximate 1 meter? I am
reasonably sure that some of my points would be within 1 meter of a
straight line - I will try to check more carefully.
On the osm part of the filter: is osm.txt the same as planet.osm? Can I
just use JOSM to save OSM data for my area of interest, and call that
osm.txt?
I will try to get gpsdrive up (good that the FC5 issues have just been
sorted!), to try out the deny and allow area feature of osm-filter.
> The problem is, that you have thousands of small segments. This might
> seem perfect in the first view. But looking at it more tight it
> reveals some severe problems. One problem is that once you find that
> you want to do something with these segments (tagging, way creation,
> ...) it takes 10 times the time than if you would have reduced the
> number of segments in the first place. Another problem is routing. A
> software doing routing based on these segments will take 10 times
> longer than on a reduced dataset, since it has to try 10 times more
> segments to find your way to the destination. As you see, it not only
> blows up the database, but does not bring more information into the
> database. If you try to convert the tracks into segments you should
> first filter them. This is what I already started with osm-filter. In
> osm-filter the tracks are filtered and reduced by various criterias.
> Some are: - 3 or more trackpoints which are in a streight line get
> merged to a single segment - Segments which are near an already
> existing OSM-Segment get dropped - Segments which have a
> speed/distance/timegap over a specified limit get dropped There are
> some more planed filter features. Which might help in simplifying
> your tracks later: - Filter duplicate tracks: This would filter
> tracks where you drove a street in both directions or where you drove
> a street twice in one track. - Filter GPS inaccuracy blobs: You know
> these blobs which get created once you are a little longer at the
> same place. osm-filter can recognize these blobs end drop these track
> segments automagically. - ... And many more
>
> You can also add more filters to this program. My idea was to create
> a framework for everyone to add the filters he needs. So anyone is
> welcome to add new filters to this framework. You simply have to copy
> one of the filter stubs and add your filtercode in there. Voila you
> have your new Track filter. So my goal in the long term is to be able
> to throw a new track at osm-filter and then to get an almost ready to
> import osm-segment file. This would also include some basic tagging.
> You could also classify the segments by looking at various aspects of
> your incoming tracks. Some classifiers would be: - Area Germany,
> speed between 80..130 --> Landstrasse - Area Germany, speed between
> 80..180 --> Autobahn - a circle with a diameter less than 500m and
> more than 180 degrees --> Autobahn start/end - Speed drops to less
> than 30Km/h, angle of turn is more than 80 Degrees --> Change
> between 2 Streets - ...
>
>
>
>> I know I can turn an entire gpx file into a "data layer", but what
>> I want is to pick a good bit from a track file, where the gps track
>> is clear and the road does not need interpretation, and easily
>> convert that into segment and way data. It could save lots of node
>> creating and segment linking time.
>>
>
> To pic an area you can use the --limit-area function of osm-filter.
> You simply define a waypoint, with a type filter.allow or
> filter.deny in the center of the area of (non)interest in gpsdrive.
> You then define an proximity(in meters) around these areas. The
> ~/.gpsdrive/way.txt file then looks like this: de_Dottingen
> 48.411430 9.492400 filter.allow 0 0 0 20000 which would allow a
> radius of 20Km around the waypoint de_Dottingen. This Area will be
> displayed in gpsdrive as a blue circle.
>
>
>> Going on from that, I know osm-filter.pl offers some data
>> simplification ability.
>>
>
> I think the only feature(s) in josm I'd like to see for filtering
> would be: - snap to track: which would snap to the nearest trackline
> when you click for generating a node. - set waypoint/filter area:
> which would create a waypoint in the file way.txt described above
>
>
>
>> It would be great if JOSM could do similar things, in terms of
>>
>
> I think having two programs do the same stuff reduces the manpower of
> programming skills we have. And we always have a great lack of
> programmers contributing to the project. So i would suggest to keep
> the efforts focused. So my suggestion is to focus on one program to
> do the task of filtering and make more people contribute filters for
> our then chosen main filter.
>
>
>> being able to simplify tracks where appropriate. For example, I
>> could first create a draft sequence of segments straight from gpx
>> data as
>>
>
> What I currently do is create a draft gpx out of the raw tracks with
> --filter-all applied. Then I have a look at them in josm. Then I
> define additional filter areas if necessary and then i import the
> resulting *.osm File into an empty josm, then i delete the
> unneeded/unwanted segments. After saving them to a file, i can merge
> them with livedata from the OSM Server. I then have another look over
> the result(check duplicates, ...) and if all this looks good; i can
> upload my new work to OSM.
Thanks for the run through. I will try that sequence out.
cheers
Andrew.
>
> -
>
> Joerg
>
> _______________________________________________ talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>
More information about the talk
mailing list