Vishful thinking…

Using modifiers with parameters in batch files

Posted in Uncategorized by viswaug on September 25, 2007

I am fiddling around with some batch files for generating SandCastle documentation for the project I am working on. I hope to be blogging about SandCastle and its setup in a little while. Anyway, the batch takes parameters and needed to handle them appropriately when the user enters the parameters within quotes or not. Being very rusty on my batch commands knowledge, I scoured the Internet for help and came across this documentation that helped me out. It explains the use of modifiers with batch file parameters to get what you need. Here is the information about the modifiers below.

Using batch parameters

You can use batch parameters anywhere within a batch file to extract information about your environment settings.

 

Cmd.exe provides the batch parameter expansion variables %0 through %9. When you use batch parameters in a batch file, %0 is replaced by the batch file name, and %1 through %9 are replaced by the corresponding arguments that you type at the command line. To access arguments beyond %9, you need to use the shift command. The %* batch parameter is a wildcard reference to all the arguments, not including %0, that are passed to the batch file.

 

For example, to copy the contents from Folder1 to Folder2, where %1 is replaced by the value Folder1 and %2 is replaced by the value Folder2, type the following in a batch file called Mybatch.bat:

 

xcopy %1\*.* %2

 

To run the file, type:

mybatch.bat C:\folder1 D:\folder2

 

This has the same effect as typing the following in the batch file:

xcopy C:\folder1 \*.* D:\folder2 

You can also use modifiers with batch parameters. Modifiers use current drive and directory information to expand the batch parameter as a partial or complete file or directory name. To use a modifier, type the percent (%) character followed by a tilde (~) character, and then type the appropriate modifier (that is, %~modifier).

 

The following table lists the modifiers you can use in expansion.

Modifier Description

%~1

Expands %1 and removes any surrounding quotation marks (“”).

%~f1

Expands %1 to a fully qualified path name.

%~d1

Expands %1 to a drive letter.

%~p1

Expands %1 to a path.

%~n1

Expands %1 to a file name.

%~x1

Expands %1 to a file extension.

%~s1

Expanded path contains short names only.

%~a1

Expands %1 to file attributes.

%~t1

Expands %1 to date and time of file.

%~z1

Expands %1 to size of file.

%~$PATH:1

Searches the directories listed in the PATH environment variable and expands %1 to the fully qualified name of the first one found. If the environment variable name is not defined or the file is not found, this modifier expands to the empty string.

 

The following table lists possible combinations of modifiers and qualifiers that you can use to get compound results.

Modifier Description

%~dp1

Expands %1 to a drive letter and path.

%~nx1

Expands %1 to a file name and extension.

%~dp$PATH:1

Searches the directories listed in the PATH environment variable for %1 and expands to the drive letter and path of the first one found.

%~ftza1

Expands %1 to a dir-like output line.

 
Note

In the previous examples, you can replace %1 and PATH with other batch parameter values.

 

The %* modifier is a unique modifier that represents all arguments passed in a batch file. You cannot use this modifier in combination with the %~ modifier. The %~ syntax must be terminated by a valid argument value.

You cannot manipulate batch parameters in the same manner that you can manipulate environment variables. You cannot search and replace values or examine substrings. However, you can assign the parameter to an environment variable, and then manipulate the environment variable.

REST in the mainstream

Posted in Uncategorized by viswaug on September 25, 2007

In my last post I talked about REST services in GIS. If you are interested in digging deeper into REST, a whole bunch of information can be found here. But who is using REST data services out there? Well, both the two big software giants are. Both Google and Microsoft are offering their own style of REST protocols for accessing databases over HTTP. Google is offering Google Base and Microsoft is working on Astoria. Being a Microsoft guy, I have been playing around with Astoria and am excited about its possibilities. Microsoft is still actively working on Astoria and are currently inviting insight into its URL syntax style and security. Dare Obasanjo has a great blog post comparing the above two technologies.

Just to demonstrate the fact that you are actually using REST to access data from a database, click here to retreive data from a database using an Astoria REST service in XML format

http://astoria.sandbox.live.com/northwind/northwind.rse/Customers

Adding the ‘format’ query parameter to the URL retrieves the data in JSON format like shown below.

http://astoria.sandbox.live.com/northwind/northwind.rse/Customers?$format=json

Clicking on the above link will let you download the data seen previously in XML format in JSON format. If you want to view the downloaded JSON data, I would recommend using the JSONViewer.

Here is a real simple web page (just HTML and JavaScript) I created that talks to the Microsoft Astoria REST data service and retrieves data from a database in JSON format and the presentation of the data is almost the only thing handled in the web page. This kind of drives towards the separation of concerns strategy too which is great.

REST in GIS

Posted in Uncategorized by viswaug on September 25, 2007

REST services have been growing in popularity for quite a while now. REST has especially been a great fit for the web mapping world. A whole bunch of web map service providers out there are already using REST in their offering. The main use of REST in the online web mapping services has been around the access and delivery of cached map tiles. REST services just standardize the way in which map tiles are requested by clients, and the ways that servers describe their holdings. Or in other words, an URL containing information on the map center point, map scale, layer and the image height and width as query parameters maps directly to pre-cached map tiles sitting on the server. This also enables caching of the map tiles on the client side thus helping speed up the application and reduce bandwidth usage. ESRI realized the importance of REST in GIS and are offering their ArcWeb Services in REST. More information on REST access to ArcWeb services can be found here. Even OSGeo is working on a “Tile Map Service Specification“.

But there are not too many REST based vector data service. There is work being done in this area also and the demo found here illustrated how REST services can be utilized for vector data. The demo actually loads vector data using a REST service. The vector data is transferred around in the JSON format specifically the still under development GeoJSON format. The demo also allows users to update the database using a REST service. It is actually exciting to see all these technologies come together seamlessly.