Re: [josm-dev] make slippy map a core feature (now #3717)

[Sebastian Klein]

Let's move the bug tracking discussion to trac:

https://josm.openstreetmap.de/ticket/3717

___

Sebastian

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

Re: [OSM-dev] JOSM source

[Sebastian Klein]

kamélia BENCHEKROUN wrote:
> Matthias,
> 
> Sorry, I'm connected throw the network of my school and i don't have any 
> idea about the responsible.
> 
> Now I wanna work with JOSM in order to understand well how to develop an 
> API. I've already downloaded JOSM, but i still don't know how to accede 
> to the code and how to study it.
> 
> Thanks.
> Kamélia.
> 

Hi Kamélia,

Here you can find the documentation, on how to get the josm code and how 
to compile:
http://josm.openstreetmap.de/wiki/DevelopersGuide

__

Sebastian

P.S.:
Please don't reply to a mail and then talk about something completely 
different. You should send your question directly to the list, so open a 
new topic.

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

[josm-dev] Painting (was: how does the transition to tested work ?)

[Sebastian Klein]

Dirk Stöcker wrote:
> A class to display a subset of the database in an own widget would be
> very helpful! There are multiple places in JOSM were we could use 
> that. With lots of reworking done regarding data storage maybe it is
> possible to do that now. And best would be if selection does also 
> work for this.

Maybe a rework of the painting code could make it faster, as well. 
Currently for each "rubber-band" line a full repaint of the entire map 
is done. There is no caching, it just draws each object of each layer 
for every mouse move event.

Consequently the drawing is quite slow if you are in a crowded area. 
However this goes away if you zoom in enough.

Ironically we do unnecessary double buffering: It does not make a 
difference if you remove that offscreen buffer code in MapView.paint, 
except it is faster. (Apparently Swing does it's own double buffering 
unless you turn it off with setDoubleBuffered(false). This is on 
Linux/gnome, might be different for Windows and Mac.)

I think we should cache all static data (osm objects, gpx layers, photo 
layer, ...) in a static cache that has to be marked as "dirty" if a 
repaint is needed. (E.g. when an object was deleted or layer visibility 
was toggled)

Then the rest can be drawn on top like it is done now.


Repainting is especially annoying when zooming and panning in a large 
dataset. For zooming there is not much we can do about it, but for 
panning it might be possible to reuse parts of the buffer by translating 
it accordingly.

__

Sebastian

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

[josm-dev] Endless bugfixing (was: Plugins not working with 3094 and Linux ?)

[Sebastian Klein]

Dirk Stöcker wrote:
> JOSM should be a bit more stable, but I also don't like to wait 
> endless. JAVA6 will come end of month latest and JAVA5 users will 
> have to live with the version we have by then. Would be nice if the
> plugin issues and some other serious stuff can be fixed till then. If
> there are really bigger issues and users of JAVA5 have no other
> chance, then a bug-fix branch can be made if a maintainer for it can
> be found (which I doubt).
> 
> If we have a very stable version tomorrow, then JAVA6 can come friday
>  :-)

We are fixing bugs for 2 months now, so time can't be the issue. We have
to clearly identify the bugs that need to be fixed, then just do it and
move on. The new stuff is probably piling up in the local repositories,
this stagnation is quite annoying.

So i can partly understand why Karl pushed out [3102] but it introduced
a couple of bugs and there may be more to come. Do we really need this
right now?

And Dirk, you do the final decisions, so could you please be a little 
more verbose and clearly state what you think needs to be fixed? 
Especially if deadlines are missed, a status update wouldn't hurt.

Happy coding :)

__

Sebastian

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

Re: [josm-dev] Endless bugfixing

[Sebastian Klein]

Karl Guggisberg wrote:
> Hi
> 
> I'm only aware of one defect related to 3102 (Sebastian, you've reported 
> it today) and this one
> is fixed. What other defects related 3102 are you referring to?  

I mean #4705. If you think there are no more problems, then it's fine.

