Tag Info

Hot answers tagged

29

I think the stock/obvious answer would be to use a spatial database (PostGIS, Oracle, SDE, MSSQL Spatial, etc) in conjunction with a metadata server such as esri's GeoPortal or the open source GeoNetwork application, and overall I think this is generally the best solution. However, you'll likely always have a need for project-based snapshots / branches / ...


22

That convention goes back to the surveying industry; which has a point of beginning. So you start at a point in space, and the last point you reference is your closing point. This way you have a closed object. So to build a full COGO object you need to have a complete description of what is being described. Its more accurate than a assumed close.


14

Metadata is by far the most important issue here. If metadata answers whom, when, why, where it's an acceptable metadata record. Having work experience in large companies with just a few GIS users (around 30) we had major issues to control data, specially versions and permissions. One side of this can be solved with extensive documenting of data (metadata) ...


14

If you don't need third party support and don't forsee the need to query by type keeping them in the same table works just fine. Alternatively you could use an inheritance model as discussed in chapter 3 of PostGIS in Action. http://www.postgis.us/chapter_03 From an architecture perspective PostGIS doesn't really care if in a query multiple different ...


13

This will not be a cannonical answer but just some of my experiences. A real archivist can give you a fuller answer. PAPER: Paper is a tricky medium, whether you are storing maps or have a library of books. The problems of degeneration are compounded for maps because climate can not only causes the paper to degenerate but can also cause the paper to ...


11

The criteria for valid polygons are defined in the OGC's Simple Feature standards document* adhered to by the majority of GIS software and spatial databases. The reasons for requiring the start points and end points to match are likely to relate to the topological concept of a closed set. The rules for a valid polygon are: Polygons are topologically ...


8

I think Dropbox would be a good solution for you. It will automatically sync files within a certain directory. I think the limit for the free account is 2g, which sounds like it would work for you. If you use this I get a little extra space on my account :)


7

We have used a file system organized hierarchically by: - geographic extent (country or continent) - data provider, licensor - domain/dataset - date/version After that we have a policy to separate the source data (in the same format that was on whatever CD/DVD that we got from the provider) from any derived datasets that we produced within our company. The ...


6

It also makes many algorithms easier if you don't have to worry about wrapping round to the beginning of the polygon again.


6

This one really troubles me. I guess it's because I've seen too many CAD files with data all on one layer, differentiated only by color. What it comes down to is really a choice between organizing the data by structure, or by attribute. Given that choice, I would always go for organizing my data through data structure. For a start, when processing data ...


4

Interesting. I have no experience with this, but would recommend that you scan them all just in case something does happen! A high resolution scan can be reprinted in case of disaster, and is easy to store/backup in multiple locations.


3

As @JasonBirch said, version control is a huge issue. Also we've found that an appropriate workflow is hugely important. For example when we're collecting field data we tend to use staging databases where the field data can be QA'd before being merged into the master dataset. Depending on how much data needs to be QA'd this will always create some overhead ...


2

A co-worker in the same office? Do you use servers for anything? Just make a shared folder with only you two given access to read/write.


1

The different methods of storing rasters in ArcMap are a little confusing. If you have a Raster Catalog, the actual raster data may be stored in a different folder, not directly in the geodatabase. Raster datasets can be managed within or as links on file system Given the very different file sizes in this case, this "link" storage is more likely. ...


1

Concerning the hardware part: In our GIS cluster (http://gis.cri.fmach.it/cluster/) we have recently added 96TB based on low end consumer hardware, obviously selecting carefully the disks. The file system system is based on the open source storage software glusterFS which enables us to add new storage in future easily ("GlusterFS is an open source, ...


1

I can think of 4 main solutions: Store the data in a static, flat file. Probably GeoJSON or GML. Your maintainers could edit the file and upload updated copies. Given the simple "POI" type structure, you could probably put together a web based editor. Leaflet would be retrieving the entire dataset at once and rendering it. Put together a GeoJSON output ...


1

How often does your data change? If not often then I have previously held it as a .JS file, using the Esri JSON specification, then referenced the JS Module in my code to parse it into graphical features over the base map. so the data gets described as a json string "var flJson = " in the .js file. It's then referenced in the ESRI ArcGIS file like: ...


1

I would suggest you precalculate bounding-boxes for your road-segmensts and store them into a QuadTree structure. In the quadtree you only store the bounding-box and identifier for each roadsegment. You can then load the complete Quadtree into memory of your client and for each mouse-move query the quadtree what segments are within a given buffer-distance. ...


1

Map tile structures are structured identically to a quadtree, where the root tile has four sub-tiles, each of those has four sub-sub tiles, etc. There's a simple formula to get the path/tilename for the tile you need. (The link describes OpenStreetMap / Tilecache's naming scheme.) For the n nearest neighbors to a tile at zoom level y, maintain a list of ...


1

I have to agree with 'George' above that metadata should play a big role in managing geospatial data. Really with any digital data, metadata is key -- think of a photographer who tries to manage his digital photo files w/o proper metadata. Life gets so much easier if you tag things religiously, and have good software that can utilize the data. Now the ...


1

As the previous post mentions, spatial DB's and a metadata server are the usual setup. I think one key thing to remember is that 'one size does not fit all'. You'll end up with data that fits best in Oracle, file servers, SQL server, whatever. I've tried shoe-horning all data needs into one solution and it usually fails. Expect to use different solutions ...



Only top voted, non community-wiki answers of a minimum length are eligible