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: [OSM-dev] Porting the mapnik stylesheet to carto
On Fri, Nov 16, 2012 at 11:50 AM, Andy Allan gravityst...@gmail.com wrote: [...] Yesterday I decided that rather than emailing the list, I would dive in and see how much work it would be to convert them to carto, and whether it's feasible https://github.com/gravitystorm/openstreetmap-carto Fantastic, thank you! I'll have to get my new laptop setup with TileMill to check this out. Random fun idea for anyone who has copious amounts of spare time: Create a web service that renders any given commit to allow for easy visual comparison of changes, or even static renders of a few showcase tiles with a nice A/B comparison page. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hello World
On Thu, Oct 18, 2012 at 4:41 PM, Alex Barth a...@mapbox.com wrote: On Oct 12, 2012, at 1:14 PM, Michal Migurski m...@teczno.com wrote: * Create a new map style intended to be the default face of OSM, but leave the current OSM.orgMapnik style as-is. It works beautifully as an editor's basemap due to the dense inclusion of all data. Keep it, but add a new one that's for non-editors to look at. I wonder how good the current Mapnik style is for editors. Mapping in Latin America I'm for instance noticing more and more how people tag major connecting roads `highway=track` because they're unpaved instead of using an appropriate tag such as `highway=tertiary` and specifying `surface=unpaved`. Tagging for the renderer of course: the problem is that the Mapnik style completely ignores `surface=unpaved` making a significant dirt road really not look how it should on the map. I guess it's clear that there's an issue w/ the style not being maintained right now and it's unclear how to contribute to it, but based on stuff like the unpaved road example I'm starting to think that the Mapnik style does not only need a refresh esthetics wise but it being unmaintained complicates good mapping. I think the current Mapnik style should eventually be replaced by a CartoCSS style (hosted on GitHub) that is accessible to more editors/cartographers (think TileMill). It should maintain the focus of showing everything under the sun, even if it is a bit cluttered. There's lots of great general purpose styles (MapBox Streets, Open MapQuest) and more focused ones out there, the main OSM.org style should be a showcase of the underlying data. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] OSRM has Alternative Routes
On Tue, Jul 10, 2012 at 10:36 AM, Dennis Luxen dennis.lu...@gmail.com wrote: Hello Everyone, We are very proud to announce the latest features that arrived at Open Source Routing Machine (OSRM). First and foremost, the engine does not only compute a shortest (i.e. fastest) path, but also gives an alternative path that obeys to certain quality criteria. Great work, I'm impressed (again) at the speed of this, and thank you for the global coverage! However, it seems a bit too conservative about showing alternate routes, as I was only given one alternate after trying dozens of end points. Another suggestion: I've been fastidious in adding route numbers to all roads, including residential roads, and the OSRM directions only show this route number; perhaps you could show both the route number and the name? Thanks, -josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] Urban Development Map Project
On Mon, Mar 26, 2012 at 7:53 AM, Reed Duecy-Gibbs rdue...@gmail.com wrote: [...] First, I’m interested in seeing how this project can integrate with OSM. However, any urban development that is hypothetical, still in the design phase, or under construction would probably be confusing to include in general OSM data. I’m assuming then that I need to create my own data on a separate server and use OSM as a base map. But, I want to double check this fact as it could save me a lot of trouble. (In general I would like to integrate and contribute to existing networks and knowledge bases as much as possible). [...] I think you've got it right, you'd want to setup a separate database (check out OpenAvationMap [0] and the USGS Collaborative Prototype [1]). Last year I was interested in using OSM for the Safe Routes to School (SRTS) program, where the idea was to let users copy a portion of the main OSM database around a particular school, then make edits to see how adding/removing paths and sidewalks would impact the walkability of a particular school. See a previous thread I started [2] which discussed this idea of Multiple temporary API instances. -Josh [0]: http://navigator.er.usgs.gov/ [1]: http://openaviationmap.org/ [2]: http://lists.openstreetmap.org/pipermail/dev/2011-August/023403.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] Web-devs: check your maps, Tiles@home does'nt exists anymore.
On Thursday, March 15, 2012, Toby Murray toby.mur...@gmail.com wrote: On Thu, Mar 15, 2012 at 1:46 PM, yvecai yve...@gmail.com wrote: Just to say that a lot of websites showing a map are broken due to openlayers looking for osmarenderer layer. So, check yours! A good first place to start might be our own wiki... http://wiki.openstreetmap.org/wiki/Idaho http://wiki.openstreetmap.org/wiki/Arizona http://wiki.openstreetmap.org/wiki/Arkansas http://wiki.openstreetmap.org/wiki/North_Dakota And that's just a few specific states I looked up. Is there any way to do a search for all of the wiki instances of the slippymap component that reference the osmarender layer? Sysops can use the replace string extension, or anyone can use AutoWikiBrowser. Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Maps-l] Announcement: WIWOSM project
On Wed, Mar 14, 2012 at 3:23 PM, Tim Alder tim.al...@s2002.tu-chemnitz.de wrote: Hello, next week I want to publish the next big step for the cooperation between OSM and Wikipedia: http://wiki.openstreetmap.org/wiki/WIWOSM Fantastic! Looks great so far, and I think this is the best implementation I've seen so far. I would like to see this used in place of Template:Attached KML, except when dealing with historic objects and the like. I put some quality assurance ideas on the talk page: http://wiki.openstreetmap.org/wiki/Talk:WIWOSM Maybe we could get a Greasemonkey script to enable this for any Wikipedia site? Also, is there a way to grab all coordinates for a category? I'd like to try my WIP conflation plugin for JOSM to help speedup the process of adding wikipedia tags. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] shortestpathtree.org - a tool for quickly checking OSM data integrity
On Mon, Mar 12, 2012 at 12:11 PM, Brandon Martin-Anderson badh...@gmail.com wrote: Behold! I made a thing. http://shortestpathtree.org Very cool! I'll have to generate this for my region (Washington DC). It's mesmerizing! -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Willing to apply Improve / Create Simple Android OSM editor GSOC 2012 project
On Sun, Mar 11, 2012 at 1:03 PM, Janani Nayanathara jananinayanath...@gmail.com wrote: hi, I am Janani Nayanathara from Uva Wellassa University, Sri Lanka. I am interested in Improve / Create Simple Android OSM editor project because I am interested in dealing with maps. I want to know what are the subject areas I should refer before applying in order to be familiar with OpenStreetMap. Great to hear this, I'm particularly interested in seeing an improved Android app. After first doing what Ian suggested, check out all the existing apps: http://wiki.openstreetmap.org/wiki/Android#OpenStreetMap_editing_features Personally I don't think robust editing (e.g. Vespucci) really works on Android phones (but might work on tablets), but I'd like to see a much improved OSMTracker. Namely adding vector background support (e.g. what OsmAnd has) to see what data already exists, uploading tracks directly to OSM, saving OSM.XML files for later editing in JOSM (by saving proper tags instead of just notes in a GPX file), and more. But definitely get more familiar with OSM in general first. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OGR driver for OSM data
I can only find a handful of mentions about creating an OGR driver for OSM files [0][1][2], and those are several years old. Has anyone else considered writing one? I don't think this group is terribly interested in it because we have many other robust tools for converting OSM data from and to other formats. However I think an OGR driver would lower the barrier to entry for using OSM data for those who aren't familiar with any of these other tools, and don't need the power they offer. Right now I'm only thinking about a read-only implementation. Basing the driver off of one of the existing XML-based drivers like KML or GPX. Possibly revive this as a GSoC idea? -Josh [0]: http://lists.openstreetmap.org/pipermail/talk/2007-October/019168.html [1]: http://wiki.openstreetmap.org/wiki/GSoC_Applications_2008#Openstreetmap_OGR_driver_Olga_Mardar [2]: http://osgeo-org.1560.n6.nabble.com/support-for-gpx-and-osm-formats-td3762980.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OGR driver for OSM data
On Thu, Mar 8, 2012 at 2:02 PM, Jochen Topf joc...@remote.org wrote: This idea comes up again and again. Writing a generic OGR driver for OSM data would be very difficult, because the data models just don't match. You'd have to have some kind of complex mapping between the two worlds. Thats why nobody has done it. There's certainly not a direct mapping, but I don't see why we can't handle most common cases. Point - Node Way (without area=yes or certain other tags, e.g. leisure=pitch) - LineString Way (with area=yes or certain other tags, e.g. leisure=pitch) - Polygon Relation (type=multipolygon, with one inner/outer ring) - Polygon Relation (type=multipolygon, with more than one one inner/outer ring) - MultiPolygon I don't even care about implementing writing functionality. My interest is letting non-OSM GIS users easily use OSM data, not for them to produce OSM data (those in the OSM community can use Osmium, ogr2osm, etc. for that). The most annoying part is maintaining a list of tags that generally (in the absence of area=no) indicate a way is an area. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OGR driver for OSM data
On Thu, Mar 8, 2012 at 5:10 PM, Jochen Topf joc...@remote.org wrote: The problem is not so much the geometries. Its the open tagging scheme which doesn't fit the fixed attribute names/types of the traditional GIS world. As a simple example, you might want to map oneway=yes and oneway=true and other versions to a simple boolean field. Real life examples are much more complex. OSM data basically always needs this cleanup and canonicalization and mapping step. True, that's an issue as well, but I'm thinking of the simplest mapping possible, just one to one (by default at least). Plenty of non-OSM data sources need cleaning up as well, so I don't see that as a specific issue with OSM data. Again, if someone wants more control, they can use other tools like Osmium. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Possible GSoC project: tag/area monitoring service
On Tue, Mar 6, 2012 at 2:10 PM, Michael Daines mich...@mdaines.com wrote: When you mention changes to large relations and widely dispersed objects, I was wondering if you had any specific use cases in mind? I'd also be interested in hearing what kind of expressions you might expect to be able to use. For example, I was thinking you could say something like give me updates for things with the tag highway=residential and is_in=Canada. I was thinking about very long routes, and country borders. If I want to monitor changes to my state and interstate routes within the state, I don't have any good options at the moment to do that. I don't think it should be terribly difficult to implement, I'm just not sure how well it will scale. To make it more interesting you could allow for watching all changes to objects with certain tags that are within a certain distance of a route relation, or located inside a multipolygon. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Possible GSoC project: tag/area monitoring service
On Mon, Mar 5, 2012 at 10:58 PM, Michael Daines mich...@mdaines.com wrote: Hi everyone, I'm writing to seek opinions about a possible Google Summer of Code project. I did GSoC in 2010, and I'd like to apply again this year. My project in 2010 was a simplified, web-based map editor. Since the wiki page for project ideas mentions that proposals for the development of existing OSM infrastructure would be preferred, I was having a look at the API v0.7 page, and noticed some interest in a monitoring feature. My proposal is to build a monitoring service to augment the existing API, similar to the Twitter streaming API [1]. Users would request to receive map updates matching tags or which involve elements in some area, and updates would be sent either over a persistent connection (as Twitter does) or possibly by making requests to an endpoint specified by the user. My general idea for the architecture is basically to grab diffs and then send the relevant parts to clients depending on what they've asked to receive. Clients of such a monitoring service could do things like send daily email updates on map activity to users interested in a specific area or tag, invalidate tiles in custom-rendered maps, or assemble a subset of available OSM data for fast, up-to-date querying within that subset (a single city, for example) without worrying about making lots of requests to the OSM API. That third application would be useful for solving one of the problems I ran into with my 2010 project -- I was optimistically loading map data with bbox queries as the user panned the map, which was too slow on the production API to be practical (and probably isn't what that part of the API is really meant for). Another project idea might be to work directly on a service which would provide fast querying on tag or area subsets. However, the project as I've proposed it above seems to me to be sort of a generalization of that, and also seems like it would require less bandwidth and disk space. I wouldn't worry about monitoring area changes, as we have OWL[0] (supposedly being integrated with the Rails port), Changepipe[1], and possibly others that do this already. I'd suggest you consider focusing on the idea of monitoring for changes based on tags and object IDs. I've been interested in changes to some large relations, and other widely dispersed objects, which isn't addressed by any of the current tools. Integration with Rails would be great, so we can Watch any object directly from the website. Of course performance would have to be considered before implementing such a service went live, but I don't think that's terribly important for a GSoC project. -Josh [0]: http://wiki.openstreetmap.org/wiki/OWL_%28OpenStreetMap_Watch_List%29 [1]: https://github.com/migurski/Changepipe ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Soliciting feedback on conflation plugin
On Thu, Mar 1, 2012 at 9:13 AM, Josh Doe j...@joshdoe.com wrote: 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 One thing I forgot to mention is that you'll need to update utilsplugin2 to the latest version, as I had to make some changes in there. Just run Update plugins in Preferences. Note there are some limitations, such as you cannot replace an un-uploaded way with an un-uploaded way or an uploaded way with an uploaded way (one needs to be uploaded, the other not). I've mostly been testing this with nodes and ways. Read the wiki for more issues that need to be addressed, but this is certainly on the list. -Josh ___ josm-dev mailing list josm-...@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
Re: [josm-dev] Creating custom validation
On Fri, Feb 24, 2012 at 6:20 AM, Morten Olsen lysgaard mor...@lysgaard.no wrote: Running a child project using the OSM stack I'd like to create custom validation rules for JOSM. Can this be written as a plugin? I'd suggest you create a ticket on Trac. I recently made the changes required so plugins can register search operators [0], and you'd follow a similar process. I've never worked with validation before, but a quick look indicates you'd need to create something like addTest(ClassTest test) to org.openstreetmap.josm.data.validation.OsmValidator. How is this done currently? Is there some sort of abstraction. So that you write a function that tells if an object is valid, and then JOSM takes care of mapping this function over all the objects that are to be uploaded? Enlighten me, thanks in advance =) Yes, you would subclass Test [1]. -Josh [0]: http://josm.openstreetmap.de/ticket/7178 [1]: http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/validation/Test.java ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Our #switch2osm story
On Sat, Feb 11, 2012 at 5:00 AM, Sven Geggus li...@fuchsschwanzdomain.de wrote: Helge Fahrnberger he...@toursprung.com wrote: As existing options don't cater very well for the world of tourism and outdoor sports we have decided to render our own tiles, with hill shading and contours. Would you mind sharing some Information about the technology in use? tirex, mod_tile, tilecache, mapnik, mapserver, TileMill, ... That would be great, and can we get this on http://switch2osm.org/case-studies/ ? -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] Using changesets-latest.osm
On Sat, Jan 28, 2012 at 5:01 PM, Toby Murray toby.mur...@gmail.com wrote: I present ChangesetMD: https://github.com/ToeBee/ChangesetMD What kind of stats are you (and others) thinking about generating? I'm interested in seeing editor stats such as a time series of editor usage, which editors people use (predominantly one or a mix, progress from using one to another, etc.), the frequency and quality of comments by editor, what tags people use besides the standard comment/source/etc. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
[OSM-dev] Combine ways with gaps (dashed line)
I'm working with digitized files that result in multiple way segments that should be a single way, because the original line is dashed. Anyone know of a script that can fix this? I can imagine a simple algorithm that takes a distance and angular tolerance to combine way segments, but I thought I'd check here first. Thanks, -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
[OSM-dev] Completeness-checking scripts
By completeness-checking I mean comparing OSM data to an authoritative data source such as UK OS Locator (bounding boxes and names for roads), a comprehensive list of businesses provided by a trade association, etc, and somehow producing an analysis of the differences, whether it be a map, a list, or even a summary by county/burough. Of course a difference does not mean OSM is wrong. :) I'd like to know of any completeness-checking scripts that might be out there that aren't documented on the wiki: http://wiki.openstreetmap.org/wiki/Completeness I'd be happy to add to this list. My interest is in comparing my county's data to OSM, for schools, parks, streets, and other features. Thanks, -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Script for generating stats by region?
I'd like to generate some HTML or wiki tables for my county showing percentage/number/length of roads that fit some criteria, like unedited TIGER, unreviewed TIGER, no maxspeed, etc., giving some hard numbers to what all the visualization tools like ITO show. I'd like to break it down by school and/or political boundaries. If I have to I'll write something in Python that uses polygon files and Osmosis to split the data and count these features up, then generate the tables, but I'm wondering what might exist out there already. I couldn't easily find anything on the wiki under the stats or QA pages. Thanks, -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] Script to merge ways with identical tags
2011/12/5 Josh Doe j...@joshdoe.com: On Dec 5, 2011 8:29 PM, Iván Sánchez Ortega i...@sanchezortega.es wrote: On Martes, 6 de Diciembre de 2011 02:21:13 Ian Dees escribió: I have some code in shp-to-osm that does glomming, but it's really not any smarter than storing all node locations in memory and check for overlaps. I think ogr2osm does something similar. Yeah, ogr2osm splits linestrings into tagged segments, then loops through segment endpoints, checking if any segments have the same tags, etc etc etc. ogr2osm is what I'm using, however it doesn't seem to be doing this for the files I've used. Does it only work in certain conditions? I'll take a look at the implementation later. It appears ogr2osm does not combine ways that have identical tags (so called glomming), but rather simply combines two-node segments if they are part of the same linestring. I don't think it would be hard to add glomming to the script, but I have code from Mike that's working for me right now. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] ogr2poly.py with buffering and simplifying
I created a Python script to convert OGR supported files (Shapefile and many others) to the polygon filter file format used by Osmosis and other tools. It will optionally buffer and simplify polygons for you. You can buffer point and line features to create polys as well. My motivation was for extracting OSM data for county political and school districts, the boundaries of which are provided as Shapefiles. I could have assembled ogr2osm, polyconvert, polybuffer, and simplify-poly, but writing this seemed easier. Take a look here, and please provide any comments. I can put it on the OSM SVN later: https://gist.github.com/1434632 -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Script to merge ways with identical tags
I'm trying to convert a Shapefile of my county's streets to OSM (not for mass imports, trust me), but every street is broken at intersections so there are often dozens or more segments that should be joined. Anyone have scripts or code to perform this sort of way-merging? I did come across Frederik's merge-ways.pl script, but I didn't have much luck with it and it seems to be designed for rendering purposes. Thanks, -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Merkaator port to Android
On Fri, Dec 2, 2011 at 8:13 AM, Ian Dees ian.d...@gmail.com wrote: On Fri, Dec 2, 2011 at 6:56 AM, Jaak Laineste jaak.laine...@gmail.com wrote: Hi, as you may now, during GSoC QGIS was ported to Android tablets (http://hub.qgis.org/projects/quantum-gis/wiki/QGIS_Mobile_GSoC_2011). Merkaator has technically same base elements: Qt, GEOS, PROJ.4 etc, so based on this experience porting of Merkaator could be also possible with much smaller fuss. It should be even smaller work than getting JOSM working under Android. Question: do you know anyone who really would need and use it? Jaak, Porting JOSM to Android would be an interesting academic task, but several problems lead me to believe it would not be useful for general use: - java.awt is nowhere to be found on Android. JOSM's rendering engine would have to be completely re-written. - javax.swing is nowhere to be found on Android. JOSM's UI system would have to be completely re-written. - JOSM's UI is based on menus and keyboard shortcuts. These don't have good analogs in Android and would have to be re-thought. I'd much rather see the time spent solving these problems put towards a general purpose editor that is specifically designed for a tablet. Maybe something general enough that an iOS and Android developer could use the same design with platform-specific tweaks. All valid points, however it may be useful to reuse much of the non-GUI code for handling file loading, validation, search, etc. Or perhaps it may be more worthwhile to write a nice HTML5 app that can work on iOS, Android, and the web. I think the hardest thing is coming up with a design that works well on tablets. I think first and foremost it should offer a simple and robust way to edit POIs. A good preset system is a must (share with Potlatch2 or JOSM, don't create a new one!). Allow ways to be created both by tapping nodes and drawing (with simplification algorithm). And definitely have online and offline modes. I'd encourage you to create a wiki article to try and define what should go in to a tablet app. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] How to show isochrones on slippy map
On Sat, Aug 20, 2011 at 2:33 PM, Josh Doe j...@joshdoe.com wrote: So now that I'm figuring out the necessary bits to generate isochrones (or rather distance isolines) from OSM+pgRouting+GRASS, I'd like to put this on a little web app to allow users to specify an arbitrary start point and distance (and later select from several profiles). I've gotten something basic working, after hacking the QGIS contour plugin, but can at least generate polygon layers and show them on an OpenLayers map. Code is here: https://github.com/joshdoe/pysochrone -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Custom costs with pgRouting and osm2pgrouting
On Thu, Sep 1, 2011 at 11:21 AM, Toby Murray toby.mur...@gmail.com wrote: I may be trying to do something similar soon. The local bicyle club wants to have a routing service that takes the bikeability of roads into account. Some information has already been tagged on all the roads in the city so now I just need to find a routing engine that will use the tags. Sorry, don't have any answers yet - I just started looking at this last night :) Definitely take a look at this wiki page for my project: http://wiki.openstreetmap.org/wiki/Safe_Routes_to_School_Mapping_Toolkit There certainly is some common ground, such as defining safe/fast/easy biking profiles, and you may be interested in biking distance maps, like you can see on that wiki page. I gave a presentation on OSM and this concept to my local biking club: http://www.slideshare.net/JoshDoe/openstreetmap-presentation-to-fairfax-advocates-for-better-bicycling I hope we can collaborate in some fashion. Cheers, -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Related terms in the wiki for improved tag search
Sounds interesting. Anyone ever thought of installing Semantic MediaWiki?
This would be a great use for it, among other things.
-Josh
On Sep 1, 2011 3:22 PM, Stefan Keller sfkel...@gmail.com wrote:
We are currently experimenting with our TagFinder
(http://152.96.56.32/poiservice/tagfinder ) and want to improve the
search for OSM tags.
One of the crucial point there is that synonyms and related terms are
found (term being one ore more words). Example: A search for church
will show amenity=place_of_worship.
In order to achieve this a controlled word list (a thesaurus) becomes
necessary. This is a list of terms where some are OpenStreetMap
specific. This can not be found in a general purpose thesaurus.
= Because of this, I propose to capture in the OSM wiki so-called
related terms. They can be kept up to date by the community (while I
would like to set a good example).
Of course it would be more precise to introduce also synonyms and
broader/narrower terms. But that seems too complicated for many users.
= In order to store related terms I propose to use wiki templates.
That would look like this on a OSM wiki page (eg.
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dplace_of_worship ):
{{RelatedTerm|place of worship}}
{{RelatedTerm|church}}
{{RelatedTerm|mosque}}
{{RelatedTerm|synagogue}}
{{RelatedTerm|en_GB|devotion building}}
{{RelatedTerm|en_US|prayer house}}
The related terms are parsed from the Wiki pages by Taginfo during the
update process and stored in Taginfo database (as it's already doing
for the tag template). The terms lists are then passed over to the
Taginfo API. BTW: The preferred term (Preferred tag) can be
estimated by the tag statistics API of Taginfo.
Theoretically parts of this code could be ported over to the search
Taginfo (the Taginfo API is already used now by our TagFinder).
= What do you think?
Yours, Stefan
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Multiple temporary API instances
I'm interested in providing a facility whereby users can create and edit copies of OSM data for a small region, say 16 sq miles (~40 sq km). This is for a project [0] that I'm working on which would allow for users to experiment with adding/removing walking and bicycling infrastructure around a school to see how the changes impact accessibility (i.e. how many more kids can walk or bike to school given a specific change). While I'm quite a ways from implementing a full web app for all of this, I'd like to understand the challenges I'd be facing. I'd like to allow all of this to be done via a web interface, and I think Potlatch2 would be a good editor to provide. For that I'd need to set up a server side API, for which I believe the rails port is the only option. For a given school, it's possible that there could be dozens of users making changes to the same area, and each user may want to try out different combinations of changes. Therefore it makes sense to introduce the concept of scenarios, where each scenario consists of a copy of the main OSM data. Users should be able to create, copy, and destroy these scenarios on demand. begin-uninformed-conjecture Each scenario should likely exist as a separate set of tables in the database sharing a unique prefix. A fork of the rails port would then need to be modified to allow the URL to specify which scenario (prefix) to use, and would then query those tables. Potlatch2 could then point to this scenario-dependent URL for the API, and everything would work magically. :) Seriously though I have no actual experience using the rails port or Potlatch2 (as a developer), this is all based off my reading of the wiki documentation, and I'm sure things are much more complicated and this project would require extensive modification of the rails port, if not necessitating writing something from scratch. I also have no idea how this sort of implementation would scale up to thousands of scenarios. Thanks for your input, -Josh [0]: http://wiki.openstreetmap.org/wiki/Safe_Routes_to_School_Mapping_Toolkit ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] How to show isochrones on slippy map
On Mon, Aug 22, 2011 at 1:52 AM, Richard Weait rich...@weait.com wrote: These might inspire you: Where should you buy a house (in your price range) for the shortest commute time? http://www.mysociety.org/2007/more-travel-maps/ How soon can you meet with three friends coming from different places in Paris? Where should you meet? http://old.isokron.com/ Thanks Richard, I've put those links and others on the wiki: http://wiki.openstreetmap.org/wiki/Isoline -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] JOSM donations?
On Fri, Aug 12, 2011 at 10:54 AM, Dirk Stöcker openstreet...@dstoecker.dewrote: But in the long time I'm software developer I heard many people complaining about missing documentation, but nobody of these every wrote a single paragraph to solve this situation. Agreed. People complain about the OSM wiki being out of date, but rarely update it or even report the problem. If it's important to you, then fix it. If you wish there was a Esperanto translation, then just do it. If you think there should be documentation on the history of a command, then keep on eye on the SVN changelog and update the docs as needed. Dirk has enough on his plate. Suggestions are welcome, but there is no guarantee anything will get done unless people get involved. -Josh ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[OSM-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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
[OSM-dev] Converting OSM Mapnik stylesheet to Cascadenik or Carto
I'm curious if anyone has ever attempted to convert the massive OSM Mapnik stylesheet to one of the CSS-like languages such as Cascadenik or Carto. Is it even possible? Maybe some features used are not implemented by either of these preprocessors... -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Converting OSM Mapnik stylesheet to Cascadenik or Carto
Thanks for all the info. It seems Cascadenik has been superseded by Carto, at least that's my impression, as Cascadenik hasn't been touched since last year, and Carto is inspired by Cascadenik but has seen more recent and active development. It would be interesting to see a comparison between Carto and MapCSS. However I'm not sure if OSMF would even be interested in changing the main stylesheet over to one of these. -Josh On Wed, Jul 27, 2011 at 11:21 AM, Andy Allan gravityst...@gmail.com wrote: On Wed, Jul 27, 2011 at 4:03 PM, Phil! Gold phi...@pobox.com wrote: * Josh Doe j...@joshdoe.com [2011-07-27 10:52 -0400]: I'm curious if anyone has ever attempted to convert the massive OSM Mapnik stylesheet to one of the CSS-like languages such as Cascadenik or Carto. I started trying to do a conversion to Cascadenik, but gave up on it because Cascadenik was generating tons of unnecessary rules (basically, the cartesian product of all my selectors) that slowed Mapnik down quite considerably. Maybe it's possible, but it's certainly not for the faint of heart. There's a new feature in mapnik to handle this better which carto uses - a flag for mapnik to match only one rule per style. Saves all the and not X and not (not X and Y) that Cascadenik generated. I don't know how much it helps though, all my projects have either been XML or cascadenik, or carto, and I've never tried converting one to the other and comparing benchmarks. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Planet file on errol
I'm new to errol, but I can't seem to find any planet files on /data/planet, though the directory is there: http://wiki.openstreetmap.org/wiki/Dev_Server_Account_Policy I'll likely just use a Geofabrik extract, since all I need is a subset of the US, but I'd like to fix the wiki if it's in error. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet file on errol
On Mon, Jul 11, 2011 at 2:31 PM, Tom Hughes t...@compton.nu wrote: On 11/07/11 18:36, Josh Doe wrote: I'm new to errol, but I can't seem to find any planet files on /data/planet, though the directory is there: http://wiki.openstreetmap.org/**wiki/Dev_Server_Account_Policyhttp://wiki.openstreetmap.org/wiki/Dev_Server_Account_Policy I'll likely just use a Geofabrik extract, since all I need is a subset of the US, but I'd like to fix the wiki if it's in error. They're not there at the moment because it was an NFS mount from the planet server, but that has now been moved to a different site and we don't want to do an NFS mount over a WAN link. We will probably setup a local mirror when we get a chance. Thanks, updated the wiki to reflect this. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] Can I get distance across dry land with OpenStreetMap
I'm not sure if you'll find what you're looking for in use by current OSM software. You're thinking more about AI pathfinding in video games: http://en.wikipedia.org/wiki/Pathfinding If you find something that ingests OSM data and can do this sort of routing I'd love to hear about it! -Josh On Tue, Jun 14, 2011 at 11:52 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: I have the following problems I want to solve with OpenStreetMap data: * For points A and B, detect if either one is on an island, and that you therefore can't traverse between them without a swim. * For points A and B, get the distance between them by land. E.g. if A and B are on opposite sites of a fjord. The routing libraries I've found seem to all assume that I want to route across roads, whereas for this task all I need is just a coastline shapfile of the planet. I'd then find out if A and B are on different coastlines, or the shortest path between them on land. Is there anything that does this already? I'm fairly sure I could do some cleverness with PostGIS to find out whether the line between points A and B crosses the ocean, but what I actually want is the distance between them sans ocean. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] CSS for pre, source on wiki
I'm not sure if it's just me, but the font size for pre and source blocks on the wiki is way too small. I don't see any reason why it shouldn't be the same size as other text, such as with Wikipedia. Also, it would be nice to surround source blocks with a dashed border and slightly darker background, again like Wikipedia does: http://en.wikipedia.org/wiki/Groovy_%28programming_language%29#Features http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi#Method_1.2C_CSS_file I've already made the changes in my user CSS, but I'm sure others could benefit from the increased readability. -Josh ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] [Strategic] OSM front page discussion and user survey results (with pictures)
Can someone point me to discussions regarding OSB and MapDust? I'm not sure if there have been any, but I couldn't easily find any. OSB is mentioned on the MapDust wiki page, but not the other way. MapDust seems fairly well developed, though I understand the MapDust DB is privately operated, so I know it not something OSB could use. But what about learning from what they've done, or perhaps working together to use a common API? That way there could be multiple bug services, some privately operated (like Skobbler/MapDust) and others like OSB, but consumers could all use the same plugins, web interfaces, etc. -Josh On Sun, May 1, 2011 at 3:41 PM, Steve Coast st...@asklater.com wrote: WORKSFORME Is it still correct to call is OSB though? It feels like a rewrite, integrated in to the rails_port. When you say OSB I think of OSB. Steve On 5/1/2011 12:37 PM, Kai Krueger wrote: Should we not move the discussion about the details of the OpenStreetBugs implementation from the strategic mailing list over to the dev list? (which I have CCed) It seems there is general consensus about that if technically done correctly, an instance of OpenStreetBugs integrated into the main page would be welcomed and useful, so the strategic aspect is done and we are now well into the implementation phase. Kai On 29/04/2011 13:55, Steve Coast wrote: So I played with it, it looks pretty good. My changes would be relatively minor, plus some questions. * Only let me enter bugs when zoomed in a fair way * Don't show me all the bugs just by default on the map. * I really don't believe in having to click the map again to enter a bug. My mum would be confused. Just use the center point of the map. So the model is, click to enter bug, popup, it says be as descriptive as possible, done. The extra click makes a lot of sense for you and me, but not someone new. I know there are a ton of but, but, but arguments against this, but really, simple is _so_ much better. Now questions * I'm assuming the API looks sane? * I'm assuming the data is all going in to whatever rails db is talking to, not some magical special other db? * I'm assuming there has been some cross-browser testing? * I'm assuming there is a proper db migration I'm happy to take a peek at the code too and make some adjustments, where is it? Steve On 4/29/2011 10:39 AM, Kai Krueger wrote: On 04/29/2011 02:56 AM, Eugene Usvitsky wrote: * Report an error link to OpenStreetBugs I'd like to mention that there is a (more or less) fully functional implementation of the Report an error functionality at http://openstreetbugs.dev.openstreetmap.org/ It is heavily modeled after the ideas of the original OSB (and uses large parts of the client javascript written by Candid Dauth), but is fully integrated into the rails_port. Apart from having the bugs stored in the main OSM database, this also allows to hook into OSM's user management to make it easier to keep track of your own bugs and bug comments. This might make it easier to communicate between bug reporter and mapper. The Api was also slightly adopted from the original OSB API to be more in line with the other rails APIs. It is mostly a rename, though, so it shouldn't be difficult to adapt existing clients to the new API. A year ago, when I did the bulk of the coding, I talked to Mitja Kleider (the maintainer of the current OSB instance) about possible transition strategies from the external OSB instance to the integrated one once things are ready. He said it would probably be possible to use the existing URLs as a proxy to not cause any disruption for existing clients in the transition period and thus gracefully moving over without any losses. Tom has just agreed to have a look at the code and review it in the next couple of weeks, so depending on what his review sais and how much change and clean up is necessary, we might be able to see some progress on this fairly soon. If people have comments and suggestions on what can be improved, I'd be grateful for any tips. However, my priority is on getting something workable and usable actually deployed before adding too many new features. Kai ___ Strategic mailing list strate...@openstreetmap.org http://lists.openstreetmap.org/listinfo/strategic ___ Strategic mailing list strate...@openstreetmap.org http://lists.openstreetmap.org/listinfo/strategic ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/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
Re: [OSM-dev] [Fwd: Mail delivery failed: returning message to sender]
Alas I do not have any infrastructure to provide, but for quite a while now I've thought of how useful it would be to gather this sort of data. I think we all can attest to the fact that routing solutions (commercial or otherwise) often produce results which are not optimal, and can even be laughed at by locals who know you'll be stuck for hours if you try and take the proposed route. Some might say we just need more speed limit information, which would certainly help, however that will not provide a complete picture. Cyclical traffic patterns, traffic signal timing, and frequency of accidents are just a few of the complex factors that determine the best route. Until we have live traffic data on every road, and that data is free, I think this method of gathering average speed per road per date/time would be of great help. If the infrastructure to gather and disseminate this information matured sufficiently, it could even be integrated into commercial navigation units for both consumption and feedback. Of course private companies are doing this sort of thing already, and I'm not addressing privacy concerns, but I think it would be great if some interested party started work on this. -Josh On Sat, Apr 2, 2011 at 8:34 AM, SteveC st...@asklater.com wrote: whoops... sent to wrong address can anyone help? -- Forwarded message -- From: Mail Delivery System mailer-dae...@asklater.com To: st...@asklater.com Date: Sat, 02 Apr 2011 13:29:47 +0100 Subject: Mail delivery failed: returning message to sender This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: d...@openstreetmap.com SMTP error from remote mail server after RCPT TO:d...@openstreetmap.com: host a.mx.openstreetmap.com [89.16.179.150]: 550 relay not permitted -- This is a copy of the message, including all the headers. -- Return-path: st...@asklater.com Received: from [64.236.163.23] (helo=[10.0.2.15]) by asklater.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from st...@asklater.com) id 1Q5zxZ-0001Bx-2l; Sat, 02 Apr 2011 13:29:45 +0100 Subject: Re: Average speed data for OSM From: SteveC st...@asklater.com To: Richard Willars richard.will...@lemonstorm.com Cc: d...@openstreetmap.com In-Reply-To: banlktikvw-q-2lyby4jnty6mwy1cio+...@mail.gmail.com References: AANLkTin_y7nj5EmbfPW=fp_au6wpj6jykzdlcavtv...@mail.gmail.com 1301744774.1805.6.camel@ubuntu banlktikvw-q-2lyby4jnty6mwy1cio+...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Date: Sat, 02 Apr 2011 05:28:15 -0700 Message-ID: 1301747295.1805.27.camel@ubuntu Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit hi anyone able to help? On Sat, 2011-04-02 at 13:04 +0100, Richard Willars wrote: Hi Steve, No problem, that's absolutely fine. Regards, Richard On Sat, Apr 2, 2011 at 12:46 PM, SteveC st...@asklater.com wrote: Hi This sounds interesting and useful -do you mind if I pass this on to our dev list to find people to help out with it? Steve On Sun, 2011-03-27 at 15:45 +0100, Richard Willars wrote: Hi Steve, Our company is developing a solution that's going to be used by lots of different courier companies, and although I'd like to use OSM for our mapping / routing data we feel that the data isn't quite at a level that can be used by commercial solutions. However, we really like the concept of OSM and would like to contribute data wherever we can. In all the courier vehicles we will be fitting bespoke telematic solutions. These will log vehicle data every 10 seconds, including data such as current location speed and acceleration and braking information. We'll be logging this data and producing average data for each road way a vehicle travels down, and keeping separate profiles for different types of vehicles, dates and times. I believe that this matches most of the specification detailed on http://wiki.openstreetmap.org/wiki/Average_speed_per_way. As the vehicles will be travelling down all types of roads the dataset could potentially be more accurate than providers such as Navteq, where they only focus on speed data for main roads. If you're interested in my company providing this data on a regular basis for the UK please let me know. If so, we will require one of your team to work with us to
[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: [OSM-dev] Regarding GSoC 2011 and the 'Develop a simple mapping tool for phones' idea
Very ambitious indeed! I don't have much to comment on at the moment, but I would suggest you do a thorough review of existing FOSS Android apps which use OSM, as I know there are a quite a few. Many of them seem to be simple map viewers, but I imagine some of them have more complex features. Bonus points if you write a summary on the wiki. :) Good luck, -Josh On Sun, Mar 20, 2011 at 2:32 PM, Achintya Prakash achint.prak...@gmail.comwrote: Hello everyone, awesome to see you guys selected for GSoC 2011!! My name is Achintya Prakash and I'm a third year undergraduate student of Computer Science, based in India. I've been involved with android development for well past 3 months now, and have dabbled in a lot of different aspects of it. Recently, I had the fortune of being chosen to attend a Design and Innovation workshop held by people from the MIT Media Labs, where amongst other things like efficient storyboarding/designing/brainstorming techniques, they also gave tutorials on android development. I'm also a student of an android development course in my college, and I must say, its more fun than I would have ever thought!! That's a bit of background about me, but the real thing is that I would love to work as a student for your organisation on something related to android. I recently submitted, as my mid semester 'mini' project, the outline for an application that would give reminders not only based on time, but also location (the inspiration behind this was the fact that I would drive around town and always pass the places where I had to pick up something without noticing. Having a simple timed reminder didn't always help, since I couldn't really know the time at which I would be in the locality!) After I gave the skeleton of the app, my teacher gave me a few suggestions to make it more useful, so I wanted to propose an idea for a project. This project closely parallels your idea for Develop a simple mapping tool for mobile phones, although the functionalities I have mentioned go further in scope than the GSoC timeline (since I plan to keep contributing to this idea). I would love to work on a project like this, and hence *would like to work on developing the simple mapping tool for phones* as a part/component of this extended project. App name: Effective route tracing and recording Functionality: A passive route logging tool for android phones. The basic ideology is that the route traversed by a single person should be remembered/logged if required for later reference, without any active input being given by the concerned person. A visual representation such as overlays presented on a map/ values of latitude and longitude/ a more human friendly address name( as decoded via geocoder) and intelligent direction sensor ( turn left on Abbey Road, or something along those lines) be the desired output. A number of added functionalities should be incorporated: 1. The ability to 'record' a route as a person is moving. 2. The ability to transfer a pre-recorded route via a multitude of ways, including through sms (the easiest way would be through a series of latitude/longitude, arranged in an appropriate format that could be read by the application and translated as overlays on a map, or some other visual representation), via wifi, bluetooth etc (could have an intelligent sensing to see the most efficient method based on a certain criteria, hence giving the user freedom from having to choose). 3. The ability to run real time route transfer ( especially useful in cases where you have a lot of people following each other in cars, where only one person knows the way). The 'master' phone would logging at predefined intervals and sending over the information to the 'slave' phones, which would automatically display the visual representation. 4.The ability to add user information to the route-points. Especially useful in cases where a pre-recorded route is being sent, user input could include textual or pictorial messages ( example, if giving directions, you may include a picture of a well know nearby landmark, or just any structure and include text references like 'take left here'.) Drawable attributes like being able to scribble, draw arrows, circles etc on the sent information should also be included. These are the initial proposed functionalities that I would think would make the application extremely useful in a lot of situations. Alternatively, there are a number of better improvements that can further be done: 1. To have the route synced with local traffic/ news updates, hence be alerted in real time if the route is congested or under repair. 2. Have an intelligent route sensing system that could, based on machine learning and frequent routes travelled, suggest alternatives/status updates of the routes. (Example, if a person travels via the same route to office everyday, or something) 3. Have different 'modes' of route sensing
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] projection Mercator, set EPSG 3785 instead of EPSG 3857
What timing. I just created a wiki page on this very subject. [1] I've been meaning to submit a bug, but the Mercator projection in JOSM is NOT EPSG:3857 as it claims, I'm not sure what EPSG or ESRI code it corresponds to. The definitions of EPSG:3785 and EPSG:3875 are different, but they should be equivalent. -Josh [1]: http://wiki.openstreetmap.org/wiki/EPSG:3857 On Sun, Feb 20, 2011 at 8:44 PM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: 2011/2/21 Frederik Ramm frede...@remote.org: Hi, 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 know that 3857 was introduced to replace 3785 but I get (got) slightly different results for 3785 and 3857 and the definitions you can find at EPSG are also slightly different. ( I am aware that EPSG says that 3785 is not valid). cheers, Martin ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Problems creating TileSource for ArcGIS REST API
As I've mentioned on this list, I'm interested in support in JOSM for the ArcGIS REST API [1], as my location (Virginia, USA [2]) has very good quality (1ft resolution, off-leaf), public domain imagery, but is only available via that API. Ian Dees suggested I extend AbstractOsmTileSource and convert the requested tile x/y/zoom to coordinates, and then use the export interface of Arc GIS REST [3] to request the tile. I've implemented this, and I'm happy to see that the imagery lines up correctly, however there are gaps between vertical tiles, which you can see in this image [4]. You can view the code here [5]. Why might this be happening? I'm guessing it has something to do with projection differences, but I don't really know. The Virginia ArcGIS REST server uses the Virginia LCC projection, so I first convert the tile x/y/zoom to WGS84 lat/lon corners, convert those to Virginia LCC using the Proj4J plugin [6], then submit the URL to the server. I know this should be a temporary solution anyways, as I should be using the tile cache provided by the server, however it seems more difficult to implement considering the tiling scheme is completely different than the mercator system used by TMS, so I'd need to do more than just create a TileSource, but rather assumptions about resolution and zoom levels must be changed in other JOSM code. Any thoughts would be appreciated, thanks! -Josh [1]: http://resources.esri.com/help/9.3/arcgisserver/apis/rest/index.html [2]: http://wiki.openstreetmap.org/wiki/Virginia#2006.2F2007_VBMP_Orthoimagery [3]: http://resources.esri.com/help/9.3/arcgisserver/apis/rest/export.html [4]: http://postimage.org/image/7g16nd6s/ [5]: http://java.pastecode.com/2183 [6]: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Proj4J ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Problems creating TileSource for ArcGIS REST API
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 Mercator projection by passing in a projection id of 102113. Interesting information on this topic: http://forums.esri.com/Thread.asp?c=93f=984t=288073g=1 ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Problems creating TileSource for ArcGIS REST API
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 Mercator projection by passing in a projection id of 102113. Interesting information on this topic: http://forums.esri.com/Thread.asp?c=93f=984t=288073g=1 ___ josm-dev mailing list josm-...@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
