[OSM-dev] I've done some work on JOSM...

Ed eAi at opencoding.net
Fri Apr 27 17:38:47 BST 2007


Hi,

I've attached a diff of the changes I've made. I've also added the 
"reverse way segments" option, which is essentially the same as the 
other code, it just does the reverse. I implemented this as a subclass 
of the original code, so I haven't had to duplicate code. I've also made 
a few small text corrections and fixed issue #135 (Segment order numbers 
do not respect user's colour prefs). I've also added some code to 
improve the rendering of small areas of large datasets. Instead of 
rendering the whole map, it will now only render the visible area. This 
significantly improves the performance (2fps to 20fps here, with some 
test data).

I've attached 6 diffs of each of these changes, and a diff which 
combines them all.

Ed

Frederik Ramm wrote:
> Hi Ed,
>
>    I'll apply your code tonight and if it all works, it's going to be 
> in josm-latest.jar from tomorrow morning.
>
>> 2. I agree, ideally I think this should be done as automatically as 
>> possible - perhaps before its saved and/or uploaded? I'm kind of 
>> against showing dialogs, unless strictly necessary (more clicks). 
>> I've made it so it will direct the way in the 'average' direction of 
>> the way. I.e. if 75% face one way, the rest will be made to face that 
>> way. I suggest that this, combined with a "flip way direction" 
>> command would solve this problem without needing to pester users when 
>> 99% of the time they want to answer 'yes'...
>
> The "flip way direction" should probably be combined with "reverse 
> segments". As I understand it, if you select a way and click "reverse 
> segments", all individual segments will be reversed but not the order 
> of the way, which sounds counterproductive. But I'll look into that, 
> maybe I'm talking rubbish.
>
> I still think the user needs at least to be informed that segmens were 
> flipped. Maybe as a compromise we can but this in the action's name, 
> so that the action either reads "re-order segments" or "re-order and 
> flip segments" or something.
>
>> Is there a good reason why this can't be done "behind the scenes", 
>> i.e. as ways are created? Is there ever _any_ reason to have a 
>> segment not facing the same direction as the rest of the way?
>
> If you create a way, then select the first node and use the "add node 
> and connect" tool, you will see that new segments are added the "wrong 
> way round", i.e. matching the way's direction. So there is some 
> progress in this direction. Many ways are created incrementally - user 
> 1 creates one bit, user 2 creates another, user 3 merges the bits. As 
> I told you, the direction of segments can have a meaning, e.g. for 
> oneway streets. And there are funny beasts as oneway streets go, like 
> this
>
> o---->o---->o<----o<-----o
>                      |
>                      |
>
> Such a way should really be expressed as two individual ways, but not 
> everybody does it, and we must not put magic into JOSM that suddenly 
> breaks things.
>
>> I'd suggest that we can make it appear to the user that ways have a 
>> direction, but ignore the individual segments. The user then just can 
>> flip the direction of the way, and each time they add a new node or 
>> segment to a way, the way is run through the code I've written so far...
>
> It is already widely agreed in the community to get rid of segments, 
> and make ways just an "ordered list of nodes". It is basically just a 
> question of who does it - who changes the server, who converts the 
> data base, who changes the applet, who changes JOSM, who updates the 
> wiki, who changes Mapnik, who changes Osmarender. Once we get that 
> sorted out, we'll just drop segments for good - they are no use 
> anyway. I'd rather not put more workarounds in now.
>
> Bye
> Frederik
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DirectAllWaySegmentsAction.diff
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070427/a4f3054b/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DirectAllWaySegmentsReverseAction.diff
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070427/a4f3054b/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: newMenuItems.diff
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070427/a4f3054b/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: renderSpeedPatch.diff
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070427/a4f3054b/attachment-0003.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rightClickToSelectSegment.diff
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070427/a4f3054b/attachment-0004.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: capitalisationConsistencyPatch.diff
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070427/a4f3054b/attachment-0005.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: allPatches.diff
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070427/a4f3054b/attachment-0006.ksh>


More information about the dev mailing list