Re: [josm-dev] Checking tags
On Mon, 23 Mar 2015, Jochen Topf wrote: If we have a stricter list whats green we have two problems: a) Users might just ignore it and b) JOSM will even more than it does now, decide whats good and whats bad. And we (as developers) have to be very careful with that responsibility and probably bring this discussion into the wider community. OTOH what I don't want is to mark something as good, which actually is not. We had another request regarding brands and names with a list compiled from database. But here as well quality of that list did not justify marking it special. To keep users from making all green I said light color. light green means we know that tag and it's accepted. grey like now means any other tags light red means we assume tag is bad. If you fear the green causes users to go berserk, than we can only add the red variant showing bad keys. But actually I trust our users :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
On 17.03.2015 11:41, Michael Zangl wrote: Thanks for the feedback on my idea. Based on the feedback and the tests I made the past few days, I wrote a GSoC application. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616 Feel free to leave feedback/your thoughts on this. The comment section on the Melange platform doesn't seem to be public, so I post it here again: Nice application! I'm all for setting realistic, achievable goals. But I was impressed, how much you could do in a small time, and hoped, you would aim for a full (or nearly full) replication of the Java2D rendering. A display without icons is kind of pointless, we don't need another Wireframe mode! Also, the text along line feature is an integral part of the standard style by now, and I wouldn't want to miss it. Keep in mind, that you don't have to implement everything from scratch: As long as you can draw individual letters on screen, it should be possible to build on the existing code for text along line. Yes, this often sounds simpler than it actually is, but you could at least put in on the agenda as a secondary goal. I have looked at your code and was surprised, how complicated it is, to even draw a simple line. This makes me wonder: Have you investigated any higher level libraries, that offer a Java2D-like interface with a JOGL backend? First thing I found was this GLG2D [1]. I know you want to use VBO caching and other low-level techniques, but at least you could copy paste some existing code, to make life easier. Another big issue I have with your proposal, is that you seem to settle with a hard switch between JOGL and Java2D. I.e. either every layer and paint mode must support OpenGL or it isn't used at all. I think this is not really desirable as it restricts the usage a lot. It makes this a toy project and technology show-off, when it could be a general turbo mode that just works for basically every user (with fairly modern hardware). You should investigate, how this can be fixed (can be during the work period). One option would be a Java2D-JOGL bridge like GLG2D. Alternatively, it seems to be possible to mix JOGL and Java2D in certain ways [2]. What are the performance implications? If you come to the conclusion, that it is not possible at all, this is fine, but the results should be documented properly. [1] https://github.com/brandonborkholder/glg2d [2] http://www.java-gaming.org/index.php?topic=10813.0 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Checking tags
On Mo, Mär 23, 2015 at 11:06:59 +0100, Dirk Stöcker wrote: On Mon, 23 Mar 2015, Jochen Topf wrote: You can download the key lists from here: http://tmp.jochentopf.com/bdeda93e7dcc24f27e3822d4c95400b6/ I'm not convinced of that yet in the proposed form. E.g. the good list contains many keys, which we discard on upload. And other stuff which mainly comes from automatic imports, but has no real use to OSM. For me a good list should really be good. This simply means documented and accepted. Essentially this boils down to usage in one of the major presets, the wiki or other highly accepted places. Everything else should be UNKNOWN, even when used a lot. Taginfo has this information, so could you compile a good list based on this instead of the database? Sure, I could do that. But I think we have a misunderstanding here what the green is supposed to mean. When I started this thread I wanted a mechanism to alert users that they might have mistyped something. In that scenario I only warn users that something might be wrong very rarely. Most keys that are commonly used in the database should not trigger that warning. Otherwise users will just ignore it. This is the problem with the current validator. Every time I use it, I am so overwhelmed with things I am supposed to fix, that I just ignore it. Yes, I know I can configure it, but that is complicated and not many people probably do it. If we have a stricter list whats green we have two problems: a) Users might just ignore it and b) JOSM will even more than it does now, decide whats good and whats bad. And we (as developers) have to be very careful with that responsibility and probably bring this discussion into the wider community. I feel much more comfortable with telling users that they should not use the equal sign in keys (because I can't imagine that anybody would think thats a good idea) than deprecating a tag thats widely used. So I think we should introduce the functionality into JOSM to differentiate between good and bad keys/tags, but be very conservative with what we mark as bad. Lets start out with obvious cases and we can later discuss step by step more drastic measures once we have some experience with the functionality. This way we can keep controversy to a minimum (why is my favourite tag suddenly bas) and we avoid overwhelming people with too many problems they need to fix at once. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Setting up Eclipse for plugin development
On 22/03/2015 20:37, Werner Horsch wrote: I was wondering if someone could point to where my error is or give at least some hints First: cd josm/core ant This builds josm-custom.jar. Then plugins should compile with ant dist from their root directories. ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Checking tags
On Mon, Mar 16, 2015 at 07:22:50PM +0100, Jochen Topf wrote: Let me give this a try and we can then look at the created list and see how we like it. Okay, I have generated three lists: good, bad, and unknown. The good list contains those keys we can accept, the bad list contains keys that are really problematic, with strange characters and so on. The unknown list is the large rest. The good list only contains about 8000 keys from over 50,000. But those keys together are used over a billion times while the bad and unknown keys are only used about 500,000 times. So while the key list is short, the overwhelming majority of keys will be flagged as good. You can download the key lists from here: http://tmp.jochentopf.com/bdeda93e7dcc24f27e3822d4c95400b6/ You can see the code for the classification here: https://github.com/joto/taginfo/blob/master/sources/db/post_grades.sql Of course this is just a test and all open to debate. If we actually want to use this, I can create those lists every night with the rest of taginfo. Here are my ideas how to show this to the user: Everywhere there is a list of tags and also in the tag edit dialog we can either colorcode the background of the fields (gree, yellow/gray/neutral, red) or show a colored border or we can show a warning icon next to the field. Just using the color is rather unintrusive and doesn't take valuable screen real estate. On the other hand, the user could hover or click on the icon to get additional info about whats going on. I could imagine marking everything from the good list in green. The bad list is not so useful to mark bad keys, I suggest creating a list of problematic characters and show everything containing those characters as bad. Here is a good starting point for this list: http://taginfo.openstreetmap.org/reports/characters_in_keys#problem Of course we can extend this bad list with known bad keys (very common misspellings) but also with some rules such as keys with 2 characters or less are bad or keys with several characters like :, _, - in a row or at start or end of key are bad. I do realize that this can be only a beginning and those rules and key lists have to be tweaked in the future. I think even my good list contains many keys that are not good at all and should eventually be cleaned up. But at the moment we can't present the users with very often used keys and declare them bad without overwhelming them which would just train them to ignore the good/bad classification in the editor. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Checking tags
On Mon, 23 Mar 2015, Jochen Topf wrote: You can download the key lists from here: http://tmp.jochentopf.com/bdeda93e7dcc24f27e3822d4c95400b6/ I'm not convinced of that yet in the proposed form. E.g. the good list contains many keys, which we discard on upload. And other stuff which mainly comes from automatic imports, but has no real use to OSM. For me a good list should really be good. This simply means documented and accepted. Essentially this boils down to usage in one of the major presets, the wiki or other highly accepted places. Everything else should be UNKNOWN, even when used a lot. Taginfo has this information, so could you compile a good list based on this instead of the database? Also that means to get keys green someone needs to document them - something which sounds sensible to me :-) Here are my ideas how to show this to the user: Everywhere there is a list of tags and also in the tag edit dialog we can either colorcode the background of the fields (gree, yellow/gray/neutral, red) or show a colored border or we can show a warning icon next to the field. Just using the color is rather unintrusive and doesn't take valuable screen real estate. On the other hand, the user could hover or click on the icon to get additional info about whats going on. Color coding sounds fine to me. Thought color must be light, otherwise people will drop anything which is not green. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM
Hi, Thanks for the comment. The main problem I have with the Icons is the packing. I don't want to use a single texture for every icon, since a texture switch is expensive. This can be solved, I already did that in jsettlers and can probably copy some code. The main problem would be to find the icons to pack together on a texture. Icon drawing is already in the current code (if there was a texture present, you could just draw a quad and supply UV coordinates). I also have not yet looked at the text-along-line feature. If it is that simple, I will add it. I never did rotated text with JOGL. Changing the rotation matrix for every call is expensive and JOGL does not expose it's backing texture. So we might need to copy some of JOGLs text drawing (which is basically to use Java2D to draw the text onto a texture and then use that texture on the screen). That way, we could use VBOs, get a really fast text drawing and can rotate every letter as we want to. Using GLG2D is a good idea. I might just add that for all unsupported layers. Although I cannot add it for drawing unsupported things on the OSM layer, it should make most plugins compatible with OpenGL. Drawing Swing components on top of JOGL and the other way around is an option I don't like, since it went wrong the last time I tried it (mouse events not beeing captured correctly, ...). But it might also just need some more tweaking. Michael Am 23.03.2015 um 15:19 schrieb Paul Hartmann: On 17.03.2015 11:41, Michael Zangl wrote: Thanks for the feedback on my idea. Based on the feedback and the tests I made the past few days, I wrote a GSoC application. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616 Feel free to leave feedback/your thoughts on this. The comment section on the Melange platform doesn't seem to be public, so I post it here again: Nice application! I'm all for setting realistic, achievable goals. But I was impressed, how much you could do in a small time, and hoped, you would aim for a full (or nearly full) replication of the Java2D rendering. A display without icons is kind of pointless, we don't need another Wireframe mode! Also, the text along line feature is an integral part of the standard style by now, and I wouldn't want to miss it. Keep in mind, that you don't have to implement everything from scratch: As long as you can draw individual letters on screen, it should be possible to build on the existing code for text along line. Yes, this often sounds simpler than it actually is, but you could at least put in on the agenda as a secondary goal. I have looked at your code and was surprised, how complicated it is, to even draw a simple line. This makes me wonder: Have you investigated any higher level libraries, that offer a Java2D-like interface with a JOGL backend? First thing I found was this GLG2D [1]. I know you want to use VBO caching and other low-level techniques, but at least you could copy paste some existing code, to make life easier. Another big issue I have with your proposal, is that you seem to settle with a hard switch between JOGL and Java2D. I.e. either every layer and paint mode must support OpenGL or it isn't used at all. I think this is not really desirable as it restricts the usage a lot. It makes this a toy project and technology show-off, when it could be a general turbo mode that just works for basically every user (with fairly modern hardware). You should investigate, how this can be fixed (can be during the work period). One option would be a Java2D-JOGL bridge like GLG2D. Alternatively, it seems to be possible to mix JOGL and Java2D in certain ways [2]. What are the performance implications? If you come to the conclusion, that it is not possible at all, this is fine, but the results should be documented properly. [1] https://github.com/brandonborkholder/glg2d [2] http://www.java-gaming.org/index.php?topic=10813.0 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
