Display photos on map

[datendelphin]

A popular way of taking notes while mapping is by taking pictures. But in order to efficiently use those notes, the pictures should be shown on the map where they were taken.

There are cameras which already record GPS position, there the exif tag could be evaluated.

The more precise way to locate pictures on the map would be by correlating them to the GPS trace with the recorded time.

[tmcw]

fwiw, I think it might be more useful to add photos from an existing service like Flickr, so that we focus less on client client capabilities and make the feature useful for those without a local cache of images.

[simonpoole]

This is the I-took-a-couple-of-photos-of-POIs-while-I-was-surveying-and-the-last-thing-I-want-to-do-is-upload-them-to-somewhere-public use case, not the I-have-a-stash-of-nice-photographs-on-X-that-I-want-to-analyze-for-useful-information case.

Sure the later should be catered for too :-)

[datendelphin]

As simonpoole said, you don't want to put the pictures up for everyone, would be a lot of work just painting over all license plates and faces (if you're not google). I have them just as easy "notes" and not fit for public viewing usually :) (quality and content related)

[tmcw]

https://github.com/tmcw/exif-extract is a first shot at a parser

[datendelphin]

Nice, but not accurate enough yet. For example http://osmd.ch/P1040050.JPG or http://osmd.ch/P1040049.JPG should be about here: http://osm.org/go/0C0kaOPQf-- but it is displayed in the middle of the lake.

P1040050.JPG was referenced by my camera (integrated GPS)
P1040049.JPG was referenced via gpx trace with gpsprune (that seems to delete the embedded thumbnail)

[simonpoole]

tmcw nice and has potential for use outside of iD.

Can't confirm datendelphins concern, http://he.poole.ch/2013-05-23_11-16-51.jpg is bang on (the picture was took at the beginning of the footway). My example does show however that it would be nice to support the orientation value and display the picture accordingly.

[datendelphin]

I found and solved the problem with the inaccuracy. Would still like to see this supported in iD

[vassilevsky]

I'm not sure if this is a good feature for iD.

Taking geotagged pictures / geotagging taken pictures against a recorded GPS track is kind of a professional activity. And professionals can always use JOSM which has a plugin for the pictures.

iD should be a simple editor for ordinary people. Adding pictures all over the place will only clutter the editor. I doubt that this feature will be widely used.

[tmcw]

Mapillary is the way forward: #2260

[simonpoole]

Nope

