I'm currently using openmaptiles in order to generate planet tiles (zoom 0 to 14 or 15). This is a long process that I plan run on dedicated servers.
I know that this is a service offered by openmaptiles but I can't afford spending $1200 or $1000 to generate or buy the tiles.
It's written in the README of openmaptiles project that the quickstart.sh isn't optimized for planet rendering. This is why I'd like to know how I could optimize the configuration to make it as fast as possible.
To be clear, I will use mbutils to generate tiles from mbtiles file, allowing me to run the planet generation on different servers with different zoom levels (i.e zoom 1 to 9 on a first server, and 10 to 14 on another one). This way, I will collect different mbtiles files that I will use to generate and merge .pbf tiles with mbutils.
I read an issue but it didn't change anything for me.
Maybe I can also remove some layers that won't be used on my map ? (How to do that ?)
ATM, when I run a script, it doesn't seem that it's using the full CPU capacities.
Thanks for your help
I found a way to accelerate the process:
Make a PR of openmaptiles/generate-vectortiles repo that contains the dockerfile of the main container for this project.
In the background, this container uses mapbox's tilelive project that allows to split a big job in smaller ones.
I added two environment variables:
JOBS: The number of job it should be splitted in
JOB_NUM: The job number to run
The fork is here: https://github.com/qlerebours/generate-vectortiles
It allows to paralellize the process if you have multiple servers to generate this.
you can restrict layers returned by modifying: https://github.com/openmaptiles/openmaptiles/blob/master/openmaptiles.yaml
Inside openmaptiles.yaml - reduce the layers entry so it contains the only layers that you require.
For example, I only required building data so I changed the file so that the layers section only contained the following.
layers:
- layers/building/building.yaml
I worked this out by going through the history of the openmaptiles repository. It worked for me.
Hope this helps! If you find another ways to speed up the process, it would be good to share!
Thanks
-Rufus
Related
My organization is trying to find an out of the box way with Azure DevOps to see which features were 'committed to' at the start of the release, and which are delivered. The Velocity report would be perfect, except Features are assigned to areas that are configured to run off of sprints that are child-iterations of larger release-iterations, and we want the data at the release-iteration level.
We're able to build queries that can mostly deliver this, but that method doesn't track changes, just shows you a current point in time view of how things are.
The goal is to have data we can use to evaluate if we're making commitments we can keep.
How have other organizations tackled this sort of problem? How do you tie committed vs. actuals at the Feature level?
I could understand your requirements. But based on my test, Velocity Report has some limitations:
For example:
If the Iteration Path has Child Iteration, it will show the child Iteration on Velocity Report. As you said , release-iteration will not show in the Report.
So it cannot meet all your needs.
I tested some related extensions and existing charts, and it seems that there is no tool that can improve or replace the Velocity Report .
For a workaround:
For Child Iteration, you still could use the Velocity Report to record the process.
For the Parent Iteration, you could create different queries to show the process(Planned
, Completed,Completed Late and so on). You can use query to get the work item list of the corresponding state.
Here are examples:
Planned :
Completed:
...
Then you could add them to the Dashboards(Query Title Widget):
On the other hand, this requirement is valuable.
You could add your request for this feature on our UserVoice site, which is our main forum for product suggestions.
I've written a NetLogo model to model agent movement in a landscape. I'd like to run this model from the command prompt, using AWs/Google Compute. The model uses about 500MB worth of input rasters and shapefiles and writes rasters and csv files. It also uses the extensions gis, rnd, cf, table and csv.
Would this be possible using the Controlling API? (https://github.com/NetLogo/NetLogo/wiki/Controlling-API). Can I just use the steps listed in the link? I have not tried running NetLogo from the command prompt before.
Also, I do not want to run BehaviourSpace as it is not relevant to this model.
A BehaviorSpace experiment can consist of only a single run, so BehaviorSpace may actually be relevant to you here. You only need to write one short XML file (or no new files at all, if the experiment setup you want is already part of the model) to do it this way.
Whereas if you go through the controlling API, you will have to write and compile Java (or Scala) code, which is a substantially more complex task.
But if you decide to go the controlling API route: yes, that works too, and it is documented, as you've already noticed.
First Post! am kinda feeling the pressure :)
I've created a multiple option filter for my dashboard using a set (with include all members). which is great for my sheets which use that datasource as primary, but when it's the secondary source I've hit a brick wall - I cannot see (or find any reference in searches) how to use the filter. Any calculated dimensions I've seen reference In/Out. Is there a way round this or something I'm missing?
thanks.
You can't do it when it's based on the secondary source in a data-blending scenario. Currently Tableau only allows for it to be applied to the primary. We are hoping this changes in version 10.0.
I am trying to create an automation framework using cucumber and trying to replicate a real time scenario (sprint wise delivery).
How do I structure my folders/source folders/packages in eclipse? Below is the structure which I am about to follow but I am not quite convinced if it is right.
I am trying to structure in such a way that when I give the command
"mvn test -Dcucumber.options="src\test\resources\sprint1\features", then it should run all the features under sprint1, similarly for sprint2 and so on.
Any suggestions or inputs would be helpful.
P.S: Since I am new to cucumber, a detailed explaination on the folder structure for real time sprint wise delivery would be much appreciated.
Thanks :)
I would not consider the file structure you are thinking of.
The reason is that after a while, it doesn't matter when a feature was added to the system. So organizing features based on time is a bad idea.
If you still need to be able to run the features for a specific sprint, consider using tags instead. That would allow you only to run the features connected to the sprint you are interested in.
I would not to that either, because after a while it doesn't matter which sprint a piece of functionality was added. It should still pass all executions, even if it is 27 sprints old.
If this organization is bad, how should you do it instead?
This is a question where a lot of people have a lot of opinions and the debate can get very heated.
My take is that it is interesting to make sure that the code is easy to use. With that I mean easy to navigate and understand for a new developer. If you want, think of usability in any other product.
Given this, I would organize the features after functional areas in different packages. A package for each area, one for viewing products, one for ordering products, one for paying etc.
I would also try to take a step further and organize the source code in a similar way.
But I would never organize using a temporal approach as you are thinking of.
You should not organize your tests as per the sprint because a particular sprint will end on a particular time. If you want to run some feature files together for temporary basis(till the time sprint is not over), you can add tags on the top in the feature files.
For example:
You have following 2 feature files:
src/test/resources/sprint1/file1.feature
src/test/resources/sprint1/file2.feature
Just add "#sprint1" on top of each feature as shown below:
//1. file1.feature
#sprint1
Feature: sprint1 : features : file1
Scenario: Some scenario desc..
Given ....
When ....
Then ....
//2. file2.feature
#sprint1
Feature: sprint1 : features : file1
Scenario: Some scenario desc..
Given ....
When ....
Then ....
Now to run these both files you need to execute the following code in your command prompt:
cucumber --tags #sprint1
By executing this command, all the files which contains "#sprint1" tag will run. After the sprint is over, you can delete this extra tag from feature files
I'm looking for a way to visualize arbitrary information about my repository over time, which might be some version-dependent number, such as:
lines of code
number of lines in a latex document
time between commits
anything that can be output by a script
What is the best way to visualize this information?
More specifically, I'm using mercurial and would ideally like something with a decent interface, with plot resizing/scrolling/etc... Jenkins' plot plugin is decent but not great, but more importantly it's not possible to visualize past data (say, after adding a new metric).
I would suggest to split your task to simplify everything a little bit. It is likely you will need several different tools in order to collect and visualize all required information. Historical view seems to be another big challenge.
Lines of code
There are several plugins available for Jenkins, but almost all are highly specialized. SLOCCount plug-in seems to be most universal, but it does not provide any graphical output.
NSIQ Collector Plugin
SLOCCount plug-in
JavaNCSS Plugin
There might be some other option for your language. For example, CCCC will provide required information for C and C++ code:
Number of lines in a latex document
I see several options to achieve that:
adapt existing solution/plugin
use repository statistics tool (Pepper, for example, can do the trick)
use simple shell script to count lines and report it
Pepper will generate something like the following:
Please check Pepper gallery. There are another tools, for example: hgchart
Time between commits
The simplest solution is to let a commit to trigger some trivial job, so Jenkins will provide all information as part of build history (with a timeline, etc).
Another solution is to use repository statistics tool once again:
Anything that can be output by a script
There are several good plug-ins for that.
Plot plugin can visualize multiple values provided as properties or csv file.
Measurement Plots Plugin scans the output in order to find values to be visualized
Happy continuous integration.