21kb of gzipped JS code, it still has all the features you will ever need for your web mapping needs,
while providing a fast, smooth, pleasant user experience.
It is built from the ground up to work efficiently and smoothly on both desktop and mobile platforms like
iOS and Android, utilizing cutting-edge technologies included in HTML5 and CSS3. The focus is on usability,
performance, small size, A-grade browser support, flexibility and an easy-to-use API. The OOP-based code
of the library is designed to be modular, extensible and very easy to understand.
Incorporates concepts from ISO 19115, 19115-1, 19119, FGDC, 19110, and FRBR along with
some additional stuff like recording the lineage of the metadata record,
which is useful in a metadata harvesting federated system. Builds on
the conceputal model presented in a previous discussion here.
This is an experiment to see what it would look like, trying to bring in just about any metadata property from those various specs... Lot's of comments in line.
I spent some time researching this issue in the context of some other projects I've been following or involved in (OWS context Standards Working Group, energy industry ISO19115 metadata profile, and USGS CGI Web Application Integration Framework group). I would like to see this considered in a larger context to come up with a solution that can be used in these various contexts, because it's essentially the same problem. Here' s the gist of the proposal for link attributes outlined in the attached doc:
href -- the link URL
type -- MIME type of response. Specifies encoding and optionally the native software application environment. We're sort of stuck with this because of existing usage. One big question is how much of serviceType, puprpose, and outputScheme it makes sense to conflate in the MIME type. I favor keeping the MIME type limited to low-level file formatting--to answer the question 'what software can read this file in a useful way' Understanding the content and intention of a document or the interface to a service should be specified by separate properties.
This is a scenario for a generic metadata edit tool,
intended for brainstorming development of a community component that is
transportable and reusable. Use of a standardized tool for editing metadata
will reduce the cost of entry into the metadata game by reducing training and
increasing productivity, and should help improve the quality and consistency of
metadata. The attached word document has the same text. Please add any other features or requirements that would be useful.
We can all agree that search engines like Google have really defined the way that we search for information on the internet. So the question is, why aren't we using Google to search for our geologic datasets? Do we have to do all that formal, structured metadata? What the hell is CSW anyways?
It acts as a proxy server. You ask it for http://metadata.usgin.org/record/a386a4ba-e892-11e0-9e4a-0024e880c1d2, and it reads that file identifier out and issues a CSW GetRecordByID request to a CSW server. The response to that CSW request is an XML document, and nobody (including Google) really cares about that, so the server formats the record as a very simple HTML page.
We write metadata so that we can search through it to find datasets we're interested in using for some purpose. I've recently started building a map-centric user-interface for doing this that has highlighted some simple functional requirements that metadata should meet in order to be helpful in accomplishing the task.
What I've done here is essentially listed the conceptual elements that seem neccessary in order to make a functional user-interface for searching. This has nothing to do with metadata syntax, just with metadata concepts.
FYI-- this is a draft profile against the upcoming revision of
ISO19115 for metadata, scoped to energy industry, but the scope overlaps
requirements for USGIN (I've been very active in developing profile and looked
after that). Please have a look at the docs if you're interested in metadata.
Given the standards process time lines, it probably won't directly impact us
until next year.
I gave two presentations at the ESRI User conference this year. One was geared mostly towards what we do with metadata in our systems, while the other was more of a broad overview of USGIN and a little bit of NGDS progress report.
Imagine that you collected geographic data in one schema and you want to provide it in some other schema. For many of us, this only happens pretty much all of the time.
For example, maybe your organization has an enterprise database which stores all the information that you have about recent, active faults. Now you want to provide that data as a WFS service with fields that conform to the ActiveFaults template being used by the AASG Geothermal Data System. Perhaps you store all your geologic map data in such a database and you want to convert it into FeatureClasses that fit into NCGMP09-style geodatabases.
Here's a nice way to convert your data formats in such a way that you only have to do it once. You can continue to make changes to your data just like you always have, and there will always be a featureclass hanging out there in the new schema which conveys the most up-to-date information that you have. The pre-requisites are:
A commonly overlooked step in the configuration of an ArcGIS Server is that you need to tell the server what its name is to the outside world. You see, on an internal network your computers might have names. As geologists we prefer names like "Eclogite", "Kyanite", "Harzburgite", etc... However, on the internet computers generally have more complicated names. These names are things like "services.azgs.az.gov" or "www.google.com" or "lab.usgin.org".
By default, your ArcGIS Server knows what the computer's internal name is. However, once you want to share your services with people outside that local network, you need to tell the ArcGIS Server how those other people will find it. You do this by editing a file called "rest.config". If you installed IIS and ArcGIS Server in all the default locations, you'll find this file at C:\inetpub\wwwroot\ArcGIS\rest\rest.config.
Look through the file and find all the URLs in it. Make sure that instead of using the computer's internal name, those URLs use the computers external name.
There could be a number of reasons why you'd like to use a database view as a backend for a WFS. Perhaps your data is split across multiple tables and updated regularly. Perhaps the data is in a table without an explicit ESRI-style SHAPE field. That's the case in this example, where the geometry information is stored in a table as UTM coordinates.
The big configuration difference is that I wanted the git repositories to reside on the elastic-block store, but be accessible in the usual way. So, after installing git and gitosis and adjusting my gitosis-admin repository, I moved all the repostories from /home/git/repositories to /mnt/ebs/git/repositories. A symlink in the /home/git/ directory links to the repositories on the elastic block store, which makes them accessible to the git user as they need to be.
PyGreSQL is a python library that allows you to write python code to interact with a PostgreSQL database. I can see some utility here if I start wanting to write Django methods that do things like create views of some of my tables.
May be useful in not too long! Don't forget about it!
USGIN Amazon Virtual Server Development | 18 Posts | Invite only Documenting the process of development of a Web Server in the Amazon EC2 environment. Software installations tailored to the requirements for USGIN