Revision d258ab27-6be0-4991-b102-d479bd63c6ce - Geographic Information Systems Stack Exchange

Reading back over your question, I think your proposal to *reproject each point while creating the SHP using pySHP* is the most reasonable considering the path you've already started down. (Although, as stated in the comments, [this is not how I would have approached such a project][1]..)

To do this, you'll need a system to keep your classifier/shapefile-writer oriented relative to the original TIFF's X/Y values as it moves through your JPEG tiles.

If your JPEGs are fixed dimensions, like 256x256, 512x512 ..1024x1024, etc, then you should be able to systematically know each file's specific offset as you move away from the source TIFF's origin. Hopefully your tile naming scheme let's you know each tile's horizontal *as well as* it's vertical position within the original TIFF. 

For example, if I were doing this your way, my JPEG naming/numbering scheme would start at 0 moving left-to-right/top-to-bottom ..I'm actually still contemplating this. But this would mean `'JPEG_0_0'` would be top-left, then, moving left, we'd have `'JPEG_1_0'`, `'JPEG_2_0'`. Then, with the next row of JPEG tiles, we'd have `'JPEG_0_1'`, then `'JPEG_1_1'`, `'JPEG_2_1'`, etc. Hopefully that scheme makes sense.

We'd also need the pixel size constant of our original TIFF. Since the TIFF is in EPSG 4326, this means your pixel size is *PROBABLY* expressed in degree units. This is the hard part.. and [getting it correct][2] is potentially the most difficult chore of your approach. (See below † for more thoughts on this.)

For the sake of attaching some numbers to visualize this, I downloaded a 30 centimeter QuickBird image of Boston, MA. It arrived projected in UTM 19N, and I reprojected it to EPSG 4326. This is explained in greater detail, below. But if we treat this image like I'm suggesting you treat yours, we have a TIFF with origin at `Origin = (-71.064739360616358,42.308502361172913)` and a pixel size of `Pixel Size = (0.000003227844478,-0.000003227844478)`. (Note the `-` applied to the Y-axis.) Now for pretend, let's apply this image's origin/pixel size to a hypothetical JPEG tile falling in the third column, and the third row of your mosaic.. and within that tile, perhaps column 17 row 23. Remember the tile-naming structure is 0-based, so that would make it `JPEG_2_2`, col 17, row 23. With those givens, *I THINK* we get a conversion equation like this..

    TIFF_originX        + (((JPEG_name_X * JPEG_width) * pixel_size_X) + (JPEG_columnX * pixel_size_X))
    -71.064739360616358 + (((2 * 1024) * 0.000003227844478) + (17 * 0.000003227844478))
    X_Coord = −71.058073862

and..

    TIFF_originY       + (((JPEG_name_Y * JPEG_height) * pixel_size_Y) + (JPEG_rowY * pixel_size_Y))
    42.308502361172913 + (((2 * 1024) * -0.000003227844478) + (23 * -0.000003227844478))
    Y_Coord = 42.301817495

The JPEG tile size I used of 1024px² corresponds to about 3.58 meters² when it's translated to more pedestrian units. (Your tiles are probably much larger. Unfortunately I didn't think about this—at all—when I started this exercise.)  And I can use this information to do a "reality check" on the coordinate differences we calculated above. I see the difference in those units lands about where I would expect ..7.37 meters toward the prime meridian (East) and about 7.44 meters toward the equator (South), a little more than to tiles worth from the origin in each direction.

So *I THINK* this is how you might be able to resolve your coordinates. I'd certainly be interested in knowing if it works! Also, I further encourage you to keep your question open for a little while to encourage additional answers, or to potentially encourage others to check my work. ..of course, the best check of this approach will be to try it and report back on the results. You may want to continue reading, below, on the topic of your raster cell size. I'm sure I'm providing a very imperfect treatment of it, but it's important to realize that analyzing rasters in EPSG 4326 is not ideal. This has much to do with the fact that the Earth is not exactly a perfect sphere—among other things, it's a little squished north to south. There's a little more to it, but hopefully this is useful enough to get you rolling.