> Actually 3102 has been
> *fixing* four defects (or closing two tickets and fixing two unreported 
> defects).
> I've added a warning when I checked in 3102 because I knew that there 
> was some
> risk but from my interpretation JOSM is currently exactly in the phase 
> where these risks are taken.
> 
> My interpreation was that a tested was  pushed out (~ a week ago it 
> appeared on the JOSM home page) and that JOSM started
> another of JOSMs traditional "cylces". If the question is whether we
> "really need this right now", then my intrpretation would be:
> yes,that's exactly how people have been working on JOSM in the past. 
>  From my point of view JOSM  would
> currently focus on  new features and larger reworks before another 
> stabilization phase  towards the end of such a "cycle".

So it is simply a misunderstanding as i think we are not there yet, and 
still stuck with bugfixing. So sorry about false accusations, I don't 
know who is to blame. Actually the developer wiki page was quite useful 
for tracking status.

> I don't like the traditional approach of JOSM developoment enough to 
> advocate it, though. I'd be
> happy if things changed. From todays emails I learned about the 
> following plan:
> * there is yet another "tested" planned for end of this month latest, 
> perhaps for next friday
> * it's going to be the long announced last "tested" for Java 5

Which implies for me, there are no new features before that. (Of course 
the mail came after the commit.)

__

Sebastian

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

Re: [josm-dev] Another 66 relations bite the dust

[Sebastian Klein]

Richard Fairhurst wrote:
> But it appears to be a similar issue to these postings which posit 
> possible causes:
>http://lists.openstreetmap.org/pipermail/josm-dev/2010-April/004276.html
>  
> http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005359.html

The first two links refer to the problem that a conflict on relations 
can easily lead to removal of all members, so I guess it's a different 
topic.

> http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005363.html
>  
> http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005368.html

These posts describe a well known problem [1], but no one came up with a 
solution for it so far. With the current API it seems to be practically 
impossible to have a complete list of referrers for all the objects in 
the data set. This causes holes in route relations, but it shouldn't be 
a 'relation killer'.

> FWIW I suspect it isn't a _bug_ as such, but rather that the UI is 
> unclear (at least to novice users) such that it is too easy for the user 
> to mistakenly delete/blank the relations. Again, deleting many (66) 
> relations that you haven't intentionally touched, or entirely deleting 
> large (893-member) relations, is likely to be an error in most 
> circumstances: the user should be made aware of what they're doing in 
> terms they are likely to understand.

Without good user feedback it's not easy to remove these traps.

But anyway, it shouldn't hurt to add some heuristics that detect unusual 
pattern (like deleting a whole bunch of large relations) and give a 
second warning before upload.


Sebastian

[1] http://trac.openstreetmap.org/ticket/2652

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

Re: [OSM-dev] start of gwtosm the google webtoolkit port of josm

[Sebastian Klein]

Andrew Gregory wrote:
> On Mon, 31 May 2010 00:40:57 +0800, Peter Körner   
> wrote:
> 
>> Am 30.05.2010 17:22, schrieb jamesmikedup...@googlemail.com:
>>> I am happy to say, have made some progress.
>>>
>>> gwtosm now can display simple roads.
>> I'm sorry but I'm really not sure what this is all about. Josm is
>> designed as an offline editing tools. Why bend'n'break it to run in your
>> browser? We already have an online editor called Potlatch.
> 
> I think a web-based online editor that doesn't rely on a plugin would be a  
> good thing.

+1

@jamesmikedupont: What is your vision for this project? Do you try to 
create a cut down version of JOSM that runs in a browser or will it be a 
completely new editor that happens to reuse some source code from 
another project?

What are the limitations of a gwt/js port? Is it still possible to open 
a local gpx file or do I have to upload it to some server, first? Same 
question for image files.

Anyway, great idea, let's see how it performs compared to the java version!


Sebastian

PS: Maybe you can find a better name for this... What about JOSM-- :)


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

[josm-dev] Extending Undo

[Sebastian Klein]

Upliner wrote:
By the way, what do you think about making merge layers 
operation undonable? I think I can implement it, there is some 
groundwork for in reverter and fuzzer(ext_tools) plugins.


Cool. I see 2 paths here: First would be to have an undo stack for each 
data layer. Normally there is no reason you have to first undo all later 
operations on layer b before you can undo things on layer a. (Although I 
never had that problem.)


Second, make higher level layer operations undoable. (Only thing that 
should be excluded is toggle of active layer and visibility.) Undo of 
merge layer would probably the most useful extension here.


