Re: Accessing third-party repositories
Frederik Ramm writes: > I can understand that if I load Ilya's geochat plugin it will phone home > to Ilya's server, or if I enable certain imagery layers they will load > data from the imagery server. Also it is clear that JOSM will access the > OSM and JOSM servers. But I think that we should not add random third > party web sites that are under control of neither OSMF nor the JOSM team > to the mix without explaining this to the user and asking for their consent. Agreed that this is the right expectations. There's an interesting issue with third-party imagery and map layers, which is how users know their privacy policies, such as what records they keep of which IP addresses looked at which areas, and if this is diclosed, etc. It would be good to have a standardized access point for these (that one can discover from a tile URL), and to have these links assocatied with the tile layer definition. The next step would be some standard semantics or simply human evaluation of whether the tile provider commits to nondisclosure, non-use and/or non-retention.
Re: using .tfwx w/GeoTIFF files with the JOSM image import plugin
Richard Welty writes: > is this practical? image import wants a tfw file which i don't have; > i have the tfwx and aux files instead. I am not familiar with tfwx. I would guess wildly that it's an XML version of tfw, because a file with a few numbers isn't cool anymore. The longstanding geotiff norm is a tiff and a tfw. A tfw for an arbitrarily-selected DRG within "boston west" is: 10.1561 0. 0. -10.1561 248898.44273176 4712074.36193996 If you have the corresponding data, then creating a tfw is pretty easy mechanically. Description on wikipedia, or probably see the geotiff sources. https://en.wikipedia.org/wiki/World_file In the case above, I am pretty sure the coordinates are in NAD83 zone 19 UTM - this is a rasterized version of the USGS 1:25000 metric topos, back when you had to pay them for copies on CD (20 years ago IIRC). If you want to send me your image, tfwx and aux offline, I'm happy to look at them.
Re: [josm-dev] IPv6 problems
I should clarify: My IPv6 setup is working fine. The problem is that my upstream ISP has routes to most parts of the v6 world but is missing a few, I'm guessing due to a peering dispute. This is the same sort of thing that can happen in v4, although I think it is less common. So this is a "internet connectivity problem in the core", not setup issues on my end. signature.asc Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] IPv6 problems
I'm not sure if I should file a ticket, or report this here, so I'll start here. I have been running JOSM for a long time, on a Mac, currently at OSX 10.7. I have functional IPv6, but my tunnel is from OCCAID, and occasionally some places are unreachable - currently api.openstreetmap.org is one of them. josm starts up and proclaims: INFO: Detected useable IPv6 network, prefering IPv6 over IPv4. which is fine, but then when downloading data (simple pushing of download icon, letting area be, and then pushing the download button in the popup) normally, I get an API error. I can ping api.openstreetmap.org on v4, but not v6, where I get a network unreachable in New York. If I had a 2-minute delay and then a download, there would be a more subtle happy eyeballs issue, but I totally failed to download data a few hours ago. Just now, I was able to download data. So it seems that there is some notion of only trying one address family, vs. trying all addresses in all familes in some sort order, and only failing if all fail. OSX itself has some version of Happy Eyeballs which uses RTT on v4 and v6 to the address (prefix?) to decide which to try first, I think via sorting getaddrinfo results. I am totally unclear on how this interacts with Java. This can likely be reproduced by configuring nonworking IPv6. Greg (osm user gdt) signature.asc Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Is the should upload logic a little too eager?
On exit, JOSM offers to save data to disk when it's modified, and this is of course totally fine. It also offers to upload, and I find this to be useful sometimes and sometimes troublesome, in two unrelated ways. * inspection of not-yet-uploaded data case Suppose one has a .osm file that's proposed for import, and is reviewing it. It seemed natural to open it in josm, and look at it in a layer with the existing data in another layer, and imagery. Then, after deciding what I thought, I exited JOSM. But, JOSM offered to upload the new data. I of course clicked no, exit anyway, but it seems that this prompt could lead to unintended uploads. So, I'd suggest that each layer have a property of whether (some) data was downloaded, and only offer to upload data from layers that both 1) have had download operations and 2) have had manual editing operations. (I realize this may require storing metadata for which there is no convenient place.) * saved edits case A while ago, I made edits to an area (in JOSM, entirely normally, not very large, 20 minutes worth of hand editing), and went to upload them. My memory is fuzzy, but I think the upload had trouble, and when I went to exit, I got the should upload prompt. So I did (since I knew all the changes were my recent edits). It turns out that the upload happened twice, or at least the db had many objects added by me twice. (I noticed this running the validator over my whole town.) Specific suggestions to avoid this kind of trouble: ** Somehow, when opening a file with un-uploaded changes, show in the command stack at least a representation of what's not yet uploaded. I find that after saving and restarting, that's empty. ** After an upload which does not complete normally, set a flag that requires an update modified operation before another upload can happen (and this needs to persist in the file). pgpu73W213tJ2.pgp Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] validator suggestion: way ends close to other highway
I've been running the validator over my whole town (roughly 6km x 6km), trying to fix all the real issues. Overall it's very helpful. Except for the case below, I am able to understand quickly what it finds problematic. (I find that the disconnected ways step takes a very long time, perhaps minutes, compared to a few seconds total for everything else. So I've disabled it for now.) I get a lot of warnings for way ends close to other highway. I get the general concept - maybe it should be connected - but it seems overly aggressive about warning. So maybe I am misunderstanding it, but my suggestions are: * make the distance configurable (so that when faced with 250 warnings, one can set this to 0.5m, or 1m, and find the most likely cases that need fixing, as opposed to micromapping where you really can't go from the parking aisle to the nearby road). * in the warning dialogue/highlighting, highlight not only the end node, but the way that is too close, and put the distance in the dialogue box. My second suggestion is because I'm often (98% of the time) unable to figure out what's wrong. Sometimes the way end that's highlighted is connected, but is perhaps near some third way that isn't connected. If people think this validation step doesn't produce lots of false positives, I can send a specific example. Greg pgpA6nPlWrrDe.pgp Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Selecting a line nearest a point
Josh Doe j...@joshdoe.com writes: 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?). I haven't had enough spare time to get to this, but I've wondered about having josm store the local data in postgis instead of a file that is read/loaded. That would enable having more data (josm does much better than it used to, it seems), and also provide spatial queries. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Microsoft gains access to aerial imagery
M∡rtin Koppenhoefer dieterdre...@gmail.com writes: 2010/11/24 Frederik Ramm frede...@remote.org: Hi, On 11/24/2010 09:31 AM, Viesturs Zariņš wrote: Paris, Syndney seems more accurate but Moscow, Tallin has similar offset. Is there a way to improve the rectification? The JOSM slippy map plugin does not have a control for moving the layer like the WMS plugin has. I guess one could be added in case of a constant offset at given locations (and not some warping problem), it would be cool to store (and possibly collect in an OSM / JOSM-database) those locations with their offsets for corrections, so that a user wouldn't have to adjust it manually everytime. Presumably MS would want to just fix this, so perhaps we can simply report bugs. pgpiHhod0LXoi.pgp Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
1.6 isn't available for PowerPC Macs, FWIW. Apple haven't made a PPC Mac since 2006. I still use PPC for both my main machines (but then I'm not a JOSM user so that may be moot). This is in my view a sufficient reason to insist that everything work with 1.5. But, if someone just has to download a jar and add it to a command line, that doesn't seem like a big deal, even if it is 7 MB. pgpTzKx2D6aIn.pgp Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Henrik Niehaus henrik.nieh...@gmx.de writes: Cons: 1. JOSM depends on JAXB - 5 jars with a total size of 1MiB (for JDK 1.5. JDK 1.6 comes with JAXB) 2. It's a big patch and might need some time to get everything (including plugins) back to work 3. New bugs, which made their way in the new implementation So, what do you think about this patch? Best Henrik No one interested? I believe that I am bit on the fringe so didn't reply the first time. It sounds cool to have better XML support. But, I have trouble running JOSM on my normal computer because java isn't portable (Sun doesn't release a JDK for NetBSD, one needs a recent JDK due to language changs, and openjdk is in practice not quite there yet), and therefore I have a negative reaction to adding dependencies. But, I suspect that the real issue is with the JDK and additional libraries is not a big deal. All that said, I use GPX in JOSM to read in tracks and display them, and that works fine - I haven't wanted to write GPX. pgpFMdwtE8igY.pgp Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
I can see why some people would find the comment requirement annoying, but coming from using svn for source code it seems very natural to me. I added a bunch of nodes for shops in my town last night and had no trouble typing add some stores in Lower Village, and move some or something like that. As Frederik said it took almost no time compared to placing and tagging the points. The deeper consequence is that this mechanism will probably lead me to make edits in logical groups. This is very similar to the clean changeset notion in subversion. Not that we're going to have stable branches of the data, and merge changes to map releases, but when we talk about browsing changesets and possibly reverting them, it makes sense to have related changes grouped together. I browsed history for my area, and there are mostly global-scale edits with huge bounding boxes. Really I'd like to see some sort of changeset has a node or way that is in or crossed my query bounding box since I think most of these global edits do not change anything in my area. Having comments explaining the purpose of such changes would be nice, so hopefully that will happen. I think I was running into the changeset still open behavior and didn't quite understand it- I did several uploads and was seeing the list of previous changes in the comment prompt even though they weren't modified. I was only running r1526 though and will see if that persists in r1541. pgp3N2Let2fNB.pgp Description: PGP signature ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