**†. Getting your source TIFF cell size**

**Getting your TIFF cell size from GDALINFO**

If you haven't done this already, I recommend installing GDAL, even if you only use it for this one purpose. If you don't have it yet, Google "Install GDAL on %OPERATING_SYSTEM%" and you should find an easy tutorial—it's easiest on Ubuntu Linux. 

For the purpose of simulating how you'd get your cell size from `gdalinfo`, I [downloaded a 30 centimenter resolution QuickBird image][3], which arrived projected in EPSG 32619, i.e. UTM 19N. Next, I reprojected it to EPSG 4326 using [gdalwarp][4], like this (you won't need to do this, but I did to be true as possible to your situation)..

    # Warp the original TIFF to EPSG 4326 using gdalwarp..
    gdalwarp -t_srs EPSG:4326 /home/elijah/Boston-QB/source.TIF boston-qb-4326.tif

Next I used [gdalinfo][5] to look at some of the projected raster file details. This is the step you would adapt..

    # Use gdalinfo to get raster details, specifically pixel size..
    gdalinfo boston-qb-4326.tif

According to `gdalinfo` my 30 centimeter raster of somewhere in Boston, MA, has a cellsize, expressed in degrees, (highlighted in the image) of..

    Pixel Size = (0.000003227844478,-0.000003227844478)

Realize that calculating degrees-to-meters is sloshy. But if we somewhat recklessly reduce it to [1 degree = about 111,000 meters][6], then we do..

    (meters in a degree   x   pixel size)
    111000                *   0.000003227844478

We get an approximate measure of 0.358290737 meters. After all the monkey-wrenching, once it was warped to EPSG 4326, our image of Boston has a slightly larger cell size. Having some awareness of this is important. But that means (if I'm understanding this correctly, myself) that in EPSG 4326, if we know our source TIFF's upper left coordinate, we should be able to add our pixel size (`+ 0.000003227844478`) to the upper left value, once for each cell moving left-to-right, up-to-down.

[![enter image description here][7]][7]

**Optional—Getting your TIFF cell size like a cowboy..**

As a loose alternative, you might try opening your source tiff in QGIS (make sure it stays in EPSG 4326!) and zoom in REALLY DEEP on your TIFF, until you see the individual cells, then measure one of your cells with the measuring tool. This will give you a good "ballpark" value of your cell size. And speaking of ballparks, here is an example of me doing this, zoomed in closely to the home plate in some random baseball field I noticed in the 30 centimeter QuickBird image I reprojected to EPSG 4326 in the previous step..

Again, I already knew this image has a resolution of 30 centimeters. Yet when I measure it with the tool, as you can see I got 0.356 meters. This approach is very sensitive to your mouse movements and not trustworthy! You can imagine how being wrong just a little bit will become increasingly exaggerated as you move through a project. So you won't want to rely on this approach to get your cell size constant, but you *can* use this approach to do a reality check on any cell size you establish using other means.

Here's the ballpark..

[![enter image description here][8]][8]

And if we zoom in close, we get a pixel size of 0.356 meters. 

Then if we divide that value by 111,000 (meters in a degree, appx), we end up back-calculating our source raster's pixel size to `0.000003207` ..which is near to what GDAL says it is, above. Of course, this value is derived, where as the GDAL value is a declared constant; the latter is the definitive value that should be used.

[![enter image description here][9]][9]




  [1]: https://gis.stackexchange.com/questions/367347/how-to-reproject-point-if-i-only-have-the-source-tiff-extent?noredirect=1#comment601417_367347
  [2]: https://gis.stackexchange.com/a/334054
  [3]: https://apollomapping.com/quickbird-satellite-imagery
  [4]: https://gdal.org/programs/gdalwarp.html
  [5]: https://gdal.org/programs/gdalinfo.html
  [6]: https://www.usna.edu/Users/oceano/pguth/md_help/html/approx_equivalents.htm
  [7]: https://i.sstatic.net/C1CAW.png
  [8]: https://i.sstatic.net/1J7Xv.png
  [9]: https://i.sstatic.net/mfiE8.png