The first would be similar to a text editor where you can undo for each 
document and second would be like photoshop or gimp, where layers 
interact more closely.


Maybe both is compatible? E.g. a checkbox in command stack to show only 
the operations on the current data layer.



Sebastian


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

Re: [josm-dev] problem in josm

[Sebastian Klein]

davinder kumar wrote:

hello everyone ,
this is davinder kumar
my problem is that i am using josm -tested .jar version 3094
i have enable plugin columbus in it.
 which is used for open open .cvs files .
but when i put my .cvs files in my hard disk, after browsing and uploading
 it does not play sound .but when i browse these files from my pendrive it
works with sounds .
can anybody help me
regards davinder kumar


www.davinderkumar.co.cc
www.csegndec.co.cc


Thanks for reporting the problem. Please post it here again: 
https://josm.openstreetmap.de/newticket (JOSM bug tracker)



Regards, Sebastian

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

Re: [josm-dev] JOSM and Java 6

[Sebastian Klein]

Sebastian Klein wrote:
I guess we also need a message box for Java 5 users trying to run JOSM 
 >= 3378. Currently it shows only the generic "This is always a coding 
error"-Box.


Done. (In [3417])

The following classes need to be Java 5 compatible for this message box 
to show up:


JOSM
org.openstreetmap.josm.gui.Main
org.openstreetmap.josm.gui.MainApplication
org.openstreetmap.josm.tools.I18n.

(@Override for interfaces implementations is OK.) All other classes 
shouldn't be a problem.



Sebastian

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

Re: [OSM-dev] Revert request

[Sebastian Klein]

25or6to4 wrote:

Hi all,

I have a revert request on
http://www.openstreetmap.org/browse/changeset/5441813.  For some reason JOSM
cut out on me, and before checking, I reuploaded a section.  Now I seem to
have dupe ways and unlabeled points.  Any thoughts on where I went wrong?


You can revert it yourself using the JOSM reverter plugin! It is 
relatively easy to use: Just enter the changeset id and upload.


The plugin will load the state of the changed objects *after* that 
changeset, then it will automatically apply the changes to your local 
layer that make it undone. (In your case delete the newly created objects.)


Then you can upload normally. (To a new changeset that is the inverse / 
opposite of the previous one.)


In case something has changed in the meantime, you will be notified and 
conflicts are created.



Sebastian

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

Re: [josm-dev] Error messages in Josm

[Sebastian Klein]

Jonas Stein wrote:

i just had a problem with josm. A friend tried to reproduce the steps and
got a different (translated) message.

I suggest to add errorcodes and 
not to translate error messages as things get very improper.
Errormessages could start with 
WW: warning

II: information
EE: error

That could help to filter information.

"Fatal:" seems to be not the best word to describe the situation.


Example 
JOSM will not stop working for german users:


"Fatal: failed to locate image 'markers/Bus Station.png'. This is a serious 
configuration problem. JOSM will stop working."

"Fehler: Das Bild 'markers/Bus Station.png' konnte nicht geladen werden. Das ist ein 
schwerwiegendes Konfigurationsproblem."


Sounds reasonable, but as there are hundreds of error messages, (some 
maybe not shown a single time, yet), it would be a significant burden 
for the developers to follow some rule here. Not the content of the rule 
would be a problem, but the fact that it has to enforced and explained 
to other people.


You might think, "he is just looking for an excuse", and you are right. ;)

Currently, you have at least some differentiation:
EE: error -> "this is always a coding error, please file a bug 
report"-window pops up
WW: warning -> Message on the console starting with "Warning" or "Error" 
or "Fatal"

II: information -> everything else on the console


Your particular case with a missing marker image is clearly a bug as the 
error is not fatal and JOSM will run just fine.


But if there is e.g. a preset image missing, you *want* that message all 
over the screen, so it can be fixed asap!



Sebastian

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

Re: [OSM-dev] Applying outer way attributes to multi-polygons

[Sebastian Klein]

Ben Supnik wrote:

Hi Y'all,

Does anyone have a good set of heuristics for the cases where 
OSM-reading software should treat outer-way attributes as applying to a 
multipolygon?


 From what I can tell there are two possible cases I should look at:

