Vidhun,
This looks impressive. The interface for uploading photos is a great place to start improving MapKnitter. The current system requires that photos be uploaded one at a time with a subsequent wait of 20 to 60 seconds during which the user can not interact with the map in progress. The first approach to improving this might be to allow upload of five or ten photos at a time so all the waiting is done in advance. Either "select files" or "drag and drop" would work fine. Drag and drop is ubiquitous so probably easy to implement. The next issue is what to do with the photos after they are uploaded. Should they be displayed on top of one another in the middle of the map? Should they be aligned in a row off to the side? Should they be displayed as icons, any one of which can be opened and displayed as the user needs them?

EXIF location data in the photos could be used to place them on the map, but this has shortcomings:

1. Very few photos ever uploaded to MapKnitter have GPS data in the EXIF header.
2. GPS data will come from the camera in the air and not necessarily account for tilt and subsequent displacement of the photo's location on the ground. This location could be calculated, but that requires data about camera altitude, orientation, tilt, and local topography. GPS data on altitude is never very good, not all GPS systems record orientation and tilt, and modeling ground topography is probably beyond the scope of this project.
3. If the photos are simply placed at the lat long coordinates of the camera, they should be rotated properly, using orientation data (NSEW, which is much rarer than lat long data). If they are not rotated properly, the advantage to the user might be minimal.
4. Most maps at MapKnitter are just 5 to 15 photos of a relatively small area, taken by a camera that moved horizontally through an even smaller area. So automatically geolocating the photos for most MapKnitter maps will result in all the photos being placed in pretty much the same place anyway. It is not clear that this would be much help to the user.
5. In some cases of homogeneous ground surface when there are hundreds of photos, automatically placing the photos can be useful. But in most cases it is obvious and easy to rotate a photo into the correct orientation and place it. This is one of the fun parts of MapKnitting.

Assuming a set of photos had good lat, long, tilt, orientation, and altitude data, and the ground underneath was perfectly flat, is it a reasonable summer project to create from scratch a system to place the photos on a map? If such a system was created, would it be easy to also stretch the photo to account for camera tilt?

Some questions for the MapKnitter community at large:

• Do such systems already exist?
• Do your aerial photos include lat, long, altitude, tilt, and orientation?
• Would you invest in the required equipment to record these data if it was used by MapKnitter?
• Are there other improvements to MapKnitter that would be more useful to typical users?

Chris

Chris,

Drag and drop is ubiquitous so probably easy to implement. The next issue is what to do with the photos after they are uploaded. Should they be displayed on top of one another in the middle of the map? Should they be aligned in a row off to the side? Should they be displayed as icons, any one of which can be opened and displayed as the user needs them?

This would be a great addition to the image upload interface, my approach would be to upload multiple images and list them off-map. The user can then select photo's to display them on map.
Again my initial proposal was to take only the auto georeferencing project and basic enhancement of upload interface. So adding more features would just be a failure to complete in the summer time. I will think over this and update proposal accordingly or maybe I can work if I complete my project early.

EXIF location data in the photos could be used to place them on the map, but this has shortcomings:

I understand this, but as I mentioned my project idea is to guess the image location on map as much as possible using available EXIF data, so if no data is present the user can fallback to regular approach.

Very few photos ever uploaded to MapKnitter have GPS data in the EXIF header.

Users who use Mapknitter frequently will find the current process painstaking. Due to this, some kind of tutorial or steps on ensuring GPS data can be advised for the users.

Most android devices support GPS(lat, long, alt). Probably an android app for taking images?

I think Iphone photos has GPS in their EXIF(not sure about this, anyone using Iphone here?). Iphone sample data

GPS data will come from the camera in the air and not necessarily account for tilt and subsequent displacement of the photo's location on the ground.

As mentioned earlier, the idea is to position the image approximately using the EXIF data. The position need not be final, therefore the user can correct them as required. This is better than just placing the photo at an unreasonable position on the map.

This is one of the fun parts of MapKnitting.

Oh, I never gave thought to the fun part in knitting, maybe an option to turn off auto georeferencing?

it a reasonable summer project to create from scratch a system to place the photos on a map? That would be great thing, should probably note this and give it some thought.

Thanks for the great points and suggestions, will review your tips, questions and update the proposal accordingly.

my approach would be to upload multiple images and list them off-map. The user can then select photos to display them on map.

I agree, this is a good way to do it. If the user wanted to upload a few more photos, could it happen in the background?

Does anyone have a small set of photos with GPS data that have been made into a map by hand? It would be really interesting to see the relationship between the photos' final lat long centroid on the map and the GPS coordinates in the jpg files. How strong does this relationship have to be to make this project useful?

Most android devices support GPS (lat, long, alt).

Some day, more people will be using smartphones to take aerial photos, but today, a $40 (ebay) Canon Powershot takes much better photos (bigger sensor, better lens, better control) and is much easier to convert to infrared. Collecting GPS data for these photos generally requires additional (and more expensive) hardware, so it is not done very much, and we don't know much about the quality of the GPS data or how it relates to the ground position of the photos.

