Re: [josm-dev] function to find nodes next to a way
On Tuesday, February 19, 2013, Jo wrote: Then I still have to figure out a way to get a list of candidate nodes to test with. That part can be done with a search in a bbox. But my main problem is the list of nodes which form the rectangle polygon. The distance from the way should be configurable and it would be nice if it could 'overshoot' the line by a few meters, for the situation where the road bends to the left and the bus stop happens to be on the outside corner to the right. If this is for a plugin, consider depending on the JTS plugin, then you can use functions like buffering and intersections. Of course the downside is you have to convert to JTS geometries, but see the conflate plugin for one way to do it. Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] MapBox Satellite default?
On Friday, January 11, 2013, Alex Barth wrote: I would love to see MapBox Satellite as per default available in the imagery menu. What's the decision making process for this? I think there's a good case to be made as it's including Landsat and has high res imagery for all of the US using public NAIP data. I thought MapBox Satellite was only available for tracing to paid customers of MapBox? http://support.mapbox.com/discussions/general-questions/9924-using-satellite-images-for-osm-tracing If not, that's great news! Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Progress
On Fri, Jul 13, 2012 at 5:42 PM, Dirk Stöcker openstreet...@dstoecker.de wrote: ... So I want to say a big THANKS to all of you contributing to JOSM. To the developers and supporters still active as well to those who no longer participate. And a big thanks to you for contributing code, running the site, and generally leading the project. I must say when I started reading your message I thought you were resigning. :) -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Selecting a line nearest a point
I have a plugin (conflation) with a custom layer which draws arrows between matched pairs of objects, and I'd like to enable these to be clicked to select the match so it can be merged or deleted. I'm not familiar with JOSM's map display code, so I'm not sure where to look. I need to find the line closest to a point, or more simply the first line which is within N-pixels of the clicked point. It would be nice if it could be performant as well, by only checking lines which are shown on the screen (spatial index?). Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM documentation
On Tue, May 22, 2012 at 2:26 AM, Nikhil Upadhye nikhil.spitf...@gmail.com wrote: Hello Everyone, I am developing plugin for josm as a part of GSoC 12. Details can be found at [1]. I was looking for josm source code documentation but didn't find any. Am I missing something? Can anyone point me in right direction. A good bit of the code is actually well documented with javadoc, though unfortunately the resulting HTML files aren't published anywhere online. You can build the HTML documentation with ant yourself, or just use a good and easy IDE like Netbeans or Eclipse which will let you navigate the code easily. -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Seeking comments on patch for making merge/download undoable
I created this ticket a while ago, and have had a patch up for a little over a week, but haven't had any comments regarding if this functionality is even desired by anyone, is implemented in a decent manner, etc. I'll be using this functionality in the conflation plugin, though I'll probably just copy DataSetMerger to the plugin until the patch has been thoroughly reviewed and tested. https://josm.openstreetmap.de/ticket/7489 Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] continuosDownload plugin naming
I can't find an email address for Gnonthgol, but I'm wondering if he was intentional about using continuos rather than the English spelling of continuous. Small matter, but better to fix it now than later. -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Conflating between layers (merging, marking as resolved)
I've been trying to think of the best way to conflate objects between layers with the plugin I'm working on, and wanted to get some input. The first part is copying or merging objects from a reference layer to the subject (OSM) layer, and the other is marking objects as resolved'. For the first, I think the only two options are copying and pasting the objects (Copy/PasteAction), or merging them (ala MergeSelectionAction). Merging is more robust, but there is currently no undo capability (ticket [0]). For marking objects as resolved, the simplest approach is to keep track of the objects internally to the plugin. However, I can imagine other plugins which would like to know whether an object has been merged/checked/verified/etc, such as a plugin interacting with the Snapshot Server. -Josh [0]: http://josm.openstreetmap.de/ticket/7489 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Soliciting feedback on conflation plugin
Last night I checked in a minimally-functional (and definitely experimental) conflation plugin, appropriately called conflation. You can read more about it here: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation There's certainly a lot of work to do, but it's actually functional enough to automatically create candidate matches between two selections, showing allowing you to run the Replace Geometry command. This is already usable for merging say GNIS nodes with area features. On the wiki page I've got a lot of ideas that I'd like to implement, but before proceeding any further I wanted to see what others think, both about the current design, direction, and what is most important to implement first. Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Soliciting feedback on conflation plugin
On Thu, Mar 1, 2012 at 9:00 AM, Mike N nice...@att.net wrote: On 3/1/2012 6:59 AM, Josh Doe wrote: Last night I checked in a minimally-functional (and definitely experimental) conflation plugin, appropriately called conflation. I re-downloaded the list of plugins in JOSM, but it doesn't show up there. Is the Jar file available somewhere? Yes, I mentioned this in the wiki; I think the plugin list isn't being updated during the current stabilization phase. You can download the JAR directly here: http://trac.openstreetmap.org/browser/applications/editors/josm/dist/conflation.jar -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] How external plugins are added to plugin list
I can't seem to find how the plugin list [0] is generated, specifically how external plugins are added to this list. Presumably there is some script which generates that file, which I can't find. I'd like to move my work-in-progress conflation plugin out of SVN and onto Github, but don't understand how I would add it to the plugin list. Currently I see four such external plugins. -Josh [0]: http://josm.openstreetmap.de/plugin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Creating a user-friendly changelog for tested release
On Tue, Feb 7, 2012 at 8:23 AM, Simon Legner simon.leg...@gmail.com wrote: Hi, On 30/01/12 15:07, Josh Doe wrote: I would suggest that we create a single set of changes between each tested release, separating the changes by major/minor enhancements, and major bugs (leaving minor bugs to be found via tickets). I believe this would be more helpful for users rather than seeing a long list of major changes (but missing some minor ones), without any visual demarcation telling them what has changed from the version they're using to the last tested. I like this idea as it provides more insight to JOSM development for casual users. Furthermore, I always like to read a list of new features of any product. For this reason, I've created a wiki page: http://josm.openstreetmap.de/wiki/Changelog For the most recent stable release, I went through the commit messages and put together a list of (in my opinion) interesting changes. Note that the classification is subjective, and feel free to add/remove/move any item. I've created a similar page for plugins, as their changes have very little visibility aside from the massive (in scope) OSM SVN log: http://josm.openstreetmap.de/wiki/Plugin%20changelog I organized by month since there's (currently) no concept of tested released for plugins; if there are better ideas please let us know. Help to expand this is greatly appreciated. -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Changing package of utilsplugin2 troublesome?
I'd like to use some functionality of utilsplugin2 in a plugin I'm writing, but would like to put it in a more proper package than just utilsplugin2, like org.openstreetmap.josm.plugins.utilsplugin2. Will this cause any problems? While I'm at it maybe I should change dumbutils to something else... -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Changing package of utilsplugin2 troublesome?
On Thu, Feb 9, 2012 at 9:55 PM, Josh Doe j...@joshdoe.com wrote: I'd like to use some functionality of utilsplugin2 in a plugin I'm writing, but would like to put it in a more proper package than just utilsplugin2, like org.openstreetmap.josm.plugins.utilsplugin2. Will this cause any problems? While I'm at it maybe I should change dumbutils to something else... Hmm, it seems like it is nearly impossible since the Plugin-Class is a constant (in site-josm.openstreetmap.de-_plugin.txt) across plugin revisions. At least for UtilsPlugin2.java, seems I can safely move all the other files into org.openstreetmap.josm.plugins.utilsplugin2. -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Creating a user-friendly changelog for tested release
I think it would be useful to create a more user-friendly changelog for the -tested releases, something which lies between the contents of the StartupPage and the SVN log. As we seem to be focused on creating a better experience for new users (e.g. creating expert mode), I think we need to take the same approach to the changelog. I would suggest that we create a single set of changes between each tested release, separating the changes by major/minor enhancements, and major bugs (leaving minor bugs to be found via tickets). I believe this would be more helpful for users rather than seeing a long list of major changes (but missing some minor ones), without any visual demarcation telling them what has changed from the version they're using to the last tested. Has this been discussed or thought about before? I know it would take some thought to avoid duplication of text (especially translated strings). -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Selecting ends of nodes (for finding dead-ends)
I would create a ticket for this, but I feel like since it is so basic I must be missing something. Is there any way to select the ends of a non-closed way? If this capability doesn't exist, this would be a trivial addition to utilsplugin2. Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Guidelines for increasing Plugin-Mainversion
Are there any guidelines for increasing Plugin-Mainversion, such as waiting for the required version to be satisfied by josm-tested? Or just upgrade at will (assuming it's required of course)? I'm thinking specifically in regards to adding the inside/intersecting/etc search keywords in utilsplugin2: http://josm.openstreetmap.de/ticket/5905 -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] tab not working any more?
On Thu, Jan 12, 2012 at 10:22 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote: In the latest version the TAB-key doesn't seem to work any more (at least not to change the column/row) on my system (ubuntu 11.04, sun java). Am I the only one or is this due to some recent updates? No, it's not just you. I had the problem where TAB would only work intermittently in the add property dialog. It seems to have been fixed today, though I haven't tested it: http://josm.openstreetmap.de/ticket/7250 -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Created a plugin, want to distribute it.
On Mon, Jan 9, 2012 at 11:47 AM, Morten Olsen Lysgaard mor...@lysgaard.no wrote: On 01/08/2012 03:04 PM, Josh Doe wrote: I think this would fit in with utilsplugin2. Make a patch and attachit to a ticket. Josh I've made a ticket: http://josm.openstreetmap.de/ticket/7237 It includes a patch and a icon for the tool. Do I have to poke anybody for it to be noticed/included? No, you don't have to do that. The core maintainers are notified of all ticket activity, and they are on this list, so they've seen this thread. Give it a week or two for one of them to comment on it or accept it (unlikely, as they usually provide feedback first). Thanks for contributing this, I'll try and take a look at it myself sometime soon. -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Created a plugin, want to distribute it.
On Jan 8, 2012 8:31 AM, Morten Olsen Lysgaard mor...@lysgaard.no wrote: Hi guys. I've created a plugin that lets you create geometry based on lat lon coordinates. It's like a beefed up version of the Add Node tool. It takes a list of coordinates in text form, and then created a set of nodes, a way or a closed way depending on what you want. Right now it can only add new geometry, but i plan to let it change existing geometry by letting you select a feature first and then using the tool. The reason i made this is that I need it for my aviation project where airspaces often are defined by coordinates. I figured the tool also could be good for OpenStreetMap, there probably are things other than airspaces that are defined by coordinates. I'd like to have this plugin in the JOSM SVN. What is required of me/it to get that? I think this would fit in with utilsplugin2. Make a patch and attach it to a ticket. Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Allow plugins to register search operators
On Tue, Dec 27, 2011 at 8:39 AM, Josh Doe j...@joshdoe.com wrote: I'd like to work on this functionality this week, any comments? http://josm.openstreetmap.de/ticket/7178 FYI, I've added patches which (roughly) implements this, and adds an insideselection keyword via utilsplugin2 to provide for finding objects inside an area (closed way or multipolygon). -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Allow plugins to register search operators
On Tue, Dec 27, 2011 at 8:59 AM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Tue, 27 Dec 2011, Josh Doe wrote: I'd like to work on this functionality this week, any comments? Only one: It is very unlikely that for most installations additional searches are registered and if, then only a few. So the aim should be to have the internal searches be as fast as possible and not to reduce performance too much due to large overhead. I think at least for filters the compile speed may be relevant. I've got some trivial search plugins working now, by extending Match with PluginMatch (which has abstract getKeyword() and getDescription()), and only checking for these plugin search operators after the core operators, so there should be no impact on compile speed unless you're using plugin provided operators. I'm most interested in creating an inside or within search operator using the functionality from utilsplugin2. I refactored the relevant bits in SelectAllInsideAction and moved it to NodeWayUtils, but I don't think I can directly use Match for this. For example, I would like to be able to search for all buildings within school boundaries, so I would imagine using this search string: building=* inside amenity=school (knowing full well that not all schools are tagged this way). However a simple boolean match doesn't work for this. Instead I would need a function which returns a CollectionOsmPrimitive for a given OsmPrimitive. Any idea how I could make this work? Perhaps allow something like inside(amenity=school)? I think I'd need to understand the search compiler much better to tackle this by myself. Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Print plugin now with preview
I've never tried the plugin before, but it takes quite a while until the dialog comes up, not sure if this is new or old behaviour though. The preview looks good though, thanks! On Sat, Dec 17, 2011 at 4:53 AM, Kai Pastor dg...@darc.de wrote: Hello, the print plugin now has its own dialog with page preview. Kai Pastor. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Tag transformer (unabbreviator) plugin for JOSM
It's bugged me a while in JOSM how I can't automatically unabbreviate street names, yet the validator bugs me (rightfully so) all the time. So I thought of writing a plugin for JOSM which does so, but realized it could easily be more general purpose. I've done a quick GUI mockup of what it might look like, and wrote some notes on use cases and implementation on the wiki: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/TextTransform I'd appreciate any input on the concept. Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM donations?
On Tue, Aug 2, 2011 at 1:44 PM, Dirk Stöcker openstreet...@dstoecker.dewrote: Sometimes I'm very discouraged to care for JOSM and I'm not sure if it is really worth the effort anymore. Each and every time something new is introduced or something is changed you get unacceptable comments and flames. Sometimes this can get too much even for me. Unfortunately this always happens, especially with popular software. Let me just say that I am very thankful for the effort you (and others) put into JOSM, as it is a very well designed piece of software that has made mapping OSM so much easier and better. Thank you for your hard work! -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] misleading infotext on startup for parallel way mode
Since parallel-ways mode is in core, perhaps we should change the shortcut for the pdf-import plugin to something else. Of course, I wonder why a core feature shortcut gets changed to something arbitrary (like Alt+Shift+P or H), and not the plugin. Perhaps because we had the plugin installed first before the core feature was added, and so it was saved in preferences? -Josh On Fri, Jun 17, 2011 at 11:48 AM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: 2011/6/17 André Riedel riedel.an...@gmail.com: Do you use some plugins with the shortcut shift+p ? Because it is the default setting. Yes, I have the pdf-import-plugin installed as well, sorry for the noise. cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Extending JOSM conflict facilities to support different primitive types
Hi Karl, As part of my conflation plugin work, I was thinking about extending the core JOSM code to support resolving conflicts between different primitive types, rather than rolling everything on my own. I know this kind of breaks with the intention of the conflict tools, which are of course to resolve conflicts between different versions of the same primitive. So the two big changes would be: 1) Allow creation of conflicts between different objects, not just different versions. This would be allowed between two different objects on the server, two objects on local, or a mix. This would essentially be a more robust form of the merge node command. 2) Allow creation of conflicts between different types of primitives, i.e. between a way and a node. Of course in this case it doesn't make sense to resolve nodes/members, but only tags. Does this make any practical or technical sense? How deep is the assumption that conflicts are always between primitives of the same type? Aside from helping with my conflation plugin, this would also allow merging of ways (possibly utilizing the utilsplugin2 replace geometry command) and relations. Thanks for any input, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Reusing conflict panels for conflation plugin
I'm back to working on a UI for performing conflation as I've mentioned on this list before. Right now I've got a series of tabs, the first allows the user to freeze/restore two selections (Mine and Theirs), the next configures the matching options, and the third presents the results. The results are the most important, and what I'm thinking about doing is having a table which shows the matched pairs, including the distance between them, and then below that table reusing the TagMerger panel. The user can select any row (matched pair) in the list, and the tags will then be shown to be merged below. Some enhancements could include a popup/context menu to allow applying the same operation to a selection of pairs, with options like My Tags, My Geometry, My Tags, Their Geometry, Their Tags, My Geometry, and Their Tags, Their Geometry. Is reusing the TagMerger panel good practice? I think the only thing I don't like is the local dataset/server dataset labels, but if that's the only issue it's not worth maintaining a nearly identical copy. Two reasons why I don't want to use the existing conflict dialogs is because sometimes I'll be merging disparate primitive types (e.g. a node with a way), and also the current system is not suitable for rapidly moving through hundreds of conflicts. Any suggestions are appreciated. Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to present results of my conflation analysis
I've expanded the wiki page on this and added some screenshots. http://wiki.openstreetmap.org/wiki/Conflation/Nodes#JOSM_Implementation Suggestions and/or code are appreciated. -Josh On Tue, May 3, 2011 at 8:44 PM, Josh Doe j...@joshdoe.com wrote: For anyone interested I've committed what I've done so far to the repository: http://trac.openstreetmap.org/browser/applications/editors/josm/plugins/conflation It's far from a usable plugin, but in case I don't get back to it someone else might find it useful. Right now all it does is find matching pairs of nodes/ways/relations based on distance (using center of OsmPrimitive.getBBox()), then creates conflicts for them, and draws arrows between them. Like I said far from a usable plugin, more of a proof of concept. -Josh On Thu, Apr 28, 2011 at 11:24 PM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Thu, 28 Apr 2011, Josh Doe wrote: Any ideas would be much appreciated! A long term plan is to use the mapview also to view subsets of the map. So we could have e.g. a dialog with two small sections, each showing a partial map. One map shows the old state, one map the new state. This would improve conflict resolution a lot and probably also be the solution for your tasks. If you would like to implement this ... Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to present results of my conflation analysis
For anyone interested I've committed what I've done so far to the repository: http://trac.openstreetmap.org/browser/applications/editors/josm/plugins/conflation It's far from a usable plugin, but in case I don't get back to it someone else might find it useful. Right now all it does is find matching pairs of nodes/ways/relations based on distance (using center of OsmPrimitive.getBBox()), then creates conflicts for them, and draws arrows between them. Like I said far from a usable plugin, more of a proof of concept. -Josh On Thu, Apr 28, 2011 at 11:24 PM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Thu, 28 Apr 2011, Josh Doe wrote: Any ideas would be much appreciated! A long term plan is to use the mapview also to view subsets of the map. So we could have e.g. a dialog with two small sections, each showing a partial map. One map shows the old state, one map the new state. This would improve conflict resolution a lot and probably also be the solution for your tasks. If you would like to implement this ... Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] How to present results of my conflation analysis
I've implemented the algorithmic part of a conflation tool in a JOSM plugin, pretty much following what I wrote down here: http://wiki.openstreetmap.org/wiki/Conflation/Nodes Right now I'm just using the Euclidean distance in the cost function, but we can of course add other costs like dissimilarity between key values. My big question now is how to present the results to the user, and to allow them to manually confirm/reject matches. All I've done so far is to create a new layer which draws arrows connecting the matched nodes/ways. However that's only a useful visualization tool but doesn't manage the actual conflation process. You can see the option dialog and arrow layer here: http://tinypic.com/r/23sw0u8/7 http://tinypic.com/r/jhd3j7/7 The first question is whether this tool should only merge data from one layer to another, or if it should allow syncing (i.e. bidirectional merging) between layers. The former is of course easier, and can possibly take advantage of existing functionality in JOSM, namely the conflict resolution tools. In fact I've added conflicts which appear in the conflict dialog when the Conflation layer is selected. Some things that are missing with that approach is to highlight the arrow connecting the matched nodes, and being able to select the arrow to conflate/resolve the pair of primitives. Also this conflation approach is slightly different from conflict resolution since I'm mostly concerned about resolving tags, and possibly center locations. Right now the conflict tools only support resolving conflicts between like primitives, i.e. Node-Node, however I need to allow any combination of Node, Way, or Relation. In other words I may want to match a GNIS feature node (from a fresh GNIS data set) to an existing feature in OSM that may be a node, area, or multipolygon. I'm not so much concerned about the geometry but rather the tags. Conflating geometry is much more complicated and is a future project. :) Any ideas would be much appreciated! -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Designing a node conflation tool (syncing data)
There's been a lot of talk about tools for merging/syncing/conflating data with OSM, so I thought it would be useful for us to discuss possible user interface designs for doing so. Because I'm somewhat familiar with JOSM, and nodes should be the easiest case (though not trivial), I've written up a short potential workflow for conflating nodes in JOSM. If we can't handle nodes then we'll have no hope for the much more challenging case of ways and relations! http://wiki.openstreetmap.org/wiki/Conflation/Nodes I've never used a conflation tool before, so this might be an obvious approach to some, or perhaps an awful way to do it, but regardless I wanted to get it written down where others could improve upon it. I'd like to keep this focused on discussing the design of a user interface and workflow, as well as the technical details. -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] projection Mercator, set EPSG 3785 instead of EPSG 3857
I'm not entirely sure what you mean. Per the OSM wiki, all coordinates are in WGS 84, which certainly employs an ellipsoid. Data users and providers are responsible for transforming between WGS84 and whatever coordinate system they are using. Thankfully WGS84 is the most commonly used system. If I make a trace with my GPS, and it uses WGS84 (which most if not all do), and I then upload it to OSM, all is well. So far there has been no need to transform coordinates, or even know a single thing about spheres, ellipsoids, or anything else. Once I pull that trace into JOSM (or any tool), I need to map those coordinates to the screen. One of the simplest ways is to use the Mercator projection EPSG:3857, which transforms the ellipsoidal WGS84 to a square. Note however that when transforming to the square it is not using an ellipsoid, but rather treating the coordinates as if they were on a sphere. Really it doesn't matter what transformation you do, you could even make up your own. The important thing is that before pushing changes back to OSM you perform the inverse transformation, and of course if you're using other data or imagery you need to make sure you are using the same coordinate system. And as far as OSM putting both datums on the same level, I have to disagree. OSM itself explicitly says all coordinates are in WGS84. There may be certain applications which mix things up, but that's not the fault of OSM. Trust me, I know this is confusing, and if I'm saying something wrong please correct me! -Josh On Tue, Mar 8, 2011 at 8:29 AM, Tobias Wendorff tobias.wendo...@tu-dortmund.de wrote: Am 08.03.2011 13:39, schrieb Josh Doe: Thus the inverse flattening that Martin mentions refers to the WGS 84 datum, not the EPSG:3857 projection from that datum. Yeah, but change in this datum has big outcome on the projection. The formular used is much more complex now. On a sphere, you can use Pi and spherical geometry to calculate the x/y-coordinates. On a ellipsoid, you need expensive expansion in series. Right now, OSM puts both datums on the same level, which is wrong in geodetic use, but the error is okay for non critical applications (1/298,257223563 = 0,0033528106 unity). ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] projection Mercator, set EPSG 3785 instead of EPSG 3857
I know it's difficult to work across language barriers! Okay, first of all the proj.4 parameters you gave aren't entirely correct. If you look in the epsg file from proj.4 that I linked to in my earlier message, you'll see that the parameters you claim for EPSG:3785 (sphere) are in fact what proj.4 uses for both EPSG:3785 and EPSG:3857. That's not entirely correct either. If you look at the EPSG definition for 3785 that Martin linked to earlier, you'll see that the _datum_ is spherical. The proj.4 parameter +nadgrids=@null (as I linked to earlier) forces proj.4 to NOT convert between the WGS84 (ellipsoidal) and spherical datums. This is all moot since EPSG:3785 is invalid and should never be spoken of again. :) Also, when you talk about using the inverse transform, you're incorrectly using a different set of coordinate systems to transform between. An application must ensure it is using the correct pair of transforms to ensure no errors are introduced. You're trying to transform with [1], then back with [3], while you should be going back with [4]. Transform [3] should be paired with [2]. Remember, the coordinates in OSM use WGS84, which is ellipsoidal. If you really wanted to transform to the (invalid) EPSG:3785, you would _first_ need to transform from the ellipsoidal datum of WGS84 to the spherical datum used by EPSG:3785, then project those coordinates using the Mercator projection. Hopefully this clarifies the matter, though it is certainly difficult to understand, and I don't claim 100% understanding. Regards, -Josh [1] cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +a=6378137 \ +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m \ +nadgrids=@null +no_defs [2] cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +datum=WGS84 \ +units=m +nadgrids=@null +no_defs [3] cs2cs +proj=merc +datum=WGS84 +units=m +nadgrids=@null +no_defs \ +to +proj=latlong +datum=WGS84 -f %.6f [4]: cs2cs +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 \ +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs +to +proj=latlong +datum=WGS84 On Tue, Mar 8, 2011 at 9:51 AM, Tobias Wendorff tobias.wendo...@tu-dortmund.de wrote: Am 08.03.2011 14:53, schrieb Josh Doe: And as far as OSM putting both datums on the same level, I have to disagree. OSM itself explicitly says all coordinates are in WGS84. There may be certain applications which mix things up, but that's not the fault of OSM. Let me explain it in numbers, perhaps my English is too bad: WGS84 coordinates (LAT,LON): 51.0, 7.0 [1] projection to EPSG:3785 (x,y): 5677294.03, 781182.21 (sphere) [2] projection to EPSG:3857 (x,y): 5677294.03, 775978.50 (ellipsoid) When a software uses the spherical formular of mercator, the coordinates will be drawn at 5677294.03, 781182.21. If the inverse mercator formular is also the spherical one, more errors will be added... x/y-coords to geographical ones: [3] 5677294.03, 781182.21 = 51.00, 7.046703 Used parameters on cs2cs: [1] cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +a=6378137 \ +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m \ +nadgrids=@null +no_defs [2] cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +datum=WGS84 \ +units=m +nadgrids=@null +no_defs [3] cs2cs +proj=merc +datum=WGS84 +units=m +nadgrids=@null +no_defs \ +to +proj=latlong +datum=WGS84 -f %.6f ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Proj4J - New plugin supporting 3000+ projections
This plugin is now in SVN, and I have published the JAR so if you're interested you should be able to install from within JOSM. Be sure to test it before assuming it is correct! I tested it with several projections that I'm interested in, and they all seemed to work fine, but this plugin certainly has some issues. Please let me know if you find any bugs either via Trac or email. Frederik pointed out a number of potential issues when using arbitrary projections, which apply not only to projections supported by this plugin but any projection really. If you come across any issues or bugs please let me know! -Josh On Fri, Feb 25, 2011 at 4:09 AM, Frederik Ramm frede...@remote.org wrote: Hi, On 02/25/2011 05:10 AM, Josh Doe wrote: Perhaps my sensationalist subject line turned people off from this. Any chance this could get added to the svn? I'd like to submit patches against that rather than continually updating the zip on the ticket. I'd do so myself, but I don't want to be presumptuous and ask for an svn account. Go ahead and request an OSM SVN account, it's nothing presumptuous. I see some trouble coming up when this plugin interacts with other stuff, like the tile/WMS backgrounds and the ImportImage or PDF plugins. These problems already exist - your plugin doesn't create them; it's just that your plugin opens the door to people using all kinds of strange projections and believing that was supported. Problems I suspect may arise: * Selecting a projection that is only valid for a small part of the world (indeed, most of the 3000+ will not work for the whole planet) and then zooming out - what will happen? Do you actually include the validity bounding boxes for each and switch back to plain Mercator outside of that area? * Imagery subsystem (tile/WMS) is likely to, at best, squish or stretch images, but will not properly reproject them, which will lead to noticeable inaccuracies especially on low to medium zoomlevels. The kind of inaccuracy depends on the projection chosen. For example, if you set JOSM ot 4326 then request tiles from a Mercator tile server, the middle section of each tile will be displaced towards the equator. This effect is probably more pronounced with other source/destination combinations. * ImportImage plugin contains its own projection library which (a) may be partly unnecessary if your plugin is loaded - maybe ImportImage could be made to depend on yours? - and (b) it tries to reproject loaded images to the display projection, one should try if this really works with the usual projections. * Gauss-Krueger proejctions commonly used in Germany are not processed by proj.4 accurately unless an extra grid file (BETA2007.gsb) is used, see http://osgeo-org.1803224.n2.nabble.com/gdal-dev-Re-ogr2ogr-BeTA2007-grid-td4900463.html - will that be possible with your plugin? * I have no clue what the PDF import plugin does if your viewport is projected. I assume that there's a whole host of plugins assuming that you can just scale an image to the viewport and it will somehow magically work. Don't let these points discourage you from continuing your work, it is most appreciated. I would just advise some caution when saying that certain projections are now supported as this will naturally lead users to believe that everything still works if they select that projection - which may not always be the case :) Bye Frederik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] where are the slippy-map settings to switch bingimagery ON
Change wms:bing:bing to bing:bing. Yes, JOSM internally translates bing:bing into http URLS when it requests tiles. On Mon, Mar 7, 2011 at 2:36 PM, ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl wrote: I have seen a lot of silly URL, but this one is the worst bing:bing Are you sure we are talking about the same subject ? Are we both talking about JOSM ? Not about the Eurovision songfestival There is no update button on the WMS-TMS preference screen, there is a refresh-button, but it does nothing. Apart from a approx 20 listed server URL (yes, real url's beginning with http) there is nothing starting with a B. Manually adding url bing:bing creates only red error tiles (I was not surprised !!!) and lists in the preferences screen as wms:bing:bing Just for the records: JOSM version 3961 Of this version all functions work, including editing download and upload of modified data Gert -Oorspronkelijk bericht- Van: Matthias Julius [mailto:li...@julius-net.net] Verzonden: zondag 6 maart 2011 20:47 Aan: josm-dev@openstreetmap.org Onderwerp: Re: [josm-dev] where are the slippy-map settings to switch bingimagery ON ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl writes: This seems not to be so obvious and the help is not very helpful here I read both have been combined (WMS / slippy) in one josm core integrated imagery menu, and indeed I have that, But it contains only a list of the servers I used in at the time of the Haiti project as well as a few others such as Yahoo. No BING url ? If I have to enter it myself, I would be happy to know which one In the preferences there is a tab for the imagery settings (WMS TMS). There at the top is a list of available imagery providers. Do you have Bing in there? If not you can try the update button next to the list. If you have Bing in the list you can select it and hit the Activate button below and hopefully that will make Bing available from the Imagery menu. Anyway, the URL for Bing is bing:bing. Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Unable to checkout all JOSM plugins (fails on smed)
I'm trying to checkout the all JOSM plugins, but it keeps failing in the smed directory: Error: In directory 'C:\devel\josm\plugins\smed\plugs\oseam\src\images' Error: Can't open file Error: 'C:\devel\josm\plugins\smed\plugs\oseam\src\images\.svn\tmp\text-base\tower.png.svn-base': Error: The system cannot find the file specified. Someone mentioned this on the Help OSM site [1], but no satisfactory answer was given. Any ideas why? I of course can get around this (unless I want to use smed, which I don't), but it's annoying and seems like something's corrupt. Thanks, -Josh [1]: http://help.openstreetmap.org/questions/2778/svn-download-fails ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] projection Mercator, set EPSG 3785 instead of EPSG 3857
Hmm, but EPSG:3785 is deprecated, or as EPSG says, NOT VALID. EPSG:3857 is equivalent to EPSG:3785, it's just a different formulation. Here's the change request from EPSG's site (notice the Actions Take section): Code: EPSG::2008.114 Reporter: OGP Request: Revisit spherical mercator used for some web mapping applications Actions Taken: Deprecated ellipsoid 7059, datum 6055, method 9841, projection 19847, CRSs 4055 and 3785, tfm 15973. Added methods 1024 and 1026, proj 3856 and projCRS 3857. Entity Types Affected: Ellipsoid; Datum; Coordinate Operation Method; Coordinate Operation; Coordinate Reference System Codes Affected: 7059; 6055; 9841; 15973 19847; 4055 3785 Report Date (UTC): 2008-12-11 Closed Date (UTC): 2009-02-10 -Josh On Fri, Feb 25, 2011 at 12:05 PM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: M?rtin Koppenhoefer wrote: JOSM currently does not permit to set the Google / Bing / standard Mapnik projection if I interpret this right (there is Mercator which is EPSG 3857 according to JOSM). Wouldn't it be better to set EPSG 3785 (aka 900913) as Mercator? EPSG:3857 is the correct number of this projection. 3785 is deprecated. See http://viswaug.wordpress.com/2009/04/01/gis-standards-gone-crazy-epsg-especially/ All, including 900913, mean the same. I am still not convinced: http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3857reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3857 http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3785reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3785 interesting remarks:Used only for Web approximate mapping and visualisation. Not recognised by geodetic authorities. ;-) I feel that EPSG 3785 for our Web approximate mapping fits perfectly. cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Proj4J - New plugin supporting 3000+ projections
Perhaps my sensationalist subject line turned people off from this. Any chance this could get added to the svn? I'd like to submit patches against that rather than continually updating the zip on the ticket. I'd do so myself, but I don't want to be presumptuous and ask for an svn account. Regards, -Josh On Wed, Feb 16, 2011 at 8:32 PM, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote: Am Mi, 16.02.2011, 16:21 schrieb Josh Doe: I've gotten my plugin based on the Proj4J in a working state, or at least working for me. Some information is on the OSM wiki [1] and codes/JAR can be obtained from the trac site [2]. Gosh, good work! I'll try tomorrow. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Problems creating TileSource for ArcGIS REST API
From that URL it appears your coordinates are already in ESRI:102113 (aka true EPSG:3857). If I convert my coordinates to 102113, and use your URL, I get a blank image. If I drop imageSR=102113 from the URL, I get an image but have the same problem of slight (5 meter or so) misalignment between tiles. I've looked at the actual response from the server (HTML or JSON output) and it appears the requested tile corners aren't matching up between adjacent tiles. Take these two tiles [1] [2]. From these URLs the corners clearly match up, but the response from the server gives different extents. This seems to be the problem, but I don't know the resolution. Thanks for your help, I may give up on this shortly and go for the better but harder goal of using the ArcGIS REST tile cache. Not sure how wise it is to start something harder before figuring out the easier part however. :) If anyone has ideas or I get inspiration I will try to get it working! Thanks, -Josh [1]: http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer/export?f=htmlformat=jpgbbox=-8605127.770289,4691551.922088,-8604974.896232,4691399.048031imageSR=bboxSR=102113size=256,256 [2]: http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer/export?f=htmlformat=jpgbbox=-8605127.770289,4691399.048031,-8604974.896232,4691246.173974imageSR=bboxSR=102113size=256,256 On Thu, Feb 17, 2011 at 3:46 PM, Ian Dees ian.d...@gmail.com wrote: I don't have any more time to look at this right now, but this is the URL I use in my tile cache for this layer (I used it to map some of Virginia myself a while back): http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer/export?f=imageformat=jpgbbox=$xmin,$ymin,$xmax,$ymaximageSR=102113bboxSR=102113size=$width,$heightlayers=show:0 On Thu, Feb 17, 2011 at 2:39 PM, Josh Doe j...@joshdoe.com wrote: Ian, Thanks for the fast response. I believe I tried that, but to make sure I tried it again, and it doesn't work. For some reason with imageSR=102113 I get a blank (white) image. For fun I also tried the equivalent imageSR=102100 with no luck. You can see the request is blank here [1], while clearing imageSR results in an image, though not of the right projection. To be honest I don't really understand how the imageSR relates to the bbox and bboxSR. Is it possible this instance of the ArcGIS server can't reproject the image to this SR? I'm outside of my knowledge area if you haven't guessed already. :) Thanks, Josh [1]: http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer/export?bbox=-77.310791,38.794768,-77.308044,38.792627size=256,256bboxSR=4326imageSR=102113format=jpgf=html [2]: http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer/export?bbox=-77.310791%2C38.794768%2C-77.308044%2C38.792627bboxSR=4326layers=layerdefs=size=256%2C256imageSR=format=jpgtransparent=falsedpi=f=html On Thu, Feb 17, 2011 at 3:16 PM, Ian Dees ian.d...@gmail.com wrote: Use bboxSR=4326 (to specify the bounding box in 4326) and imageSR=102113 to get the image back projected to Spherical Mercator. The imageSR parameter may be called something else, but I do know that an output projection option exists somewhere. On Thu, Feb 17, 2011 at 2:09 PM, Josh Doe j...@joshdoe.com wrote: Ian, I've tried various combinations of spatial references and haven't quite got it working. I use the tileYToLat/tileXToLon functions which give me decimal degrees in WGS84 (EPSG:4326), so I can't use bboxSR=102113 without converting those coordinates. With the Proj4J plugin I used EPSG:3857 (equivalent to ESRI:102113 and ESRI:102100), and that eliminates the gaps but now there are slight shifts between each tile, so clearly something is still awry. I thought setting imageSR=102113 would fix the slight shifts, but then I don't get any image returned. Tobias, I've found it very confusing to understand what spherical mercator is and the various codes involved, so much so that I created a wiki page on EPSG:3857 [1]. All, One thing that bothers me in JOSM is the Mercator projection claims to be EPSG:3857, however it gives values in radians, not meters which EPSG:3857 uses. I'm not even sure what EPSG/ESRI/etc identifier corresponds to to this, but I think we should change it to avoid confusion (took me a while to realize it was wrong). Shouldn't we change this code to avoid confusion and to be right? I'm guessing people use the projection, so we shouldn't fix it but rather give it the correct code if we can find it or invent one, probably via SpatialReference.org. Thanks, -Josh [1]: http://wiki.openstreetmap.org/wiki/EPSG:3857 On Thu, Feb 17, 2011 at 12:35 PM, Tobias Wendorff tobias.wendo...@tu-dortmund.de wrote: Am 17.02.2011 17:15, schrieb Ian Dees: Don't reproject your coordinates to Virginia, just tell ArcGIS that your request bounding box is in Spherical
[josm-dev] Proj4J - New plugin supporting 3000+ projections
I've gotten my plugin based on the Proj4J in a working state, or at least working for me. Some information is on the OSM wiki [1] and codes/JAR can be obtained from the trac site [2]. Please test this out and report any issues. My main interest was using EPSG:2924 with the pdfimport plugin, so I've also created a patch for that plugin to show the preference panel of any projection, not just Proj4J. You can view the ticket at [3]. Thanks, -Josh [1]: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Proj4J [2]: http://josm.openstreetmap.de/ticket/5935 [3]: http://josm.openstreetmap.de/ticket/5936 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How do I add a new projection, EPSG:2924?
Just wanted to say thank you, and that I've got it working. I decided to use the OSGeo Proj4J library [1] since it has support for datum transformations and has a huge database of EPSG data. I loaded up the county property map using pdfimport and everything lined up to within less than a meter (from data I added via GPS and Bing aerial). It would be trivial to add all projections supported by Proj4J to JOSM, all that is required is to change the EPSG code. I'm not sure how to implement this as a plugin, though I do see projections can have a preference panel so perhaps the EPSG code could be set there, but I'm not sure if that will work. -Josh On Tue, Feb 8, 2011 at 1:58 PM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Tue, 8 Feb 2011, Josh Doe wrote: I believe I understand how to add it now, though I can't do so as a plugin because it then would not be available to the pdfimport plugin. Sure it would. Why not? However a bigger problem I have is that there appears to be a difference in datums between what JOSM uses (WGS 84) and what EPSG:2924 uses (NAD83). I'll have to first figure out how to convert between those. When you don't need external libraries a patch for core is fine. Otherwise you need to make a plugin. To make it simpler I added the addProjections() function myself in r3872. I don't understand what is so complicated about this function that 3 people failed to do it, one of them the original maintainer. :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] How do I add a new projection, EPSG:2924?
Hello, I've gotten access to and permission to use a large set of maps in PDF form for Virginia, USA, and I'd like to use the pdfimport plugin with JOSM to help with importing the data. The projection is EPSG:2924 [1], Virginia State Plane North/NAD83(HARN). What's the best way to add this new projection? I believe I can't add it as a plugin, like (epsg31287 [2]), because it won't be available to the pdfimport plugin. However, since that plugin uses the jhlabs Java Map Projection Library, which does support the Virginia State Plane EPSG:2924, and it appears to be capable of being integrated with JOSM through a custom build, I can just copy that code, modify it, and build my own version of JOSM. Any advice would be appreciated, thanks! -Josh [1]: http://spatialreference.org/ref/epsg/2924/ [2]: http://svn.openstreetmap.org/applications/editors/josm/plugins/epsg31287 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How do I add a new projection, EPSG:2924?
Hi Dirk, I believe I understand how to add it now, though I can't do so as a plugin because it then would not be available to the pdfimport plugin. However a bigger problem I have is that there appears to be a difference in datums between what JOSM uses (WGS 84) and what EPSG:2924 uses (NAD83). I'll have to first figure out how to convert between those. Thanks, -Josh On Tue, Feb 8, 2011 at 10:04 AM, Dirk Stöcker openstreet...@dstoecker.de wrote: On Tue, 8 Feb 2011, Josh Doe wrote: What's the best way to add this new projection? I believe I can't add it as a plugin, like (epsg31287 [2]), because it won't be available to the pdfimport plugin. However, since that plugin uses the jhlabs Java Map Projection Library, which does support the Virginia State Plane EPSG:2924, and it appears to be capable of being integrated with JOSM through a custom build, I can just copy that code, modify it, and build my own version of JOSM. Well, you're the third one asking: - Add it as plugin - Add the proper interface into josm - namely a addProjection() function in the right place (like e.g. Main) - and send a patch for this. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] ArcGIS REST or SOAP support
Hello, I've found that Virginia, USA offers their off-leaf orthophotos from 2002, 2006/2007 and soon 2009 in the public domain [1], but it is only accessible via an ArcGIS server that only offers ArcGIS REST and ArcGIS SOAP interfaces. For my area this imagery is better than Bing and Yahoo combined, since it has the high resolution of Bing, it's off-leaf like Yahoo, plus it's public domain. Problem is I can't use it in JOSM, or any other editor that I know of. From my naive point of view, ArcGIS REST and WMS look very similar. I've tried to find a REST/WMS adapter but haven't had any luck. Anyone know if an adapter exists, or how difficult it would be to adapt the JOSM WMS code to support REST? The specification is publicly available [2]. Thanks, -Josh [1]: http://wiki.openstreetmap.org/wiki/Virginia#Resources [2]: http://resources.esri.com/help/9.3/arcgisserver/apis/rest/ ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] ArcGIS REST or SOAP support
That would be fantastic! There's a number of data layers available on the server, but the REST URL for the latest aerial imagery is located here: http://gismaps.virginia.gov/arcgis2/rest/services/VBMP2006_2007/MapServer Thanks, -Josh On Fri, Jan 28, 2011 at 9:26 AM, Ian Dees ian.d...@gmail.com wrote: I'd be happy to write an extension to the imagery code to allow this. In the mean time, I can set up a tile cache for you to use with your data if you give me the URL for the ArcGIS REST page. On Fri, Jan 28, 2011 at 8:03 AM, Josh Doe j...@joshdoe.com wrote: Hello, I've found that Virginia, USA offers their off-leaf orthophotos from 2002, 2006/2007 and soon 2009 in the public domain [1], but it is only accessible via an ArcGIS server that only offers ArcGIS REST and ArcGIS SOAP interfaces. For my area this imagery is better than Bing and Yahoo combined, since it has the high resolution of Bing, it's off-leaf like Yahoo, plus it's public domain. Problem is I can't use it in JOSM, or any other editor that I know of. From my naive point of view, ArcGIS REST and WMS look very similar. I've tried to find a REST/WMS adapter but haven't had any luck. Anyone know if an adapter exists, or how difficult it would be to adapt the JOSM WMS code to support REST? The specification is publicly available [2]. Thanks, -Josh [1]: http://wiki.openstreetmap.org/wiki/Virginia#Resources [2]: http://resources.esri.com/help/9.3/arcgisserver/apis/rest/ ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