- If the outer multipolygon has _no_ tags (other than type=multipolygon) 
then I should probably go get some attributes from the outer ways, or 
else the whole multipolygon is a no-op.


- If the outer multipolygon only has one way, then __maybe_- that way 
might contain all of the attributes I care about?  This second one makes 
me nervous because I could have a state park way where the boundary of 
the park is a water way with an island in it...the island (inner way) 
might be meant to cut a hole in some attributes (like water) but not 
others (like park).


You can see it the other way around: If the multipolygon _has_ tags 
(other than type=multipolygon), then these tags fully describe the 
multipolygon.


If there are other tags on the single closed outer way (like 
highway=service or leisure=park), then this is an completely independent 
object. In the case of leisure=park it would be equivalent to a second 
multipolygon with these tags and only this single closed way as outer 
member.


The situation you describe (multipolygon: natural=water; outer way: 
leisure=park & natural=water), is a little ambiguous, though: In strict 
interpretation, there would be 2 water areas. This is probably not the 
intention, so I would consider natural=water on the outer way a legacy 
artefact and ignore it.



Sebastian

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

Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)

[Sebastian Klein]

Michael Daines wrote:

Hello OSM,

I'd like to announce my GSoC 2010 project which is nearing
completion,
[...] Questions, comments, and bug reports are much appreciated.
Also, I plan to update the wiki page with more detailed and current
information soon. I believe the editor can be production-ready with a
bit more testing and polish. Let me know what you think!


Great, looks really promising!


Let me comment on the user interface:

 * It would be good to cancel the current operation if you click on the 
map or another object.


 * If you click an object far right, it is hidden by the dialog, which 
is kind of strange.


 * A highlighting on mouse-over would be very fancy.

 * Allow to click POIs that are part of a way.

Another thing I noticed: It creates a new changeset for every operation. 
It should remember the changeset and add subsequent requests to it.


I recommend you have a look at the JOSM presets. They are quite 
comprehensive have been actively maintained for a long time.


Sebastian

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

Re: [josm-dev] Major rework of the presets menu layout

[Sebastian Klein]

Ulf Lamping wrote:

Hi!

I've just done a major rework of the presets menu layout (SVN 3460). 
Hope you'll find it useful.


The trigger for this work was a talk with a local mapper, who wasn't 
even aware that a preset for the address input actually exists ;-)



Goals were:

- add lot's of missing icons from mappaint (bring presets and mappaint 
icons closer together)
- trying to group stuff together that belongs together (making it easier 
to find things)

- split very long menus (to better fit on low resolution screens)
- add some stuff I was missing

In detail:

- (slight) relayout of waypoints entries
- add a new transport/motorcycle section
- whole relayout of water menu entries (water vs. shipping)
- (slight) relayout of travel/tourism entries
- add a new sport/motorsport section
- add a new man_made/food section (selected items from shop section go 
here)

- relayout of man_made/shop section
- whole relayout of places entries
- add a new annotation section
- add some entries came to mind
- other minor changes

I'm still a bit unhappy with the travel and man_made menu layout, but 
even after thinking about it for a while, I couldn't find a better 
alternative layout.


If I'll find some time, I'll continue to bring presets and mappaint 
icons closer together. IMHO it's a bad idea to have different icons in 
the presets and mappaint for the same stuff.



If interested, please review ...


Some things, not necessarily related to your changes:

 * Geography top entry: better use icon for border or landuse rather 
then the icon for place, which is quite similar to "man_made"


 * a lot of entries under "Travel" I would not expect to find there: 
Restaurant, Playground, ...
   for me, "Travel" has also associations with streets and traffic, 
maybe a top level entry "Tourism" would suffice


 * The tag keys (amenity, man_made) are no longer consistently mapped 
to the menu entries - so maybe not use these expressions at all.


 * menu entry Man Made > Buildings is strange as there are a lot of 
buildings in other categories


 * i could imagine top level entry "Buildings", then "Shop" and as 
third level submenu "Foods"


   - annotations -> sub entry of "Buildings"

 * possible category "Service": could include the current amenity, 
financial, health


Just my 2 ct. :)


Sebastian

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

Re: [OSM-dev] Disallowing certain characters in tag keys

[Sebastian Klein]

Hi,

