I use GeoServer to publish some GIRBS files.
Now I'm in doubt about how to use Styles. I know what SLD styles are, but don't know how many styles I should provide or attach to GeoServer.
Should each GRIB file Layer use a specific style (for example temperature, Pressure, Humidity, ...)?
And should we provide style for different Zoom Levels?
At last are there any ready and pre-built default styles that could serve all layers?
Related
This question is about the design of SVG-fonts.
I am using some third-party SVG music fonts for an application. The single glyphs of these fonts, are by default very huge in size. I was wondering what the reason for this could be. I can think of, this allows to do more fine-tuning work while designing the fonts, and since they are of course scalable, they should be down-scaled as needed when I want to actually use them. Is this true, or are there some other points to consider?
Also when I use the path's data of single fonts (e.g. in a svg file) and open the svg file in Inkscape the symbols are upside-down, so I have to apply scale(1 -1) to all symbols. Is there a reason why these fonts are designed this way?
It will generally relate to the tool(s) they are using. Font editors commonly have a default em size of around 1000 units. The reason for that is likely because font files generally use integers, rather than floating point, for their glyph coordinates. And 1000 gives you a decent three digits of precision.
For instance have a look at a description of the OTF/TTF glyf table
As part of my software I have to somehow convert and display Esri ASCII (.asc) files on a leaflet map.
The files are in the filesystem and the backend is in nodeJS.
.asc is a raster format and gdal_translate manages to translate the files as I like. Unfortunately I can't use GDAL in node and as far, as I see it, gdal-node is not able to convert the files. Manually converting files is not an option.
My data is always somehow geo referenced, so if I get an image, it has to be placed on the right spot on the worldmap.
Help would be highly appreciated, because I feel kinda overwhelmed by all this GEO stuff.
If you want the normal set of features Leaflet offers, like zooming, what you need is called a map tile service.
There are a few map tile standards that Leaflet supports. Generally though, making map tiles is complicated — particularly if your ASCII grids are in lat/long but you're using a background layer from Google, Bing, OSM that's in "web Mercator" — so you probably don't want to write one in Node yourself.
Look at GeoServer and see if that will fit into your setup.
Is there a way to control the resolution of an exported PNG image in ArgoUML?
Can't find any way to create a higher resolution output and the default resolution of exported grpahics is not useable for importing and printing them within a document for most UMLs we've created so far - most labels and annotations are barely readable.
D'Oh!
On second (3rd..) look it turns out that there's a setting under Environment:
When setting the Graphics Export Resolution to High all is good!
Which that was the default..
The PNG exporter writes at screen resolution (~75-100 dpi) which will look quite small at print resolutions (300+ dpi). You can have your document tool scale the image up, which will look kind of chunky, but will probably be usable, or you can choose a vector format which is more appropriate for printing than a raster format like PNG or GIF.
ArgoUML supports both SVG and EPS which would probably be better choices depending on what your document editor/processor accepts.
I am into a project in university, I would like to know that how can I use liquid layout in android so that different screen sizes must see the application according to its resolution?
In simple words, I would like to create an application whose layout is perfect in all the type of screens :)
I know how to create it in simple html/css in websites for PCs, but how to do it in android?
Can anyone please give suggestions/help/tutorial link?
Thanks,
Usman
Android provides "liquid" layouts out of the box - the layout dimensions and contained elements adapt to screen resolution automatically. It is gracefully handled by the Android framework. There are various kind of layouts available (LinearLayout, FrameLayout etc.) so you need to check carefully which type of layout is the best for you.
You should avoid AbsoluteLayout. While it is true it lets you specify exact locations (x/y coordinates) of its children it is less flexible and harder to maintain than other types of layouts without absolute positioning. It is now deprecated anyway.
Useful links:
To read more about different layouts see: http://developer.android.com/guide/topics/ui/layout-objects.html
Good tutorials are also available here: http://developer.android.com/resources/tutorials/views/index.html in the "Layouts" section.
AbsoluteLayout doc: http://developer.android.com/reference/android/widget/AbsoluteLayout.html
Update:
Layout itself will adapt to different kind of resolutions automatically but you need to keep it mind that elements contained in a layout can look differently. The same image will be smaller on high-res screen than on low-res screen. Luckily, Android provides a way to deal with this problem in a simple manner. You can supply different images depending on the resolution that a device has (this is a bit of a simplification because there are other factors eg. pixel density in addition to resolution that matters). By the same token, it is also possible to supply a different layout but it is not that common.
Links:
Full story on multiple screen support: http://developer.android.com/guide/practices/screens_support.html
Sample code: http://developer.android.com/resources/samples/MultiResolution/index.html
Im writing a game engine and I'm wondering what 3D model format should I use/load/export? Obj seems universal and easy but it also appears to be unreliable in that most models out there contain errors and it doesn't store anywhere near as much as other formats.
There appear to be formats specifically for games such as MD2/3/5 but Im not sure, I use wings3d if I model, and I don't know what other details beyond purely loading what I need and support from the format Id have to implement, such as would I need to implement IK? and can I use scripted per piece animation rather than Inverse kinematics and bone rigging?
Collada is an open XML based format for 3d models owned by the Khronos group(OpenGL standards body)
From the Collada.org FAQ:
The COLLADA 1.4.x feature set includes:
Mesh geometry
Transform hierarchy (rotation, translation, shear, scale, matrix)
Effects
Shaders (Cg, GLSL, GLES)
Materials
Textures
Lights
Cameras
Skinning
Animation
Physics (rigid bodies, constraints, rag dolls, collision, volumes)
Instantiation
Techniques
Multirepresentations
Assets
User data
Before worrying about what 3D formats you want to support, I think you should really focus on what features you are planning to implement in your engine. Write those down as requirements, and pick the format that supports the most features from the list... as you'll want to showcase your engine (I am assuming you are planning for your engine to be publicly available). You might even want to roll your own format, if your engine has specific features (which is always a good thing to have for a game engine).
After that, support as many of the popular formats as you can (.X, .3DS, .OBJ, .B3D)... the more accessible your engine is, the more people will want to work with it!
Collada is a nice and generic format, but like Nils mentions, it is not an ideal format for final deployment.
I use my own binary format. I've tried to use existing formats but always run into limitations. Some could be worked around, others where showstoppers.
Collada may be worth a look. I don't think that it's that good as a format to be read by a 3D engine. It's fine as a general data-exchange format though.
http://www.collada.org/mediawiki/index.php/Main_Page
+1 for Collada. You may also want a custom native binary format for really fast loading (usually just a binary dump of vertex/index buffer data, plus material and skeleton data, and collision data if appropriate).
One trend in the games industry is to support loading a format like collada in the developer build of the engine, but also have a toolchain that exports an optimized version for release. The developer version can update the mesh dynamically, so as artists save changes, the file is automatically reloaded allowing them an (almost) instant WYSIWYG view of their model, but still providing a fully optimised release format.
support Collada well, and then supply good converters to/from the other formats (this might be the hard part). This will give you maximum flexibility. Take a look at C4 engine
Collada is great, but it lives more on the 3D app side of things. ie it's best used for transferring 3D data between applications, not loading 3D data from within a games engine. Have you looked into Lua? It's widely used in games because its a scripting language that's both ridiculously quick (perfect for games) and very flexible (can be used to represent whatever data you need for your engine).