Some day, more people will be using smartphones to take aerial photos.

Is there some data on the number of images on mapknitter that contain GPS data. This way we can ensure that the project will prove useful.

Hi! just a few thoughts to add:

• For this project, you may begin to overlap with this other GSoC proposal a bit -- not the same code or functions, but you'll have to coordinate: http://publiclab.org/notes/anishshah101/03-08-2014/gsoc-2014-proposal-porting-imagedistortion-class-in-the-mapknitter-interface-to-leaflet-js
• I think the best way to approach this coordination may be to skip making separate "maps" for now, and just focus on people uploading images one by one.
  • So, the map would just show all images by that user, or (with a toggle to change this) all recent images by this user, or all images from all users for this region.
  • Exporting a map would involve dragging to select a group of images which you wish to export, rather than having lots of separate named maps
  • These last few distinctions may not be that important for your project
• the upload interface, once you're done uploading an image, would drop you back into the map. If it's simple enough, you could put it on both the front page of the website (so people can begin making a map really quickly) and within the map editor interface. But the editor will be changing if the above project by Anish goes forward, so keep your code clean and portable.
• the upload interface could be modeled on http://publiclab.org/post
• finally, re: having fun, the auto-placement will basically never be good enough to make some manual adjustment unnecessary.

Great start to your proposal!

For this project, you may begin to overlap with this other GSoC proposal a bit.

I've read the proposal and also did some digging, from what I understand the approach is to move the image distortion class to leaflet.js. Parts of my project relies on using image distortion, probably work with the initial code and make changes later on once Anish has completed his work (portable)?

I think the best way to approach this coordination may be to skip making separate "maps" for now

Do you mean "multiple image" feature? As I mentioned earlier my approach was to list all currently uploaded images off map allowing the user to select what to load on map. Would it affect the coordination if we allowed user to select one image to knit at a time from the list of uploaded ones? Since you mentioned I am confused as to how Anish's project will make changes to editor, apart from porting is there any visual level mods that would be made?

So, the map would just show all images by that user, or (with a toggle to change this) all recent images by this user, or all images from all users for this region.

This would be awesome. Will reflect this in proposal.

the auto-placement will basically never be good enough to make some manual adjustment

True. So any possible reason that user would require for toggling auto-placement? Probably the GPS data doesn't make sense. Thoughts?

I'll be working on modelling the interface. Will have note the list of features that will be required on the interface.

Vidun - i'm going to paste in some questions and thoughts here related to how your project overlaps with Anish's proposal. Some of these are for Anish, some for you, but both projects will be related and it'll be important to figure out with Anish where your work fits together, and how you'll each ensure that your work will function even if the other's does not yet work. And how they'll work together if both succeed.

• Upload interface is a partial, which can be included in various places
• Recent images also
• Separate JS code files
• Leaflet work contained in Leaflet plugin
• Could upload function first be integrated with current system, but clearly mark where it would begin to work with Leaflet system once that's done? Via agreed-upon callback and/or constructor method?
• Upload of each image to server completes with a callback like "imageUploaded()" which the Leaflet system can overwrite when it's ready?
• Leaflet system, if completed, will need a) transparency, b) outlining, c) locking
• new Bootstrap interface overhaul for MapKnitter could be part of Upload project.

Oops forgot to link to his project: http://publiclab.org/notes/anishshah101/03-08-2014/gsoc-2014-proposal-porting-imagedistortion-class-in-the-mapknitter-interface-to-leaflet-js

how Anish's project will make changes to editor, apart from porting is there any visual level mods that would be made?

We've discussed his re-implementing the buttons and such in Bootstrap, which would be much simpler. Your work might intersect his if you contained your code to a Rails partial (read up on this... it's like a reusable template fragment) which could be included in the old version or Anish's new version of the editor. Or you could have faith that Anish will finish his work, and just focus on an image uploader/gallery/placement tool which instantiates a new in-editor image from a list of uploaded images (as you said) and hands off the relevant data to Anish's code for the user to begin manipulating.

For the auto-placement, you could pass "suggested" placement along with the constructor to Anish's code to instantiate and display the image.

any possible reason that user would require for toggling auto-placement?

Perhaps at the moment you upload, it could have a checkbox (default checked) that says "attempt to auto-place". Or it could just try, and if it fails, it could briefly show an unobtrusive message that it couldn't find a match. If you right-click the image, or long-click it, maybe it could offer to try again.

I've been busy these days with exams.

As said I will have to contact Anish, probably look into making the upload feature as a start to begin with the coordination.

About the toggling, I've been weighing the pros and to me I don't think this feature will do any good. I'm not sure of this but can be decided later. Depending on the user corrections, I was also thinking it would be better to make the complete tagging inherently with EXIF(modify GPS corrections by user writing to the image EXIF).

I found a map with GPS coordinates in the EXIF data: https://mapknitter.org/map/view/cuas-balloon-mapping