what is the problem with escaping problematic characters? There should 
be build in functions for most languages, like uri_escape in Perl and 
URLEncode.encode in Java.


This proposal [1] moves values into the key to describe conditions. 
(Although you could argue, it should be done like that anyway...)
[1] 
,



Sebastian


Jochen Topf wrote:

Hi!

I am currently fighting some issues where tags with strange characters in them
need to be represented in a URL for Taginfo. Lots of other websites probably
will have similar issues. Characters like /, ?, &, etc. have special meaning
in URLs so if they appear in tags I can't have those tags in URLs. Sometimes
escaping characters as %XX helps, sometimes not. And those problems are not
confined to web pages and URLs only. Special characters that need escaping
are often a problem.

We can't really do anything about that with regard to tag values, they must be
allowed to contain all those characters. But it would help at least a little if
we knew those characters can never appear in tag keys. And I can't really see a
legitimate reason why we need those characters in keys. Looking at the database
almost all cases where they appear in keys are obvious errors. Out of the about
2 different keys, there are only about 190 keys with problematic characters
in them (another about 800 with whitespace). Really the only case that I can't
immediately rule out as errors or see an alternative tagging are tag keys like
"maxspeed:weight>7.5". And with those you can already see the problems: Some of
them have ">" instead of the ">".

So I'd like us to think about whether we can disallow a few characters from
appearing in tag keys. Technically this would mean changing the API to check
for those characters, removing any that are already in the database (can be
done with normal manual edits because there are so few cases) and adding checks
to the editors so that they can give meaningful error messages. Shouldn't be
too hard.

So, what characters am I talking about? I haven't drawn up a complete list
and we certainly would need to discuss this further.

Here is a preliminary list:

Whitespace   Should use '_' instead of whitespace in keys, whitespace are
 also very confusing for users, especially at beginning and end
 of a text.

<>&/+?#;%'"  Special characters in XML, HTML and/or URLs.

\'"  Characters often used for quoting.

=Because its used in many places as the separation character
 between tag key and tag value. If we disallow this, we can always
 treat one string like "foo=bar" as k:foo, v:bar without any
 ambiguities.

This is a small list of special characters, all other characters should still
be allowed. That means tag keys can still be in Chinese or whatever. We'd just
disallow a few characters of which we know that they will make problems again
and again.

And to emphasize this again: I am only talking about tag keys. Tag values must
be allowed to contain the full Unicode set of characters.

Jochen



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

Re: [josm-dev] i18n update issue

[Sebastian Klein]

Claudius wrote:
There seems to be an issue with the i18n update from launchpad. Many 
strings that were translated into German in Launchpad have not made it 
through to the client. For example the "Vacuum cleaner" preset entry is 
in launchpad since october 17th:


https://translations.launchpad.net/josm/trunk/+pots/josm/de/+translate?batch=10&show=all&search=vacuum+cleaner 



...and bastiK did a i18n update in r3639 on 24th ( 
http://josm.openstreetmap.de/changeset/3639/josm ), but still in 3640's 
UI those strings show untranslated. Same applies for "Greengrocer" and 
several other strings.


Claudius


Thanks for reporting the issue. I cannot say what went wrong, but after 
another update [3644], the translations are in.


Sebastian

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

Re: [josm-dev] Removing scale_max / scale_min from elemstyles.xml?

[Sebastian Klein]

Ulf Lamping wrote:

Hi!

Quite a while ago, I've experimented with the map display to show/hide 
features only at a specific zoomlevel of the JOSM map display.


At that time, the display was so slow that removing specific features 
from the map was an idea to speed up the map display. Since then I've 
spend quite some effort to increase the map speed, which made the whole 
scale tag thing obsolete IMHO.


The two values of scale_max / scale_min that are currently spamming 
elemstyles.xml (the mappaint style file) are actually unused AFAIK.


Are there any objections against removing the remaining traces of these 
experiments?


No objections. Maybe we can switch the default value of 
mappaint.zoomLevelDisplay from false to true afterwards. This way 
authors of external style sets can create fancy scale dependent styles 
and don't need to bother their users with advanced preferences 
configuration.


Btw., I have mostly completed mapcss support (which offers zoom 
dependent markup, as well), but it will take some time to integrate into 
JOSM. A lot of existing code needs to be adapted and I don't want to 
break too much...


E.g. the z-index property does not work well with the way multipolygons 
are drawn in the PaintVisitor.



Sebastian

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

Re: [josm-dev] Removing scale_max / scale_min from elemstyles.xml? / mapcss

[Sebastian Klein]

Ulf Lamping wrote:

Am 15.11.2010 23:48, schrieb Sebastian Klein:

No objections. Maybe we can switch the default value of
mappaint.zoomLevelDisplay from false to true afterwards. This way
authors of external style sets can create fancy scale dependent styles
and don't need to bother their users with advanced preferences
configuration.


Makes sense. To avoid any hassle, we may want to remove the scale 
entries first, wait one or two releases and then change the default value.


Generally I don't see any problem since the xml style is distributed 
with the binary. But users who have loaded a modified copy of 
elemstyles.xml would be affected.



Btw., I have mostly completed mapcss support (which offers zoom
dependent markup, as well), but it will take some time to integrate into
JOSM. A lot of existing code needs to be adapted and I don't want to
break too much...

E.g. the z-index property does not work well with the way multipolygons
are drawn in the PaintVisitor.


Do you keep an eye on the performance? Having a new "rendering engine" 
that is able to display a lot of fancy stuff but is also a lot slower 
might be the wrong direction ... ;-)


