region() behavior at the feature boundaries
See original GitHub issueIn my gff3, I have a feature that is seqid=x, start=a, end=b. By gff3 convention, both a and b are included. If I query for the single position a with region(seqid=x, start=a, end=a)
I am not finding this feature, however if I query region(seqid=x, start=a, end=a+1)
or region(seqid=x, start=a+1, end=a+1)
I do find it. This seems inconsistent to me. Am I missing something? Is this behavior defined anywhere?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:9 (5 by maintainers)
Top Results From Across the Web
Get started | Maps JavaScript API - Google Developers
In the Google API Console you can select which feature layers to display. This determines which kinds of boundaries will appear on the...
Read more >Capture—ArcGIS Field Maps | Documentation
Capture a single place at a location chosen on the map Capture an area by ... new features setting with the Field Maps...
Read more >g.region - GRASS GIS manual
g.region: Manages the boundary definitions for the geographic region.
Read more >BRFSS Maps: Methods and Frequently Asked Questions (FAQs)
Features include multiple data classification methods, map panning and zooming, related prevalence tables, downloadable map images, and the capability to ...
Read more >Logistic map - Wikipedia
Behavior dependent on rEdit · For r between -2 and -1 the logistic sequence also features chaotic behavior. · With r between -1...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This issue seems to be caused by the fact that these lines in
gffutils.FeatureDB.region()
involve strict inequalities. The boundary base pairs get included correctly, if the lines are changed intoCould someone else check if this change is correct?
This is exactly my experience. Thank you very much for characterizing the bug. I was working on something else by the time @daler replied and never got around to reproducing it.