Just to give some rationale: nothing against Mapillary (I'm a big fan), but I believe we don't want to force mappers to any one third party service. Obviously it would be great to have lots of choices, but given the situation it probably simply bolis down to mapillary and local storage in some form (people do still take photographs with "real" cameras).

[tmcw]

Okay, @simonpoole will implement.

[jfirebaugh]

#2354

[pnorman]

Does #2354 let you display your photos in iD? I thought it was for displaying Mapillary photos in iD, which is a different use case.

[simonpoole]

@bhousel Just to give another use case where having drag and drop of fotos would make things far easier: the typical mapping party with limited outbound bandwith (so uploading to mapillary is too slow, which it likely is in any case in a time limited event scenario) and the mappers have a variety of equipment in use (so upload would require copying to the desktop and using the mapillary upload scripts).

Copying pictures to the desktop and then dragging and dropping them to iD to see location and orientation would be so much simpler than firing up JOSM (with the requiste instructions and so on).

[bhousel]

@simonpoole I agree about the usefulness of the feature, and nobody is against the idea of supporting drag-and-drop local photos onto iD, we just don't have the developer bandwidth to make it happen right now.. You are the only person since 2013 who has brought it up.

That said, we have more people contributing to iD lately who might be looking for a project to take on, so I'll reopen for now and maybe somebody will pick it up and implement it. If that happens, I'd happily merge a PR. That would require:

• add layer 'local photos' which works like 'local gpx'
• add dragdrop handler
• vendor in the exif parsing library
• make sure the existing dragdrop handler that handles gpx files is ok
• add rendering code and css for the images thumbnails maybe using mapillary markers as inspiration

[hctomio]

The possibility to add one geographic photo once a time would already help with our edits.
As is done with the tracks.

[joepie91]

I agree about the usefulness of the feature, and nobody is against the idea of supporting drag-and-drop local photos onto iD, we just don't have the developer bandwidth to make it happen right now.. You are the only person since 2013 who has brought it up.

Just putting in my +1 here - this would be very useful for me. I'm a semi-hobbyist mapper; I do occasionally take a GPS track (through OsmAnd) and I collect photos of simple things that I want to add in iD later (benches, trashbins, shop information), etc. - but it very much needs to remain a hobby for me, and I don't want to invest a lot of time into learning a complex editor with non-obvious UI, making iD pretty much the only suitable option for me that I've seen.

I'm currently working around it with a tool that I quickly threw together, but having to drag-and-drop GeoJSON files and then constantly needing to match them up to the originating photos is still surprisingly much hassle, and it turns this sort of data entry into a "when I get around to it" sort of thing rather than "right when I get home". It would make it a lot easier if I could sidestep the "handling two related files" process and just drop photos on the map directly.

I might have a stab at a PR for it myself at some point, but can't promise anything - like I said, it needs to remain a hobby for me :)

(Especially considering the widespread ownership of GPS-capable smartphones nowadays, this could probably be considered more of a beginner feature now than it might have been when this issue was originally created.)

[simonpoole]

@tyrasd I've added a GSoC project for this https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2022/Project_ideas#iD_editor It would be nice if you could potentially mentor it.

[pedjas]

It is year 2022 and this is still not resolved?

Mapillary is now commercialized and out of picture. We do need simple way to see locally saved georeferenced photographs to get info that we need to insert into map.

[tmcw]

I still get notifications for these issues, and am not particularly involved in the project anymore, but here's my 2c:

Since 2013, thousands of pull requests have been merged into iD. Maintainers have come and gone, and the same with funding sources. Lots of work has happened, and people have poured time into it.

There are a few issues like this one, discussed for years, almost a decade. The discussion of the opening hours field in #974 is an epic. Almost 50 comments. Lots of folks surprised it hasn't been fixed, and throwing in their opinion that it should be simple to fix. Years of comments.

The answer is this:

A project like this has a few maintainers who have limited time and resources and they try to work on the absolutely most-critical, highest-return-on-investment issues they can. There's some wiggle room in judging what's important and what's not, but if you look at the CHANGELOG, well, a lot of that seems pretty important. Security fixes, fixes to the essential tagging infrastructure, and so on. It's hard to pick something in the changelog that seems unimportant or not worthwhile.

Outside of maintainers time, there are some contributors, who care deeply enough about a feature to implement it, and they contribute that feature or change. If you look at the contribution graphs, there are people like Thomas Hervey, who worked on KeepRight support. That certainly wasn't easy, especially with having to onboard onto the project and learn all the conventions and get all the PRs reviewed and merged. But he and others have made the commitment to get it done.

But issues like this one, and like opening hours, don't get finished for the simple reason that nobody does them. They're big chunks of work that aren't critical enough to be a priority for maintainers. And the people who want them enough to ask for them in the issue tracker - well, they don't want them enough to put in the work and implement them, or they don't have the skills, or don't want to put in the work to acquire the skills to implement them.

That's just how it works out. These issue threads could have 50 comments, or 500. It doesn't really matter how many comments there are. Until someone does it, it won't be done.

[simonpoole]

It should be noted that this years GSOC projects included one working on this issue. Not sure how far it has progressed, but one way or another we'll find out soon.

[JesseWeinstein]

Is this not mostly handled by StreetComplete's feature that lets you take a picture when adding a note, and stores the resulting pictures only until the note is resolved?

[simonpoole]

Nope. This is mostly about -not- having to rely on a service provided by a third party.

[nontech]

Hey all, as part of GSoC 2022, I added this feature.
You can have a look at - PR 9291

[tyrasd]

The work on this which was started during last year's gscoc project (#9291) and has now finally been fully implemented in iD:

This works for jpegs (and in theory also pngs) which have a gps location metadata in their EXIF metadata. Georeferencing photos using a GPS trace would be nice to have in the future, but as it is possible to do that using external tools, it's not crucial functionality at the moment.

[joepie91]

Excellent news, thanks @nontech for implementing it!

[pedjas]

Great! Man, this is awesome!