Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quality Checking your Spatial Data - review (chapter 28, Hassan Sabirin) #114

Open
Rachael-E opened this issue Jun 14, 2020 · 0 comments
Open
Labels

Comments

@Rachael-E
Copy link

This chapter is an important one for reminding the reader the importance of checking your co-ordinate system. It's also helpful in reminding the reader the number of small discrete ways these errors can creep into your database and is an important chapter to have.

It is 837 words long: I am unsure of a word limit for this book but if it needed reducing some of the introductory context setting could be reduced to lead the user more directly to warnings about incorrect co-ordinate systems. My suggestions below may add more code lines and so some text may have to be reduced.

Main review points:

  • It would benefit from copy-editing and formatting

  • I am unsure of the intended audience for the book (in terms of experience), but some of the acronyms and steps in the code comments could be explained more fully (e.g. what does "srs" mean and at the end of code block 2, give some examples of what code the author has in mind).

  • "The next thing to do is to adapt this measurement method in a while or for loop and run it across all rows in your well header database (perhaps by using ODBC/SQL calls)."

    For the above section from the chapter, it would be really helpful to have an example code block to show what the author intends - having a start to finish workflow is so helpful for developers new to this kind of thing.

  • I didn't have the contents of the table to refer to for this review but I ran the code in a Jupyter notebook. There are a number of syntax errors which I have attempted to rectify below but these should be double checked by the author.

    In addition to this, in Code Block 1 as shown below, I got some Future warning and syntax deprecation warnings: if the author is able to update the code calls to the updated functionality that would be beneficial.

Code Block 1: suggested syntax corrections

import pyproj

#init srs
w84UTM50N_srs = pyproj.Proj( "+init=EPSG:32650" ) 

#Without preserve_units=True, all results will be returned in meter
TimbBRSO_ft_srs = pyproj.Proj( "+init=EPSG:29872", preserve_units=True )

# these are original/stored coordinates in Timbalai BRSO(ft)
long = 114.0
lat = 5.0
x = 1900000.0
y = 2050000.0

# and this is WGS84 UTM 50N coordinate
W84_x = 278000.0
W84_y = 626000.0

# Section A – projection and unprojection
# ‘c_’ indicates calculated values
(c_x, c_y) = TimbBRSO_ft_srs (long, lat)		# Timbalai BRSO geographic to projected coordinate
(c_long, c_lat) = TimbBRSO_ft_srs (x,y, inverse=True)	# Timbalai BRSO projected to geographic coordinate

#Section B - transformation between different datums/projection - here from WGS84 50N to Timbalai BRSO(ft) 
(c_29872_x, c_29872_y) = pyproj.transform(w84UTM50N_srs, TimbBRSO_ft_srs,  W84_x, W84_y)
# and the other way around
(c_32650_x, c_32650_y) = pyproj.transform(TimbBRSO_ft_srs , w84UTM50N_srs ,  x, y)

Code Block 2: suggested syntax corrections

#Here we calculate the abs difference between stored and calculated values.
#Refer to variables defined in Section A
abs_diff_x = abs(c_x - x)  # calculate absolute difference
abs_diff_y = abs(c_y - y)

# You can also calculate offset: use Pythagoras method sqrt(dX*dX + dY*dY) and then magnitude: log10(offset)
# Insert your own code here to do something when the difference in values exceed a certain value or magnitude
@mycarta mycarta added the review label Jun 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants