What Rupmaps Actually Does Before You Waste a Day on It
Rupmaps is a mapping and urban planning tool that lets you layer geospatial data, render custom maps, and push those outputs into planning workflows without stitching together five different programs. I say "usually works" because the first time I tried dropping a shapefile of zoning parcels onto a topographic basemap, the coordinate reference system was wrong and every feature ended up somewhere in the Atlantic. I spent forty minutes reprojecting to WGS 84 before anything clicked into place. The core loop is straightforward: import vector or raster data, style it, add basemap context, export or share. The thing most people miss is that Rupmaps isn't really a desktop GIS replacement. It's fast enough for quick visualizations and mid-stage reviews, but if you need topological editing or network analysis, you're still going to reach for something else. I learned that when a client asked me to do a watershed delineation inside Rupmaps and I couldn't find a pour point tool anywhere in the interface. Exported to QGIS, did it in twelve minutes, brought the result back. Where it actually earns its keep is in the review cycle. Instead of running around sending GeoTIFFs and shapefiles back and forth, you publish a Rupmaps link and stakeholders click through layered views. That alone cuts my feedback round-trip from three days to roughly a day, assuming the stakeholders don't send three separate emails asking for the same map at different scales.
Getting Started Without Losing Your Mind
First, check what file types your version supports before you spend an hour exporting from your existing pipeline. Some deployments of Rupmaps dropped CAD import support in a recent update and nobody mentioned it in the release notes. I caught that one the hard way when a municipal engineer sent me a DWG and every layer came through as blank geometry. Step one is setting up your workspace with a consistent CRS. If you're working on a US project, NAD 83 state planes are usually the right call, not Web Mercator. Web Mercator looks fine for presentation because it's what everyone expects, but it distorts area badly enough that any measurement you pull from it is wrong. I keep a preset profile saved for my region so I'm not second-guessing projections every session. Step two is getting your data in. Rupmaps handles GeoJSON, KML, Shapefile, GeoTIFF, and a few other formats natively. If you're bringing in data from a local government portal, expect to clean it first. Their attribute tables are almost always a mess—duplicate field names, missing values, codes that don't match any standard. I run through a quick normalize pass in a spreadsheet or a lightweight script before uploading, and it saves you from having to fix fifty attributes after the fact.
Step three is styling. The style editor in Rupmaps is decent but not where the time sink is. The time sink is making sure your symbology communicates clearly at the sizes it will actually be viewed at. A map meant for a PDF handout at 8.5 by 11 inches needs different stroke widths and label sizes than the same map displayed on a tablet in a public meeting. I keep two style presets for each project: print and screen. Switching between them takes about ten seconds and prevents two hours of rework later. Step four is publication. Rupmaps gives you a shareable link with optional access controls. Set the permissions properly. I've seen projects where someone shared a link with "view" access that still allowed data downloads, and then that link ended up on a public comment page. Not a disaster, but it means the assessor's office now has publicly accessible parcel data with ownership information attached, and that's a privacy headache you don't need.
Get the Full Details
The Stuff Nobody Tells You About Using It Day to Day
The performance drops off sharply once you go past about twenty layers with more than fifty thousand features each. I was pushing a full county road network plus parcel data plus floodplain layers plus aerial imagery and the map started taking four or five seconds just to pan. The workaround was simplifying the parcel layer with a generalization filter before loading it in, dropping it from two hundred thousand features to about forty thousand while keeping it legible at the intended display scale. The tradeoff is you lose the ability to click individual parcels, but most people looking at the map aren't trying to do that anyway. Another thing that trips people up is the versioning. Rupmaps saves incremental updates automatically, but there's no branching. If you make a styling change and then decide you want to go back to how it looked three revisions ago, you're stuck digging through your project history. I keep a manual backup folder on my local drive where I save a copy of the project file every time I hit a milestone. Takes thirty seconds and has saved me twice already. The export options are adequate but limited. PNG and PDF are solid. GeoTIFF export works for rasters. But if you need to hand off clean vector data to a consultant or a city planner, you're better off exporting as GeoJSON or Shapefile directly rather than trying to extract data from a rendered image. I made the mistake of sending a PNG to a surveyor once and he spent an hour digitizing roads off the screenshot instead of just using the actual shapefile. Don't do that.
When Rupmaps Is the Wrong Call
If your project requires advanced spatial analysis—network routing, suitable site modeling with weighted overlay, change detection across time series—Rupmaps isn't built for that. It's a visualization and collaboration tool, not an analytical engine. I use it alongside QGIS and occasionally ArcGIS Pro depending on what the deliverable needs. The workflow is: do the heavy lifting in the proper GIS software, bring the cleaned result into Rupmaps for stakeholder review, and iterate from there. There's also the dependency issue. Rupmaps is cloud-hosted, which means your project is only as reliable as your internet connection and their uptime. I had a project deadline where their service was down for six hours on a Friday afternoon and I couldn't access the data I needed to finalize a presentation. Having a local copy of everything in that situation would have been nice. Keep your source files backed up locally at all times. The cost structure is another practical concern. Free tiers exist but they're thin—limited layers, limited storage, watermarks on exports. Once you move into paid territory, the pricing scales with seats and storage, which adds up fast on multi-stakeholder projects. I've found that negotiating an annual plan instead of month-to-month gets you a meaningful discount, but you need to know you're going to stick with it. Downgrading mid-project means losing access to your published maps and having to rebuild sharing links from scratch.
A Practical Workflow That Actually Holds Up
Here's how I run a typical project now. I start with raw data in its native format, clean and reproject it in QGIS, run any analysis there, then bring the final datasets into Rupmaps. I set up both print and screen style presets. I publish to a restricted link for internal review first, collect feedback in one pass rather than letting it drag out, then publish the final version with public access if needed. I save a local copy of the Rupmaps project file and all supporting data to a shared drive before I close it out. This usually gets a project from raw data to published map in two to three business days for a standard urban planning deliverable, compared to four or five days when I was doing it the long way. The tool works well enough that I use it regularly, but it's not a silver bullet. Treat it like a piece of equipment that's good at some jobs and useless at others, and you'll save yourself a lot of frustration.