Yes, I'm aware of this. Currently, the new PaintVisitor is slightly 
slower (basically due to z-level ordering) but not significantly ( < 5% 
I think, but I will do careful benchmarking). All styles are cached, of 
course, so most time is not spend in JOSM code, but with actual 
rendering of areas and lines.



Regards, ULFL

P.S: I'm not a big fan of mapcss, as the XML we currently have makes it 
a lot easier for externals to automatically analyze the rendering (and 
preset) rules files (as e.g. Jochen is currently doing it for taginfo). 
Parsing the css alike syntax isn't impossible, but obviously harder 
compared to XML that a lot of people already know how to do - including 
myself ;-)


Sure, it's not that easy to parse, but it's a matter of priority. E.g. 
you don't design a programming language such that compiler has an easy 
job to parse the source code, but from a user perspective. (Otherwise 
Lisp would be much more popular and Perl much less. :)  )


Another reason for supporting this format is its use in potlatch 2, so 
we might get a second style in JOSM "for free". Maintaining a single 
style must be a lot of work already, so why not join forces a little.


I'm not about to remove the xml style support, though. It will still be 
available and you can even load style files with different formats at 
the same time. (But as I said, don't expect it before Christmas. :) )



Sebastian

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

Re: [josm-dev] How to scale / resize objects ?

[Sebastian Klein]

M∡rtin Koppenhoefer wrote:

2010/11/20 Olivier Croquette :


- modifier for X / Y scaling only



This is often done in applications with dedicated buttons (x-button,
y-button) to restrict/allow modification only in this direction or
even more often with a selection bracket (surrounding rectangle with a
total of 8 squares to grab and drag at corners and in the middle of
the selection bracket's sides).

IMHO those 2 solutions are both user friendly (the bracket-one maybe
more, you find it in many applications and it could also be used to
rotate if you drag slightly outside the corners. Usually [shift] is
used to maintain proportions).


+1 a "selection rectangle" with drag-able corners and sides would be 
very intuitive.


There was an incident where an entire district of Bonn was accidentally 
 rotated and uploaded by an inexperienced user. :)


So it could be separated more clearly by having a dedicated mapmode for 
scale & rotate. The selection mapmode (S) is quite overloaded with 
modifiers already.



Sebastian

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

Re: [josm-dev] sac_scale in JOSM - RFC for change of translation

[Sebastian Klein]

Dirk Stöcker wrote:

 Actually I oppose this solution, as it is against the basic idea of how
 OSM works.


When some mappers (accidentally) spoil the work of many others, this 
is also not the way osm is supposed to work. Extending the description 
in the presets might be a solution, but I'm not sure how this should 
be done.


Hey, the discussion was not about destroying work of others. He blamed 
that people enter ways with "accordinging to his view" wrong 
classification. For me that is the typical issue we also had for streets 
and everything else- People design a classification sheme and get angry 
when it is not used as was planned. But for OSM no experts are mapping, 
so you need to define a sheme which is understood by novice users as 
well. You can't expect from someone mapping tracks to be experts in the 
classification of hiking ways.


As already mentioned, SAC scale is defined by the Swiss Alpine Club, so 
if you say the classification is not well suited for osm, this would 
mean to remove it from the presets and wait for someone to invent a 
better classification.


No one actually wants that, so we are left with 2 choices: (a) Truncate 
description to official reference numbers T1-6, this way viewer people 
will use it, but at least no harm is done and (b) provide sufficient 
explanation in the preset dialog.


Status quo is no solution and (b) requires someone to do the work, so it 
seems sensible to me to go with option (a) in the meantime.



Sebastian

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

[josm-dev] new tested version?

[Sebastian Klein]

Hi,

what about a new tested version this year?

Most problems related to plugin integration should be solved and
imagery seems to be stable. We could target the 30.-31. Dec. nightly
build as "release candidate".

Sebastian

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

Re: [josm-dev] How to update changes in dataSet ?

[Sebastian Klein]

Dirk Stöcker wrote:

On Tue, 4 Jan 2011, Flávio Henrique wrote:


One question that could clarify many things for me:

after calling Main.main.undoRedo.add(new SequenceCommand(tr("My job"),
cmds)), a new calling for method:
nc.getCurrentDataSet().getWays() should return the combined ways (without
the original ones)?


I think so, yes. But I'm not sure. Maybe that is a parallel thread and 
thus asynchroneus. Some of these who had a deeper look into these 
structures lately (Jiri, Sebastion, Upliner) probably know better.


From memory, I would say it happens all in one thread, so there cannot 
be an issue with parallel execution. Why do you think, 
nc.getCurrentDataSet().getWays() returns ways from the previous dataSet? 
This sounds strange, there is only one dataSet at a given time. (Yes, 
and some positional caching.) Note, that the method will also return 
ways that are deleted, so the number of returned ways does not change in 
this case.


Sebastian

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

Re: [josm-dev] single session authenticatoin

[Sebastian Klein]

Mikel Maron wrote:

Hi

In Kenya, we have people often sharing computers. With JOSM, this causes an 
issue, because people forget to change the saved authentication credential to 
their own. You can choose to not save credentials, but this then leads JOSM to 
ask for them on every single API call, which is basically unusable.


JOSM remembers the credentials for one session, even if you choose not 
to save it permanently. Please report a bug (including used version) if 
this is not the case.


Is there a solution to this? Ideally, login/password would only be stored for a 
single session. 


So you like to have an (advanced) option to not show the "save user and 
password" checkbox in the credentials dialog?



Would be a great help to us in Kenya!


There is another option:
 * Create links on the desktop, on for each user.
 * Change the link from
java -jar .../josm-tested.jar
   to
java -Djosm.home=.../josm-user1 -jar .../josm-tested.jar

(Replace "..." by the path to the preference folder for user1 and the 
path to josm-tested.jar respectively.)


This will keep the preferences for each user in a separate folder.

Sebastian

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

Re: [josm-dev] Summer of Code 2011 Ideas

[Sebastian Klein]

Ian Dees wrote:

Hi all!

As admin for OSM's application to Google's Summer of Code this year, I'd
like to remind everyone that we're looking for some project ideas for
students to work on here on the wiki page:
http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2011. The application
deadline is roughly 24 hours away and we only have 2 ideas listed so far.

All OSM-related projects are welcome to add project ideas. Any editors,
tools, or libraries related to OSM should feel free to throw their ideas on
this page so we can have a well-rounded list. Google uses this ideas page as
part of the application process, so we should show them the diverse set of
ideas our community has.

Please feel free to pass this on to other mailing lists!


Anything wrong with copying the "Improved conflict resolution in JOSM" idea 
from last year? There wasn't much development in that area, so this would still be a nice 
project.

Other stuff I can think of at the moment:

* Work on gwtosm project, i.e. create a usable javascript editor based on the 
josm sources.

* Continue signfinder [1] GSoC project from 2009, i.e. create a JOSM plugin 
that reads street names off photos

* Create a scripting API for JOSM. The plugin by Karl already provides the 
infrastructure, so this project could focus on design and implementation of a 
easy to use and robust interface.

[1] 


Sebastian

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