Working with GoogleEarth, I am able to import CSV data that contains long, lat, name, etc., but I am unable to get Google Earth Pro to recognize timespan (begin, end) information.
I found an online App called EarthPoint, that allows me to convert a CSV file into KML that includes the timespan data, but that app is limited in its ability to recognize additional fields. Thus, I am unable to apply style templates to the EarthPoint imported data, as there is nothing for Google Earth to latch onto.
So I am looking for either a different app, that imports all three (geo, time, description), from either CSV, or straight from a spreadsheet app like Excel.
And barring the existence of such an app, I would simply like to know if there is a way to specify the headers so that Google Earth will reecognize the time series data for what it is.
Related
I have an ICS generator gzip the results but still the files get VERY large. The ICS format clearly isn't made to contain large number of events. I looked at the spec and there doesn't seem to be a way to create "chunks". For example, have an ICS per month of the year with an "index" file in front or a way to "link" to the previous month which would allow me to do something like:
https://mywebsite.com/calendar => 307 => https://mywebsite.com/calendar/202205.ics
Where https://mywebsite.com/calendar/202205.ics would then link to https://mywebsite.com/calendar/202204.ics, etc.
Are there any of such techniques possible with ICS? That would also make it possible to keep read-only data of past events and the ability to static host all these without the need to every time update it with a new static file.
Is there maybe a different calendar format better suited for this that is still compatible with Google Calendar, Outlook and other popular calendar apps?
I'm using MS-Office 2016 to do a Mail Merging for a contract where the original Data is stored in an Excel file.
I have problem formating the Plate number as it should be in a format like
this ##-##### and that's how it's shown in Excel, However, when i do the merge it shows like
this #####-## and here is a photo to show exactly one entry.
I tried placing the merged field out of the table, tweaked with right to left, left to right and tried to generate a format based on what i saw on the internet about formatting Date and Currency, However, I got no positive results.
I would appreciate if you could help me formatting this field or direct me to reference in which i can learn how this formatting thing works.
Or, I don't know if this viable but every time i open the .docx file it says that it need to run sql query, can I access that query?, I think I have a base knowledge about that and I may be able to format it through the query.
Scrumwise can export its whole data as XML. This contains lots of data including Projects, Backlog, Sprints, Tasks, Team Members, etc. It can also export Tasks as CSV.
GreenHopper can import Projects in various formats (but not XML).
I'd like to transfer as much as possible between Scrumwise and GreenHopper. I'm thinking of extracting the Projects node from the XML, converting to JSON, and importing that. Right now GreenHopper rejects the data right from the start.
Is there a reference to the data schema used in GreenHopper? I'd like to transfer more than just the Project, but all its associated data.
Select all the backlog tasks and export. Scrumwise uses the semicolon as the delimiter. Convert by search and replace and JIRA will at least try to import. Import into a new empty project, expect it to take several attempts to get it right. You'll need to add columns for time remaining in seconds. Getting the statuses and resolution was the hardest part. JIRA gives you status options that will fail during import! Check the jira workflow for valid states. Also, an empty resolution means "unresolved", an unrecognized resolution defaults to "resolved". For tasks, you will need to export as XML, parse the XML for all tasks and add a parent ID column.
Is there anyway to filter the results returned using xapi so that I don't have a ton of results to work through? I thought something like [filter=tag] might only show tags but I can't seem to find any documentation saying this is possible.
Thanks
(1) The standard way of using XAPI lets you filter to retrieve only objects tagged with a certain tag, for example just to get pubs you'd use:
http://jxapi.osm.rambler.ru/xapi/api/0.6/*[amenity=pub]
(2) If you want to filter an OSM file after you've downloaded it (e.g. to remove certain tags), Osmosis is a command-line tool that can do various types of filtering.
(3) If you want to filter an OSM file into some other format (i.e. you're not interested in having an OSM-format XML file at the end) you could use XSLT. Here is an XSLT I made which extracts a small number of pub parameters from an OSM file to CSV.
One of the features in my application is a log where a user can add log entries. I want to make it possible to for the user to export this data. However I do not know which format I should use for this. The data looks like this:
A date, distance, duration, maximum four category names. What I want is to make it possible to send it on mail or open it with dropbox using the URL scheme if the user has dropbox.
I have read about CSV format but I don't know if that is a good file format? My main concern is that the user do not have to have a fixed number of categories (could be between 1-4 categories)
Seeing as the columns of data to be exported will be dynamic in total, it will depend on what the user selects - and there's nothing wrong with this.
I think .csv is fine for this purpose as well - but you need to ask yourself... what will the user be doing with the data? You could either offer multiple file export formats or whatever is the best-for-purpose format, depending on what your average user will do with it.
CSV (comma separated values) is simple (and adds very little overhead - the commas), but not terribly flexible. This is good for importing to MSFT Excel, for instance.
You should consider using XML (the same underlying format used for plists) which is a very flexible (future proof should you wish to add additional columns in the future) and well supported format.