This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Mike, re: > I know the MAKEMAP command does not support GeoJSON, but could it? Well, it is only software after all, so anything is possible *with enough work*. I would guess that support would have to be added for Json/GeoJson to the package, and then MAKEMAP or something like it would need to be updated/created. Both of these things might entail a moderate to a lot of work. re: > In my ongoing effort to make more work for myself, I'm trying to think of > ways I could update some of the McIDAS maps from current GIS > data, preferably from a standard GIS format. I know there's no support for > Shapefiles, and afaik the only way to import & create maps is with the > MAKEMAP command which is rather limited. I seem to recall that GEMPAK had the ability to convert shapefiles to ASCII, and, if the ASCII format is "correct" (I can't detail what that means), MAKEMAP could be used to make a McIDAS OUTline file. re: > The help output for MAKEMAP shows only three formats are supported, and > none of them are a standard GIS format. Correct. re: > But these formats look like > relatively simple tabular strings which (in theory) would be > fairly straightforward to parse. Yes, exactly. re: > I took a glance at MAKEMAP.pgm, and while > Fortran is quite literally a foreign language to me the code doesn't seem > terribly complicated. It is not. Aside: I like classical Fortran because I know all of the statements, and I can spell them correctly ;-) re: > While I think we can all agree adding support for > Shapefiles would be no simple task, I'm wondering if adding support for > GeoJSON would? I have no idea, since I have never thought about this, sorry. re: > In my mind it would boil down to string parsing, which is > essentially what MAKEMAP is doing now. I'm including a sample road below > and I'm interested to hear your thoughts on how much of a project it would > be to add this format to MAKEMAP. My first approach would be to write a script that parses the Json listing and outputs a textual format that MAKEMAP understands or could be made to understand with as little effort as possible. re: > The other idea I had was to write a bit of Python code to convert GIS data > to the either GEM or MCI ASCII formats, which from there MAKEMAP should be > able to make sense of it. But I feel like adding this support directly to > MAKEMAP would be more ideal. It could open the door to substantial (and > IMO much needed) mapping updates. You are correct, of course, but the question comes down to the level of effort that is needed. I'll send a note to the MUG folks at SSEC to see what they use to create new versions of MAP OUTline files. It might be the case that they already have a non-McIDAS routine that can be used directly. re: > { > "type": "FeatureCollection", > "name": "roadtest", > "crs": { "type": "name", "properties": { "name": > "urn:ogc:def:crs:OGC:1.3:CRS84" } }, > "features": [ > { "type": "Feature", "properties": { }, "geometry": { "type": > "MultiLineString", "coordinates": [ [ [ -87.743195552223071, > 41.567600840555166 ], [ -87.795293386939179, 41.548498301159263 ], [ > -87.878649922484939, 41.553708084630877 ], [ -87.911645217805145, > 41.550234895649801 ], [ -87.967216241502328, 41.534605545234967 ], [ > -88.000211536822519, 41.515503005839065 ], [ -88.126982934631712, > 41.513766411348527 ], [ -88.196446714253184, 41.487717493990473 ] ] ] } } > ] > } This is easy enough to parse in a shell script. My favorite shell script a few years back was Tcl, and it is likely that someone has written a Json "adapter" for Tcl. Just a random thought... Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: EKV-159239 Department: Support McIDAS Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.