Flutterby™! : Screencaps 2004-09-29 21:15:14.402045+00

Screencaps

2004-09-29 21:15:14.402045+00 by Dan Lyke 7 comments

I'm now getting to the point where I have to drop back and do some graphic design work, but my photo manager is progressing. You can see the map view, with images laid out over a topo of San Francisco, and a detail view which shows off in garish primary colors the hypertext description editing, all subjects then become cross referenceable in subject views. For sticklers, some of the lat/lon positions are wrong because my first pass at placing things was simple keyword searching.

Wow. the map view is pretty sweet. I'm doing some 'management/sorting' stuff to my PHP/Web based photo album, but nothing like this.

meta -- The sidebar on the side is showing 1 comment for this entry, but the meta on the left of the entry shows 0 comments. strange.

What projection are you using for your map view and where did you get your basemap?

If you can give me the projection, extent and format of the basemap, I can create a custom one for you...

BTW, once I get caught up after my 3-month hiatus, I'm going to put some of my pictures from my trip on my ArcIMS server. I'll try to document the architecture of ArcIMS at the same time so you can see the difference between an application like this and a "real" GIS implementation.

#Comment Re: made: 2004-09-30 20:01:48.849074+00 by: Dan Lyke [edit history]

The base map was downloaded as a huge TIFF from the USGS, the projection is linear interpolation from reference points that the app lets you place on the map. In this case I put one on each corner and one in the center [edit: Of each of the horizontal edges]. In the previous Perl

version I took the outlines from the census bureau state outlines and got almost pixel perfect match-ups on this map and others, and having arbitary points on the projection allows me to use things like tourist maps as backgrounds, take a picture of the park brochure, slap some reference points at known intersections, and you've got your map.

I'm also thinking an exponential interpolation might be better (could be cleaner code), but haven't bothered because the linear one works so far.

The locations were gleaned from a Census Bureau ZIP code database that I'm fairly sure I'm not using correctly, partially because one of the San Francisco

entries is way out by the Farallons, but it lets me get things on the right map and I can then position them manually. And those little checkboxes on the upper right are so that you can put them in a particular place on this map for presentation, dragging them to a good representative place,without the mousing mucking about with lattitude and longitude.

Yikes! I can see the value of linear interpolation for large-scale maps, like a photo of a park map, but as your scale gets smaller (like your map of the SF Bay) you'll need something better. And heaven help you if you try to show all of California at once!

Actually, I can make maps for you that would work for simple linear interpolation, even smaller scales like the entire state or even the US. The shape will look a little funny... A little stretched horizontally at the top...

Are you georeferencing the images based on ZIP code? That gets way squirrelly in areas with low population. Did you capture Long and Lat? Using Unprojected Long and Lat allows you to treat Long and Lat as X,Y.

Those long and lat came from ZIP codes, and as I said the data set I'm pulling from is shaky at best, because one of the long/lat pairs for SF is actually out by the Farallons, so I rather suspect that some of these points are tagged for labeling, not just for position. But it gets things on the right map. I can't treat lon/lat as x/y because the map isn't linear or aligned.

But even looking at this map, which is 7680x5612 including the borders covering -124 to -122 degrees longitude and 37 to 38 degrees lattitude, linear interpolation with 6 reference points gives a max error of around 6 pixels. Hit the 15 degree crossings with reference points and given that a good many of the lines on the drawing are 3 pixels wide and there's probably at least a two pixel misalignment between colors, we're down well below the limits of resolution of the map.

At some point I took one of these maps with a fairly simple 6 point reference and the Census county outline data, and it was pretty close to pixel perfect. I was going to work on better schemes, but that told me I needed to punt worrying about alignment for a while. I think if I'm seeing worse results in Python

than I did with Perl

it's because I need to use doubles rather than floats.

The original TIFF also had enough tag data that I didn't understand at the time that I'm sure I could autogenerate enough reference points to get this scheme to work to the pixel even if I didn't want to be smarter about different projections.

After a bit more housecleaning and usability stuff, I need to grap GPS tracks and synch them to EXIF camera times so that I can have 3 meter or so positional accuracy.

Ah, now that I see your image I see your notions about larger scales. The error on larger scales will be the max distance between a straight line between reference points placed on the same lattitude and the curve of the projected lattitude line. Do you have a simple pointer to the arithmetic that normally lies behind the common projections? Is it simple polar coordinates with the center way the hell above the paper?